Humans and Technology 7691 Dell Rd Salt Lake City, UT 84121, USA

801.947.9277

Лори Вильямс University of Utah Computer Science 50 S. Central Campus #3190 Salt Lake City, UT 84112, USA

435.649.7931

Original text at:

 

 

Введение

При парном программировании разработчики решают все задачи совместными усилиями, работая бок о бок за одним компьютером. За последние несколько десятков лет такая практика уже неоднократно получала самые лестные отзывы, так как с ее помощью удавалось значительно улучшить процесс разработки ПО.

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

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

Программисты привыкли считать свою работу индивидуальным, а не коллективным трудом (это убеждение основано как на навыках, которые они получали в процессе обучения, так и на опыте работы).

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

И в то же время:

Довольно много известных и уважаемых программистов предпочитают парное программирование любому другому стилю работы.

Те программисты, которые уже привыкли к "парному" стилю работы, говорят, что так работается "как минимум, вдвое быстрее".

Что касается качества программы, то опыт показывает, что при парном программировании система имеет лучший дизайн и более простой код, который в будущем можно легко расширять и модифицировать.

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

Все это поднимает несколько довольно провокационных вопросов. Действительно ли парное программирование эффективнее одиночного? Что оно представляет собой в экономическом плане? И, наконец, нравится ли людям работать в паре? Не теряют ли они удовольствие от работы?

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

 

Пример использования парного программирования в одном из проектов

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

В начале декабря моя команда занялась довольно рискованной деятельностью. Эта деятельность включала в себя внесение изменений практически в каждый файл и слияние фрагментов кода. При всем при этом надо было ничего не сломать. Дальше больше - в архитектуру одной из подсистем потребовалось внести довольно существенные изменения. Итак, с одной стороны, эта работа представляла собой скучнейшую рутину, а с другой - требовала постоянного внимания и напряженной работы мысли.

Разработчики согласились со мной в том, что парное программирование:

- Должно существенно уменьшить риск появления скрытых ошибок, а значит сделать отладку программы менее мучительным процессом;

- Даст нам возможность провести гораздо более полную проверку кода, чем мы когда-либо делали; а кроме того

- Предоставит программистам возможность обмениваться знаниями.

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

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

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

Наконец, мы подготовили промежуточную версию системы и отдали ее в отдел контроля качества (QA). К нашему удивлению, процесс тестирования прошел без сучка без задоринки. Это было тем более удивительно, что одну из подсистем некоторое время назад целых шесть (!) недель мучили в отделе QA. Было совершенно очевидно, что парное программирование коренным образом уменьшило количество дефектов в системе.

С течением времени сотрудничество программистов становилось все более тесным.

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

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

Сам я начал работать в паре только к концу проекта. Как только моему партнеру и мне удалось синхронизировать наши мысли, я понял, как замечательно работать вдвоем.

И хотя ему не хватало опыта, он умел так сформулировать вопрос, что подыскивая ответ, мы, как правило, находили оптимальное решение для каждой проблемы.

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

 

Направления исследования

Мы рассмотрим здесь восемь направлений исследования, связанных с программированием и организационной эффективностью. Удивительно, но все они свидетельствуют в пользу парного программирования. Итак, мы вели наши исследовали в следующих направлениях:

Экономическая обоснованность. Недавние эксперименты показали, что стоимость разработок при добавлении второго программиста возрастает совсем немного. Однако в этом случае программный код будет иметь гораздо меньше дефектов. Таким образом, изначальные затраты с лихвой компенсируются экономией на исправлении ошибок.

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

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

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

Решение проблем. Все опрошенные нами программисты подчеркивали, что при парном программировании возрастает способность команды быстро находить выход в "безвыходных" ситуациях.

Обучение. Работающие в парах программисты утверждают, что многому учатся друг у друга..

Формирование команды и коммуникации. Опрошенные нами программисты говорят, что с помощью парного программирования разработчики в их командах учатся обсуждать проблемы и решать их совместными усилиями. Это улучшает и качество общения людей, и эффективность их работы.

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

Далее мы рассмотрим каждый из восьми пунктов более подробно, с привлечением статистических данных и информации, полученной в результате многочисленных опросов и интервью. Все это позволит более точно определить затраты, которые требует парное программирование, и выгоды, которые оно приносит.

 

Экономическая обоснованность

Ключевой вопрос, возникающий при обсуждении целесообразности перехода на парное программирование - это затраты, которых оно потребует. Если методика требует слишком больших расходов, то никакой руководитель компании просто не станет ее вводить. Скептики полагают, что переход на парное программирование влечет за собой удвоение расходов на разработку программы и персонал. Однако, помимо этих затрат существуют и другие виды расходов, которые тоже необходимо учитывать: контроль качества и поддержка уже находящегося в эксплуатации продукта. Так, IBM сообщает, что они потратили около 250 миллионов долларов только на устранение 30 000 проблем, о которых заявили их клиенты. Итого, по 8 000 долларов за каждую ошибку!

В 1999 году второй автор этой статьи (Лори Вильямс) провел в университете Юта эксперимент по выяснению экономических аспектов парного программирования. В нем участвовали студенты старших курсов, обучавшихся по специальности "Software Engineering". Треть группы писала программы обычным способом - то есть, в одиночку. Остальные работали над проектом в паре с партнером. На рисунке 1 вы видите, сколько времени затратили на выполнение заданий первая и вторая группы студентов. После начального периода "притирки" партнеров, которая проходила во время работы над первой программой, пары программистов тратили всего на 15% больше времени, чем индивидуалы. Как видите, парное программирование отнюдь не удваивает стоимость разработки!

Рисунок 1: Время, затраченное на выполнение контрольных заданий

Важно отметить, что получившийся в результате парного программирования код содержал на 15% меньше ошибок, чем код индивидуалов. (Эти результаты подтверждены статистикой.) На рисунке 2 показано, с каким успехом проходили тестирование программы, написанные студентами обеих групп (иными словами, процент успешно пройденных тестов, которые писал инструктор).

Рисунок 2: Ошибки в программах

Изначальное 15% увеличение стоимости разработки окупается за счет уменьшения количества ошибок. Проиллюстрируем это положение наглядным примером. Предположим, что программа в 50 000 строк кода (50 000 LOC) разрабатывается группой программистов-"одиночек" и группой программистов, работающих в парах. При типичной скорости разработки 50 LOC в час "одиночки" напишут эту программу за 1000 часов. "Пары" затратят на ту же задачу на 15% больше, то есть 1150 часов. Таким образом, стоимость разработки вырастает на 150 часов. Основываясь на статистических данных, программист совершает 100 ошибок на 1000 строк кода. Правильно поставленный процесс разработки позволяет выявить около 70% этих ошибок. Следовательно, у "одиночек" в программе останется порядка 1500 ошибок, в то время как у "пар" их будет на 15% (на 225) меньше - 1275 ошибок.

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

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

Посмотрите, что говорит программист, работающий в паре с партнером, и как это совпадает с тем, что мы прочли у Флора:

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

Во время количественных исследований, проведенных в университете Юта, работающие попарно программисты не только разрабатывали программы высокого качества, но и реализовывали необходимую функциональность в меньшем количестве строк кода, чем программисты-одиночки. Более подробно эти данные представлены на рисунке 4. Нам кажется, что краткость программного кода свидетельствует о более качественном дизайне всей системы.

Рисунок 4: Количество строк кода

 

Непрерывность проверки кода

Уже двадцать лет тому назад было установлено, что визуальная проверка кода - это эффективный, с точки зрения стоимости, метод исправления дефектов в программных продуктах. Это подтверждают и эмпирическими исследованиями, однако несмотря на это, большинство программистов не любят проверок и не считают это занятие ни приятным, ни стоящим. В результате о проверках, как правило, забывают (за исключением тех случаев, когда их выполнение требуется официально). Зачастую проверку кода осуществляют неподготовленные к этой задаче программисты.

"Несмотря на положительные результаты исследований в течение более 20 лет, процедура проверки кода очень плохо приживается в индустрии производства программных продуктов. Точных данных у нас нет, однако согласно неформальному обзору USENET-групп, 72 из 90 опрошенных программистов практикуют проверку кода крайне редко, или вообще ей не занимаются."

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

Экспоненциальный рост стоимости дефектов легко объяснить. Во время проверки, программист говорит: "У оператора "if", что на 450 строке кода, должен быть оператор "else"." После этого ему понадобится несколько минут, чтобы быстро исправить эту ошибку на своем компьютере. Если же программный продукт уже находится в эксплуатации, то в один прекрасный день раздается звонок разъяренного клиента: "Новый год на носу, а у меня ни одна касса не работает! Я ни-че-го не могу продать! Вы меня разоряете!"

Итак, в первом случае программист имеет дело с ошибкой, на которую ему только что указали. Во втором случае, группа технической поддержки должна потратить время на диагностику проблемы (все кассовые аппараты не работают), затем обратиться к самой системе и определить, где нужно вносить исправления (в какой строке кода не хватает оператора "else"). На этом примере всякий может убедиться - работа группы поддержки, которой надо проанализировать проблему и выявить дефект, стоит гораздо дороже, чем те несколько минут, которые должен затратить программист на исправлении ошибки в своем собственном коде. Если программисты работают парами, то такие проверки кода происходят непрерывно. А непрерыная проверка кода не только опережает спорадические "инспекции" как по качеству, так и по скорости нахождения ошибок, но и не вызывает у программистов отрицательных эмоций.

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

Как-то я работал с одним из наименее опытных разработчиков над довольно простой задачей. Честно говоря, я всегда считал себя замечательным специалистом по языку Smalltalk, поэтому был уверен, что просто буду учить молодежь, как надо работать.

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

[со слов Рона Джеффриза]

И наконец, еще одним преимуществом постоянных проверок кода является то, что с их помощью разработчики узнают новые способы и стили кодирования, особенности языка и лучше представляют себе всю систему.

Непрерывная проверка кода при совместном программировании создает уникальные условия для обучения, поскольку оба программиста постоянно учатся друг у друга. "Проверка кода - это уникальная возможность для обучения: процесс анализа и критики программных артефактов, которые создал кто-то другой, представляет собой замечательный по эффективности способ изучения языков, техники проектирования, предметной области и т.д."

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

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

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

Команда разработчиков учится общению и совместной работе.

 

Решение проблем

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

[- Дэвид Уагстафф (David Wagstaff), Salt Lake City]

Мы называем описанный Дэвидом Уагстаффом эффект парной эстафетой (pair relaying). Работающие парами программисты часто сообщают о том, что благодаря этому методу могут решать проблемы гораздо быстрее, а также о том, что этот метод отличается от таких процессов как улучшение качества дизайна системы, обнаружение ошибок при наборе или проведение "мозгового штурма". Под словами "Решение проблем" мы понимаем ту ситуацию, когда оба программиста озадачены сбоями в работе программы или же просто не могут решить, как им следует разрабатывать ее дальше.

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

Очень эффективно совмещать технику "мозгового штурма" и парной эстафеты. Один из опытных программистов заметил:

Когда мне приходится снова работать в одиночку после того, как поработал в паре, мне кажется, что у меня отказала часть мозга. Я чувствую, что начинаю терять уверенность в том, что делаю.

 

Обучение

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

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

Обучение на визуальных примерах и его роль в ученичестве

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

У книги есть подзаголовок - "периферийное участие в работе на серьезном уровне", который подчервкивает три основных аспекта ученичества: новичок участвует в работе мастера активно; новичку поручают серьезную, ответственную работу и, наконец, что новичок работает на периферии, постоянно приближаясь к более высокому уровню профессионализма. Поначалу новичкам поручается простая (и не самая важная) часть работы. С течением времени его работа приобретает все более ответственный характер.

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

Наибольший интерес для нашей темы представляет пример обучения мясников в супермаркете. Начинающий мясник работает отдельно от профессионалов; ему поручают только самую простую рубку мяса. При этом он не может научиться у старших рубщиков тому, как нужно делать более сложную и тонкую работу, потому что специалисты находятся в другом помещении. Авторы указывают, что эта ситуация - пример невозможности передачи знаний от учителя к ученику.

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

Специалист в пределах слышимости (Expert In Earshot)

В результате работы на семинарах, в которых участвовали 10 руководителей проектов, первый автор этой статьи сформулировал еще один паттерн для руководства проектом. Полностью (включая примеры и пояснения) вы найдете его в приложении к этой статье. Вкратце его суть можно описать так:

Использовать паттерн Специалист в пределах слышимости (Expert In Earshot) нужно тогда, когда вы замечаете, что программисты-новички, работающие в вашей команде, усваивают новые навыки не так хорошо, как хотелось бы. При этом вы не хотите, чтобы специалист в данном вопросе тратил все свое рабочее время на их обучение. В этом случае нужно поместить специалиста или руководителя команды в то помещение, где работают новички. Таким образом, молодежь будет наглядно обучаться тому, как работает профессионал. Наблюдая и прислушиваясь, новички приобретут манеру (будем надеяться, правильную) работы специалиста. (Понятно, что этого специалиста будут часто отвлекать, поэтому необходимо заранее позаботиться о том, чтобы у него было время и на спокойную, сосредоточенную работу).

Обратите внимание, как этот подход соотносится с исследованиями в области ученичества (см. выше). Важно отметить, что этот паттерн понравился всем 10 руководителям, и они собирались немедленно внедрить его в своих компаниях.

Парное программирование представляет собой сочетание паттерна Специалист в пределах слышимости (Expert In Earshot) и принципа периферийного участия ученика в серьезной и ответственной работе (когда он слышит и видит учителя). Следовательно, в случае с парным программированием мы вправе ожидать более значительных результатов, нежели просто обучение владению новым инструментарием или языком программирования. Эти ожидания подтверждаются сообщениями программистов, которые уже приняли на вооружение эту практику.

Данные статистики

Второй автор этой статьи использовал парное программирование во время преподавания курса web-программирования в университете Юта. Группа студентов состояла из 20 человек, имевших разный опыт программирования. Однако никто из них не знал ни языков web-программирования, ни инструментарий, который для этого используется. Опыт большей части студентов в этой области состоял лишь в применении WYSIWYG редакторов web-страниц. В течении 11 недель занятий студенты на хорошем уровне изучили язык HTML, JavaScript, VBScript, Active Server Page Scripting, Microsoft Access/SQL и некоторые команды ActiveX. Порой им приходилось совмещать операторы всех этих языков в одной программе.

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

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

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

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

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

 

Персонал amp; Управление проектом

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

И компании, и команде разработчиков выгодна атмосфера постоянного обучения и обмена знаниями. Во время работы над проектом существенно возрастают профессиональные навыки разработчиков - как в области языков программирования, так и в области проектирования.

Снижается риск потери ключевых разработчиков, так как многие их коллеги хорошо знают каждую из частей системы. Некоторые называют это "принципом грузовиков": "Сколько разработчиков должен сбить грузовик, чтобы проект не смог нормально завершиться?" Наихудший из возможных ответов: "Одного". Если знания о системе рассредоточены по всей команде разработчиков, это существенно повышает требуемое количество грузовиков, а вместе с ним и уровень безопасности проекта.

 

Заключение

Основные преимущества парного программирования заключаются в следующем:

большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);

заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);

готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");

команда быстрее справляется с возникающими проблемами (см. принцип "парной эстафеты");

разработчики гораздо больше узнают как о системе, так и самом процессе разработки ПО (см. обучение в поле зрения учителя);

к моменту окончания проекта множество людей обладает глубокими знаниями о каждой из его частей;

люди учатся совместной работе и общению, что приводит к увеличению потока информации внутри команды и положительно влияет на ее динамику;

люди испытывают больше удовольствия от своей работы.

При этом увеличение стоимости разработки при парном программировании составляет вовсе не 100%, как можно было бы ожидать, а приблизительно 15%, что легко окупается за счет более высокого качества программного кода (а значит, меньших затрат на тестирование и поддержку).

 

Литература

1. Salomon, G., Distributed Cognitions: Psychological and educational considerations. Learning in doing: Social, cognitive, and computational perspectives, ed. R. Pea and J.S. Brown. 1993, Cambridge: Cambridge University Press.

2. Constantine, L.L., Constantine on Peopleware. Yourdon Press Computing Series, ed. E. Yourdon. 1995, Englewood Cliffs, NJ: Yourdon Press.

3. Beck, K., Extreme Programming Explained: Embrace Change. 2000, Reading, Massachusetts: Addison-Wesley.

4. Williams, L., et al., Strengthening the Case for Pair-Programming, in IEEE Software. submitted to IEEE Software. Online at www.cs.edu/~lwilliam/Papers/ieeeSoftware.PDF

5. Williams, L.A. and R.R. Kessler. The Collaborative Software Process. in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland. Online at www.cs.edu/~lwilliam/Papers/ICSE.pdf

6. Nosek, J.T., The Case for Collaborative Programming, in Communications of the ACM. 1998. p. 105-108.

7. Humphrey, W.S., A Discipline for Software Engineering. SEI Series in Software Engineering, ed. P. Freeman, Musa, John. 1995: Addison Wesley Longman, Inc.

8. Humphrey, W.S., Introduction to the Personal Software Process. 1997: Addison-Wesley.

9. Flor, N.V. and E.L. Hutchins. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. in Empirical Studies of Programmers: Fourth Workshop. 1991: Ablex Publishing Corporation.

10. Fagan, M.E., Advances in software inspections to reduce errors in program development. IBM Systems Journal, 1976. 15: p. 182-211.

11. Johnson, P.M., Reengineering Inspection: The Future of Formal Technical Review, in Communications of the ACM. 1998. p. 49-52.

12. Lave, J. and E. Wenger, Situated Learning: Legitimate peripheral participation. 1991, New York, NY: Cambridge University Press.

13. Weinberg, G.M., The Psychology of Computer Programming Silver Anniversary Edition. 1998, New York: Dorset House Publishing.

14. DeMarco, T. and T. Lister, Peopleware. 1977, New York: Dorset House Publishers.

15. Cockburn, A., Crystal "Clear": A human-powered software development methodology for small teams, Addison-Wesley, 2001, in preparation. Online at http://members.aol.com/humansandt/crystal/clear

16. Highsmith, J., Adaptive Software Development, Dorset House, 1999.

17. Cockburn, A., Characterizing People as Non-Linear, First-Order Components in Software Development, in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland… Online as Humans and Technology Technical Report, TR 99.05, http://members.aol.com/humansandt/ papers/ nonlinear/nonlinear.htm. (На русском языке: );

 

Приложение: "Специалист в пределах слышимости"(Expert In Earshot) Паттерн управления проектом

(полную версию смотрите на http://c2.com/cgi/wiki?ExpertInEarshot)

Неопытным программистам довольно сложно самостоятельно научиться хорошо работать, поэтому…

Около них (в пределах слышимости) должен находиться высококлассный специалист в данной области.

Показания

(1) Новички плохо обучаются и медленно осваивают новые технологические приемы работы.

(2) Все работают над одним проектом, но несмотря на это, специалисты сидят в отдельном помещении, а новички собраны в общей комнате.

Противопоказания

(1) Согласно правилам, размещение специалистов и новичков в одной комнате запрещено.

(2) Специалист некоммуникабелен или же имеет некоторые особенности и привычки, которые вы категорически не хотите видеть ни у кого другого.

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

Цели и задачи

(1) Вам нужно, чтобы все делали свою работу - и новички, и опытные специалисты.

(2) Вы хотите, чтобы новички обучались, и считаете, что у ваших специалистов есть чему поучиться.

(3) Вы можете позволить себе выделить часть времени специалистов на то, чтобы они уделяли внимание новичкам (если конечно, те при этом учатся работать).

Но при этом…

(1) Вы не хотите, чтобы специалисты посвящали все свое рабочее время преподаванию.

(2) Люди всегда стесняются беспокоить начальника (или специалиста) телефонным звонком или стуком в дверь.

Сделайте следующее

Пусть специалист (или начальник) работает в одной комнате с новичками, тогда они смогут перенимать его опыт просто наблюдая и прислушиваясь к тому, что он делает. Специалист же будет продолжать заниматься своей обычной работой.

(1) Новички будут перенимать у специалиста опыт и технологию (будем надеяться, правильную)

(2) Специалист будет чувствовать себя менее комфортно, так как его будут чаще отвлекать от работы. Поэтому вам нужно заранее позаботиться, чтобы у него было свое личное время, когда он сможет спокойно сосредоточиться на своей работе.

(3) Вам и специалисту нужно будет следить за тем, чтобы новички не начали просто перекладывать свои проблемы на чужие плечи.

(4) У вам будет больше людей в одной комнате.

Эффект передозировки

(1) Чрезмерное обилие вопросов существенно снизит производительность специалиста.

(2) Если в одной комнате собрать слишком много переговаривающихся между собой людей, в такой обстановке будет трудно сконцентрироваться.

См. также

Паттерн "Обучение:Дневная няня" (Training:Day Care) предлагает следующее: "Если ваши специалисты проводят слишком много времени за обучением новичков, то … каждый день назначайте одного "ответственного" за всех новичков, а остальные спецы будут в это время спокойно работать. [CoSOOP]. Это может также быть решением в ситуации, когда специалист пытается обучать новичков во время проектирования системы. В паттерне "Специалист в пределах слышимости" (Expert In Earshot), профессионалы не отвечают за обучение новичков. В этой ситуации само окружение позволяет новичку получать необходимые знания, наблюдая за тем, как работает специалист.

Паттерн "Парное программирование" (Pair Programming) не противоречит принципам паттерна "Специалист в пределах слышимости". Таким образом, специалист оказывается в пределах слышимости только своего партнера-новичка (если они работают в одной паре), или же всех остальных коллег, которые работают с ним в одном помещении.

Примеры

(1) Когда Томас Дж. Уотсон Младший, бывший главный администратор компании IBM, сменил жизнь авиатора и плэйбоя на карьеру в серьезном бизнесе, его отец, исполнявший тогда обязанности главного администратора в этой компании, распорядился, чтобы тот провел полгода, сидя сбоку у стола одного из старших руководителей. Целых шесть месяцев единственным занятием молодого человека было смотреть и слушать, как этот высококлассный профессионал выполнял свою ежедневную работу, как он общался с людьми и т.д. Это несколько необычный, но зато очень яркий пример паттерна "Специалист в пределах слышимости".

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

(3) Старший программист работал в одной комнате с шестью новичками. У этого специалиста были две не очень хорошие привычки: во-первых, он не принимал всерьез идею правильного и аккуратного дизайна системы и, во-вторых, вместо того, чтобы объяснять своим неопытным коллегам, что такое хороший дизайн или программа, он просто по ночам переписывал их код. Утром, приходя на работу, эти шестеро никогда не знали, осталась ли программа в прежнем виде или изменилась, и насколько. Через несколько месяцев все новички стали создавать не только плохой, но и неряшливый дизайн. Их идеалом стало высокомерное отношение к проектированию старшего программиста.

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

© Copyright 2000-2002, Alistair Cockburn ("Humans and Technology" Technical Report)

© Copyright , перевод, 2002

Глоссарий используемых терминов:

= проверка кода

= распределенное знание

= поддержка продукта, уже находящегося в эксплуатации

= парное программирование

= парная эстафета

Послесловие переводчиков :

Опыт освоения парного программирования в отечественной софтверной компании описан в статье Романа Еремина