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

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

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

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

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

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