Наш опыт внедрения парного программирования

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

Нас 15 человек. Наш продукт довольно велик - порядка 600000 строк на Delphi и сейчас находится на этапе подготовки в выпуску версии 3.0. XP мы начали практиковать после двух лет разработки, так что у нас тяжелое доэкстремальное наследие (страшный волосатый код и отсутствие Unit тестов). Вот на этом фоне и начались попытки внедрить XP.

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

На этом этапе разработчики разбились на два лагеря - одни охотно работали в паре, другие - старались избегать этого. В конце концов, мы (в смысле я и Product Manager) решили, что пора делать совсем как в XP - стали требовать, чтобы рабочий код писался только в паре. Сейчас скоро уже год как мы практикуем этот подход. Вот некоторые проблемы, с которыми мы сталкивались:

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

Несогласие с тем, что все надо писать в паре. Постоянно возникают аргументы, что существует настолько понятный и очевидный код, что его глупо писать вместе. Я всегда отвечаю - что его так же глупо писать в одиночку. На самом деле, это признак того, что надо рефакторить (что лучше получается в паре). Надо сказать, что когда я работаю в паре с кем-нибудь, я с такой проблемой не сталкиваюсь. Я задаю напарнику вопрос - а должны ли мы вообще писать этот тупой и очевидный код? Ответ обычно "не должны, но...". Тут я и апеллирую к правилу "Безжалостно рефакторить". 

Непродуктивные споры. Двое неплохих программистов, оказываясь в паре, проводят слишком много времени в спорах. Эта проблема - свидетельство отсутствия культуры командной работы и, возможно, неопределенности общих целей. Мы стараемся решить подобные проблемы апеллируя к результату и внедряя формальные протоколы принятия решений (см. книгу Software For Your Head).

Пассивность. Один набирает, другой спит или ковыряется в ногтях. Это являлось результатом силового внедрения, наложенный на внутреннюю пассивность разработчика и непонимание того как работает парное программирование. Разрешается путем работы над личными целями каждого и внедрением нескольких простых правил:
 - Менять ведущего каждые 15-30 мин.
 - Тот кто теряет нить или плохо разбирается в том что пишут - садится за клавиатуру.
 - Если становится скучно - садишься за клавиатуру.

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

Планировка офиса. Не ставьте компьютер в углу, двое должны свободно размещаться перед монитором. Иначе парное программирование существенно замедляется. У нас планировка офиса такова, что столы стоят по периметру, и есть угловые места. То есть за несколькими машинами работа в паре практически невозможна. При обновлении офиса мы планируем поставить столы "островками", вокруг которых пары могут легко собираться.

Клавиатуры. В конце концов, мы купили всем одинаковые клавиатуры (MS Natural). Некоторые повозмущались немного, но быстро привыкли. А раньше частенько кто-то из пары испытывал дискомфорт из-за небольших различий в раскладке.

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

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

Ответственность. Надо отметить, что хотя XP и требует двух человек для написания кода, но задача (Engineering Task) назначается одному. Этим избегается размазывание ответственности и переход ее в коллективную безответственность. То есть свою задачу ты должен делать в паре с кем-нибудь, но она остается твоей.

Команда. Можно заметить, что в XP вообще и в парном программировании в частности, упоминается команда. Команда - это не просто группа людей, она обладает своими собственными качествами. Именно наличие команды определяет то, насколько легко внедряется XP или ее практики. Если у вас есть команда, то многие проблемы решатся сами.
Так вот, я осмелюсь заявить, что наличие сложившейся команды - ключевой параметр при внедрении парного программирования. У вас не будет полного эффекта от парного программирования пока не будет команды. Хорошей новостью является то, что сами попытки работы в паре ведут к формированию команды.