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

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

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

Модели парного программирования

Людям очень трудно все время быть сосредоточенными. Большинство из нас легко отвлекаются. В книге «The Ebb and Flow of Attention in the Human Brain» Трей Хедден и Джон Габриэли исследуют, что происходит, когда люди отвлекаются на внутренние мысли при выполнении сложной работы. Они рассказывают историю Дана Янсена, олимпийского конькобежца, который на зимних Олимпийских играх 1988 года поскользнулся и упал на дистанции 500 и 1000 метров. Янсен тренировался годами и обычно был сосредоточенным. Однако всего за семь часов до его гонки сестра Янсена скончалась от лейкемии. Хедден и Габриэли выдвигают гипотезу о том, что, хотя внимание Янсена, его внешнее внимание было сосредоточено на коньках, у него были небольшие пробелы, когда мысли о его сестре вторгались в его голову. Эти проблемы отвлекли внимание Янсена от внешних задач и привели к его нехарактерным падениям.

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

Модель случайных пар

На Agile 2005 Арло Белши представил и опубликовал отчет об опыте – «Случайные пары и разум новичка».

В своем выступлении и опубликованной статье Белши описал множество практик, все из которых имеют отношение к увеличению способности к обучению у новичка. Разум новичка открыт для экспериментов и не измучен опытом. Белши определяет разум новичка следующим образом: «Если человек чувствует себя комфортно в окружении, но ничего не понимает, то он обычно пробует сделать что-то, пока не разберется с новым для себя опытом.»

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

Белши и его команда выдвинули гипотезу, что, если они смогут оставаться в состоянии новичка как можно дольше, они увеличат свою скорость. Они испробовали несколько приемов. В его команде один человек из каждая пара переключает пары и задачи каждые 90 минут, всегда сохраняя «эксперта» и «новичка» в каждой задаче.

Командные задачи лучше всего объяснены в отличие от индивидуальных задач.

Модель случайных пар на практике

Switch Team – команда из шести человек (не считая владельца продукта или Scrum мастера). Команда Switch договорилась о часах работы. Все члены команды обязательно присутствуют на рабочем месте с 10:30 до 16:00 с часовым перерывом на обед.

Ежедневный Scrum команды в 10:00.

Обратите внимание, что в этом примере есть три блока парного программирования. В каждом блоке есть главный и подчиненный (я назвал этих людей A, B, C, D, E и F). Каждый парный блок длится 90 минут, как рекомендовано в эксперименте Белши. Люди переходят с одного блока в другой змейкой. Задачи же фиксируются на рабочих местах, пока они не будут выполнены.

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

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

Модель микро-пар

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

• Один человек пишет тест, а затем передает клавиатуру своему партнеру.
• – Если тест не пройден (индикатор становится красным), партнер реализует необходимый код для его прохождения.
• – Если тест пройден (индикатор становится зеленым), партнер пишет дополнительный тест или проводит рефакторинг проходящей реализации.
• Затем клавиатура возвращается к исходному человеку, чтобы написать еще один тест или выполнить рефакторинг написанного кода.
• Шаблон продолжается, пока задача не будет завершена.

Итак, почему кто-то хочет написать проходной тест, а не провальный тест? Одной из причин является шифрование или документирование поведения, которое уже существует с помощью другого теста, но не является в достаточной мере задокументированным. Написание проходного теста блокирует некоторые функциональные возможности или подтверждает некоторые подозрения относительно поведения кода. Другая возможная причина состоит в том, что когда вы намереваетесь написать провальный тест, и вы заканчиваете тем, что пишете проходной тест, ой! Это должно вызвать кучу вопросов: плохо ли написан тест? Был ли предыдущий тест плохим? Код выполняет больше, чем вы планировали?

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

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

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

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

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

Заключение

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

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

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

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

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