Алистэр Коуберн - Парное программирование: преимущества и недостатки

В некоторых компаниях программный код передается в отдел тестирования или контроля качества, который находит и исправляет существенную часть оставшихся в программе ошибок. Обычно при проведении системных тестов на одну ошибку уходит от четырех до шестнадцати часов. Возьмем нечто среднее - 10 часов, тогда получится, что на исправление этих "лишних" 225 ошибок отдел тестирования потратит около 2250 часов. А это в 15 раз больше, чем изначальное увеличение затрат на парное программирование - 150 часов!

Если же по окончанию работ программа отправляется непосредственно заказчику, то парное программирование оказывается еще более выгодным. По данным статистики, после выхода программы в эксплуатацию на исправление одной ошибки уходит от 33 до 88 часов. Возьмем оптимистичный вариант - по 40 часов на ошибку, тогда если клиет обнаружит 225 дополнительных ошибок, это будет стоить компании-разработчику 9 000 часов - в 60 раз больше, чем те затраты, которые требовались при использовании парного программирования!

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

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

Изначально многие разработчики настроены по отношению к парному программированию скептически, даже враждебно. Дело в том, что работа с партнером меняет условия работы программиста-одиночки, к которым он так привык. Один программист написал:

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

Согласно статистике, программисты, которые ранее работали в одиночку, а теперь работают в парах, считают, что им больше нравится новый способ работы. Одной из причин они называют возросшую уверенность в качестве своего кода (коэффицент ошибок в том и другом случае подтверждает последнее замечание). На рисунке 3 вы видите результаты анонимного исследования, проведенного в университете Юта среди профессиональных программистов и студентов. Как видите, большинству программистов совместный стиль работы нравится больше.

Рисунок 3: Удовлетворение от работы

Как заметил один из программистов,

"С психологической точки зрения, очень приятно осознавать, что в твоей программе нет серьезных ошибок… Я чувствую себя гораздо увереннее, когда мой партнер просматривает весь код, который я пишу. В этом случае, я могу быть уверен, что делаю свою работу хорошо, ведь ее проверяет и одобряет человек, с которым я работаю и кому доверяю."

На эту тему есть еще один замечательный комментарий :

"Так здорово вместе радоваться, когда что-то работает."

Студенты предпочитают иметь 15%-ные издержки//работать больше, но с партнером

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

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

Нам кажется, что такое поведение свидетельствует о том, что разработчикам нравится работать вдвоем.

Ниже мы приводим слова руководителя одной из команд разработчиков, который и слыхом не слыхал о парном программировании. Здесь он объясняет, почему все его проектировщики-программисты работают вместе за одним терминалом.

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

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

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

В 1991 году Ник Флор (Nick Flor), занимавшийся в то время когнитологией (Cognitive Science), сделал интересный вывод о распределенности знаний у программистов, работавших в паре, которых он изучал. Распределенное знание - это один из разделов когнитологии, основное положение которого можно выразить словами: "Все, кому приходилось изучать процесс осмысления, были поражены тем фактом, что "разум" очень редко работает в одиночку. Вся данные, которые человек поднимает во время этого процесса, оказываются распределенными - по различным умам, людям, а также символическому и физическому окружению, в котором этот человек находится."

С помощью видео и аудио аппаратуры Флор фиксировал все виды обмена мнениями между двумя программистами, которые работали над одной задачей. В этом исследовании Флор установил соотношения между вербальным и невербальным поведением программистов. Для этого он использовал известные когнитологические теории, касающиеся распределенного знания. Одна из таких теорий - "Поиск в более обширном пространстве возможностей" ("Searching Through Larger Spaces of Alternatives.")

"С точки зрения генерации разнообразных планов, система со многими действующими лицами обладает большим потенциалом. Можно назвать, по крайней мере, три причины: во-первых, все действующие лица привносят в разработку свой уникальный личный опыт; во-вторых, каждый из них обладает своим подходом к информации, касающейся выполняемой задачи; в-третьих, все они находятся в разных отношениях к проблеме, поскольку выполняют разные функциональные роли… Главным следствием попытки свести воедино все имеющиеся цели и планы является то, что в такой конфликтной, по сути, ситуации программисты должны открыто договориться, какую последовательность действий необходимо будет предпринять. Вырабатывая, таким образом, единое общее решение, они перебирают гораздо большее количество альтернативных вариантов, чем мог бы в такой ситуации программист-одиночка. Именно это обстоятельство и ведет к снижению риска выбора плохого плана действий."