Парное программирование: преимущества и недостатки

Обратите внимание, как этот подход соотносится с исследованиями в области ученичества (см. выше). Важно отметить, что этот паттерн понравился всем 10 руководителям, и они собирались немедленно внедрить его в своих компаниях.

Парное программирование представляет собой сочетание паттерна Специалист в пределах слышимости (Expert In Earshot) и принципа периферийного участия ученика в серьезной и ответственной работе (когда он слышит и видит учителя). Следовательно, в случае с парным программированием мы вправе ожидать более значительных результатов, нежели просто обучение владению новым инструментарием или языком программирования. Эти ожидания подтверждаются сообщениями программистов, которые уже приняли на вооружение эту практику.

Данные статистики

Второй автор этой статьи использовал парное программирование во время преподавания курса web-программирования в университете Юта. Группа студентов состояла из 20 человек, имевших разный опыт программирования. Однако никто из них не знал ни языков web-программирования, ни инструментарий, который для этого используется. Опыт большей части студентов в этой области состоял лишь в применении WYSIWYG редакторов web-страниц. В течении 11 недель занятий студенты на хорошем уровне изучили язык HTML, JavaScript, VBScript, Active Server Page Scripting, Microsoft Access/SQL и некоторые команды ActiveX. Порой им приходилось совмещать операторы всех этих языков в одной программе.

Во время обучения эти студенты задавали на удивление мало вопросов своим преподавателям. Когда, в последний день занятий, их спросили о причинах такой независимости, мнения распределились следующим образом:

74% написали, что выясняли все вопросы в процессе общения друг с другом.

84% согласились с утверждением: "Я смог изучить Active Server Pages быстрее и лучше, так как все время работал вдвоем с партнером".

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

Формирование команды amp;коммуникация

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

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

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

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

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

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

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

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

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

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

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

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

Несмотря на то, что книги "Психология программирования" ("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 пар программистов не столкнулась с непреодолимыми препятствиями психологического толка. Впрочем, со слов тех, кто пытается практиковать парное программирование во время реальной работы над проектом, такие проблемы все же случаются (возможно, сказывается слабое воздействие на программистов или недостаток мотивации к совместной работе). Опросы тех разработчиков, которые сумели преодолеть трудности, показывают, что изложенный выше сценарий срабатывает довольно часто (может быть, разве что не в столь ярко выраженной форме). Зачастую люди могут научиться работать вместе только после того, как начнут это делать.

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

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

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

Персонал amp; Управление проектом

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

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

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