Шрифт:
‹Неловкое молчание. Люди обмениваются неприязненными взглядами›
"Не думаю, что это сработает. Вот, например, что будет, если мне нужно писать код, а партнера нет рядом?"
"Тогда найди кого-нибудь еще. Главная цель - работать вместе, чтобы передавать друг другу знания".
"А если рядом никого не окажется?"
"Тогда позови меня, я с удовольствием с тобой поработаю. Если же ты и в самом деле не можешь найти ни одного партнера, чтобы писать код вместе, тогда отложи клавиатуру и отдохни."
‹Все удивленно смотрят на меня. Гробовая тишина. ›
Несколько раз парное программирование прошло довольно гладко. Иногда, правда, что-то не получалось. Общались разработчики вяло и редко. Я изо всех сил старался помочь ребятам - старался приучить их думать вслух (то, что Уорд Каннингэм называл рефлективной артикуляцией). И это решило дело! Программисты действительно стали вместе работать, а не просто писать код для одной системы.
Уже через неделю я начал подмечать существенные изменения в поведении разработчиков. Они начали разговаривать друг с другом. Совершенно нормально, так как говорят между собой обычные люди. Нужно было видеть их в начале проекта, чтобы понять, как сильно изменилось их отношение друг к другу. Они беседовали, шутили, смеялись. Теперь уже они начали понимать, что такое доверять друг другу и получать удовольствие от совместной работы.
Еще через несколько дней эти разработчики превратились в отличную слаженную команду."
[из архивов Алистэра Коуберна]
Несмотря на то, что книги "Психология программирования" ("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; Управление проектом
Руководство проектом только выигрывает от улучшения качества работы персонала и уменьшения рисков, которые с ним связаны.
И компании, и команде разработчиков выгодна атмосфера постоянного обучения и обмена знаниями. Во время работы над проектом существенно возрастают профессиональные навыки разработчиков - как в области языков программирования, так и в области проектирования.
Снижается риск потери ключевых разработчиков, так как многие их коллеги хорошо знают каждую из частей системы. Некоторые называют это "принципом грузовиков": "Сколько разработчиков должен сбить грузовик, чтобы проект не смог нормально завершиться?" Наихудший из возможных ответов: "Одного". Если знания о системе рассредоточены по всей команде разработчиков, это существенно повышает требуемое количество грузовиков, а вместе с ним и уровень безопасности проекта.
Заключение
Основные преимущества парного программирования заключаются в следующем:
большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);
заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);
готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");