Программисты обнаружили, что работать независимо, а потом проверять код занимает больше времени, поскольку в процессе проверки приходится обучать партнера всему тому, что узнал сам, пока вносил изменения. Обучение это отнимало почти столько же времени, сколько уходило на внесение изменений. Когда программисты работали вдвоем, им не нужно было делать "двойную работу", процесс кодирования шел быстрее благодаря известному принципу "одна голова хорошо, а две лучше", и разработчики были значительно более уверены в качестве конечного результата.
Наконец, мы подготовили промежуточную версию системы и отдали ее в отдел контроля качества (QA). К нашему удивлению, процесс тестирования прошел без сучка без задоринки. Это было тем более удивительно, что одну из подсистем некоторое время назад целых шесть (!) недель мучили в отделе QA. Было совершенно очевидно, что парное программирование коренным образом уменьшило количество дефектов в системе.
С течением времени сотрудничество программистов становилось все более тесным.
… Когда работа над каждой из подсистем заканчивалась, пары перегруппировывались, в зависимости от навыков, требуемых для решения следующей задачи. Это несколько замедляло работу, так как новым парам требовалось время, чтобы сработаться, прежде чем они начинали трудиться с прежней эффективностью. К августу пары сработались уже настолько, что один из партнеров мог запросто выражать их общее мнение на собраниях, проходивших у нас два раза в неделю.
Последующие релизы, как внутренние, так и внешние, проходили достаточно гладко. критические ошибки обнаружиливались в системе исключительно редко. Благодаря непрерывной проверке кода мы выявили большую часть серьезных проблем, в том числе незамеченные ранее существенные недоработки в дизайне системы.
Сам я начал работать в паре только к концу проекта. Как только моему партнеру и мне удалось синхронизировать наши мысли, я понял, как замечательно работать вдвоем.
И хотя ему не хватало опыта, он умел так сформулировать вопрос, что подыскивая ответ, мы, как правило, находили оптимальное решение для каждой проблемы.
… После этого разработчики сами решили использовать практику парного программирования и в дальнейшем. Никакие указания свыше не сравнятся с личным опытом.
Направления исследования
Мы рассмотрим здесь восемь направлений исследования, связанных с программированием и организационной эффективностью. Удивительно, но все они свидетельствуют в пользу парного программирования. Итак, мы вели наши исследовали в следующих направлениях:
Экономическая обоснованность. Недавние эксперименты показали, что стоимость разработок при добавлении второго программиста возрастает совсем немного. Однако в этом случае программный код будет иметь гораздо меньше дефектов. Таким образом, изначальные затраты с лихвой компенсируются экономией на исправлении ошибок.