Одна голова - хорошо, а две - лучше

(В оригинале - Two Heads Are Often Better than One)

Программирование требует сосредоточенности, а сосредоточенность требует уединения. Таков один из стереотипов.

Подход «одинокого волка» потихоньку меняется на более коллективный, который позволяет для программистов повысить качество, продуктивность и удовлетворенность от работы. Согласно новому подходу, разработчикам приходится более тесно сотрудничать друг с другом и с не-разработчиками – бизнес-аналитиками, системными аналитиками, тестерами и пользователями.

Что это означает для программистов? Быть техническим экспертом теперь недостаточно, нужно еще быть эффективным в работе с другими.

Сотрудничество – это не задавание вопросов или сидение на митингах. Это, закатав рукава, сделать работу вместе с кем-то.

Я большой фанатик парного программирования. Вы можете назвать это «экстремальным сотрудничеством». Как разработчик, мои умения растут, когда я работаю в паре. Если я слабее своего партнера в предметной области или технологии, я обучаюсь с его помощью. Если я сильнее в чем-то, то я еще лучше разбираюсь в том, что знаю и чего не знаю, объясняя это партнеру. Мы оба в паре даем что-то друг другу и учимся друг у друга.

В паре мы создаем коллективный опыт, как в предметной области, так и в технической части, и это позволяет нам писать ПО более разумно и эффективно. Даже в случае сильного дисбаланса уровня внутри пары, более опытный все равно что-то получает взамен, скажем, новую комбинацию «горячих клавиш» или же опыт с новым софтом или библиотекой. Для менее опытного в такой паре – это замечательная возможность быстро «разогнаться».

Парное программирование популярно среди поклонников agile разработки, хотя и не ограничивается ими. Те, кто возражает против парного программирования, обычно задают вопрос «Почему я должен платить двум программистам за работу одного?». Мой ответ в этом случае «Не надо». Я утверждаю, что парное программирование повышает качество, понимание предметной области, владение техникой (IDE и другие программы), а также снижает последствия «риска лотереи» (если один из ваших ведущих разработчиков выиграет в лотерею и уволится на следующий день).

Но какова долгосрочная ценность изучения нового сочетания клавиш? Как измеряется повышение качества результирующего продукта в результате введения парного программирования? Как оценить влияние партнера, не дающего вам довести до конца решение сложной задачи? Одно из исследований показывает повышение эффективности и скорости на 40% (J. T. Nosek, "The Case for Collaborative Programming," Communications of the ACM, Март 1998 года). А какова ценность снижения «риска лотереи»? Большинство подобных показателей достаточно сложно поддаются измерению.

Кто с кем должны образовать пары? Если вы новичок в команде, то важно найти кого-то, кто является экспертом. Точно также важно, чтобы он обладал навыками коуча. Если вы не сильны в предметной области, то образуйте пару с экспертом в предметной области.

Если вы еще не убеждены, то проведите эксперимент. Объединитесь с коллегами. Образуйте пары по интересным, сложным проблемам. Посмотрите, как оно пойдет. Попробуйте повторить эксперимент несколько раз.

Автор оригинала - Adrian Wible