Удовлетворение от работы. Те разработчики, которые пробовали программировать вдвоем, считают, что так работать гораздо приятнее, чем в одиночку.
Качество дизайна системы. Исследования показали, что программисты, работавшие попарно, выпускали более короткие программы, нежели их коллеги, которые работали в одиночку (а как известно, чем короче программа, тем лучше ее дизайн). Об этом же свидетельствуют и личные впечатления разработчиков.
Непрерывность проверки кода. При парном программировании происходит постоянная проверка как кода, так и дизайна системы, что ведет к существенному снижению коэффициента ошибок.
Решение проблем. Все опрошенные нами программисты подчеркивали, что при парном программировании возрастает способность команды быстро находить выход в "безвыходных" ситуациях.
Обучение. Работающие в парах программисты утверждают, что многому учатся друг у друга..
Формирование команды и коммуникации. Опрошенные нами программисты говорят, что с помощью парного программирования разработчики в их командах учатся обсуждать проблемы и решать их совместными усилиями. Это улучшает и качество общения людей, и эффективность их работы.
Персонал и управление проектом. Когда каждый фрагмент кода хорошо знаком не одному разработчику, а сразу многим, это снижает риск, связанный с изменениями в персонале компании.
Далее мы рассмотрим каждый из восьми пунктов более подробно, с привлечением статистических данных и информации, полученной в результате многочисленных опросов и интервью. Все это позволит более точно определить затраты, которые требует парное программирование, и выгоды, которые оно приносит.
Экономическая обоснованность
Ключевой вопрос, возникающий при обсуждении целесообразности перехода на парное программирование - это затраты, которых оно потребует. Если методика требует слишком больших расходов, то никакой руководитель компании просто не станет ее вводить. Скептики полагают, что переход на парное программирование влечет за собой удвоение расходов на разработку программы и персонал. Однако, помимо этих затрат существуют и другие виды расходов, которые тоже необходимо учитывать: контроль качества и поддержка уже находящегося в эксплуатации продукта. Так, IBM сообщает, что они потратили около 250 миллионов долларов только на устранение 30 000 проблем, о которых заявили их клиенты. Итого, по 8 000 долларов за каждую ошибку!
В 1999 году второй автор этой статьи (Лори Вильямс) провел в университете Юта эксперимент по выяснению экономических аспектов парного программирования. В нем участвовали студенты старших курсов, обучавшихся по специальности "Software Engineering". Треть группы писала программы обычным способом - то есть, в одиночку. Остальные работали над проектом в паре с партнером. На рисунке 1 вы видите, сколько времени затратили на выполнение заданий первая и вторая группы студентов. После начального периода "притирки" партнеров, которая проходила во время работы над первой программой, пары программистов тратили всего на 15% больше времени, чем индивидуалы. Как видите, парное программирование отнюдь не удваивает стоимость разработки!