Алистэр Коуберн - Парное программирование: преимущества и недостатки

По прибытии я обнаружил удручающую картину: у Билла не было никакой команды разработчиков. У него было шесть талантливых, хорошо подготовленных сотрудников, которые не могли вместе работать. Они даже сидели поодаль друг от друга. Ясно было, что особых симпатий между ними пока не возникло.

"Давайте поговорим о парном программировании. (далее перечисляются все его преимущества). ‹пауза› Парное программирование вводится теперь в обязательном порядке. Весь программный код должен быть написан при участии второго партнера".

‹Неловкое молчание. Люди обмениваются неприязненными взглядами›

"Не думаю, что это сработает. Вот, например, что будет, если мне нужно писать код, а партнера нет рядом?"

"Тогда найди кого-нибудь еще. Главная цель - работать вместе, чтобы передавать друг другу знания".

"А если рядом никого не окажется?"

"Тогда позови меня, я с удовольствием с тобой поработаю. Если же ты и в самом деле не можешь найти ни одного партнера, чтобы писать код вместе, тогда отложи клавиатуру и отдохни."

‹Все удивленно смотрят на меня. Гробовая тишина. ›

Несколько раз парное программирование прошло довольно гладко. Иногда, правда, что-то не получалось. Общались разработчики вяло и редко. Я изо всех сил старался помочь ребятам - старался приучить их думать вслух (то, что Уорд Каннингэм называл рефлективной артикуляцией). И это решило дело! Программисты действительно стали вместе работать, а не просто писать код для одной системы.

Уже через неделю я начал подмечать существенные изменения в поведении разработчиков. Они начали разговаривать друг с другом. Совершенно нормально, так как говорят между собой обычные люди. Нужно было видеть их в начале проекта, чтобы понять, как сильно изменилось их отношение друг к другу. Они беседовали, шутили, смеялись. Теперь уже они начали понимать, что такое доверять друг другу и получать удовольствие от совместной работы.

Еще через несколько дней эти разработчики превратились в отличную слаженную команду."

[из архивов Алистэра Коуберна]

Несмотря на то, что книги "Психология программирования" ("The Psychology of Computer Programming") и "Кадровое обеспечение" ("Peopleware") были написаны, соответственно, 20 и 30 лет тому назад, никто до сих пор не написал ничего лучшего о командной работе. Уже в наши дни формированию команды и коммуникациям стали уделять внимание новые методологии - eXtreme Programming , семейство Crystal [15] и Adaptive Software Engineering [16]. В статье "Characterizing People as Non-Linear, First-Order Components in Software Development" (Русский перевод: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"), Алистэр Коуберн вообще ставит человеческий фактор в деле разработки ПО на первое место, утверждая, что это вовсе не второстепенный вопрос, как принято считать.

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

Как вы уже поняли из приведенного выше рассказа, люди учатся работать вместе. Во время эксперимента в университете Юта ни одна из 14 пар программистов не столкнулась с непреодолимыми препятствиями психологического толка. Впрочем, со слов тех, кто пытается практиковать парное программирование во время реальной работы над проектом, такие проблемы все же случаются (возможно, сказывается слабое воздействие на программистов или недостаток мотивации к совместной работе). Опросы тех разработчиков, которые сумели преодолеть трудности, показывают, что изложенный выше сценарий срабатывает довольно часто (может быть, разве что не в столь ярко выраженной форме). Зачастую люди могут научиться работать вместе только после того, как начнут это делать.

Научиться работать вместе - значит научиться более быстро решать вместе со своими коллегами различные проблемы, а не скрывать друг от друга свои мысли и идеи. В этом случае заметно совершенствуется командный стиль работы.

Если пара программистов сумеет сработаться, то им будет гораздо легче общаться. Кроме того, это общение будет протекать гораздо чаще. При увеличении объема и частоты коммуникаций увеличивается и общий поток информации, циркулирующий внутри команды. Чтобы усилить и ускорить этот процесс, нужно не забывать менять партнеров в парах.

Похоже, все это существенно улучшает производительность команды. К сожалению, эти выводы основываются только на рассказах самих программистов. Никаких статистических данных на этот счет у нас пока нет.

Руководство проектом только выигрывает от улучшения качества работы персонала и уменьшения рисков, которые с ним связаны.

И компании, и команде разработчиков выгодна атмосфера постоянного обучения и обмена знаниями. Во время работы над проектом существенно возрастают профессиональные навыки разработчиков - как в области языков программирования, так и в области проектирования.

Снижается риск потери ключевых разработчиков, так как многие их коллеги хорошо знают каждую из частей системы. Некоторые называют это "принципом грузовиков": "Сколько разработчиков должен сбить грузовик, чтобы проект не смог нормально завершиться?" Наихудший из возможных ответов: "Одного". Если знания о системе рассредоточены по всей команде разработчиков, это существенно повышает требуемое количество грузовиков, а вместе с ним и уровень безопасности проекта.

Основные преимущества парного программирования заключаются в следующем:

большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);

заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);

готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");

команда быстрее справляется с возникающими проблемами (см. принцип "парной эстафеты");

разработчики гораздо больше узнают как о системе, так и самом процессе разработки ПО (см. обучение в поле зрения учителя);

к моменту окончания проекта множество людей обладает глубокими знаниями о каждой из его частей;

люди учатся совместной работе и общению, что приводит к увеличению потока информации внутри команды и положительно влияет на ее динамику;

люди испытывают больше удовольствия от своей работы.

При этом увеличение стоимости разработки при парном программировании составляет вовсе не 100%, как можно было бы ожидать, а приблизительно 15%, что легко окупается за счет более высокого качества программного кода (а значит, меньших затрат на тестирование и поддержку).