Парное программирование: стили, организация, тайм-менеджмент

Многие разработчики слышали о практике парного программирования, но оно все еще имеет разношерстное толкование и применение. Одна из причин неоднозначного признания в том, что преимущества очевидны не сразу, а окупаются в среднесрочной и долгосрочной перспективе. И оказывается не всё так просто, как “работаем вдвоем за одним компьютером”, поэтому некоторые быстро отказываются от этого способа при появлении первых проблем. Тем не менее, по нашему опыту, парное программирование однозначно подходит для командной работы и создания качественного ПО.

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


“Мы с Бетти Снайдер с самого начала были партнерами. И я верю, что лучшие программы и дизайн-решения сделаны в партнерстве, потому что люди могут критиковать и находить ошибки друг друга, и использовать лучшие идеи”.
Джин Бартик, одна из первых программистов

“Пишите всё ПО двумя людьми за одним компьютером”
Кент Бек

Джин Бартик была одной из женщин-вычислителей на ЭНИАК и многими считается одной из первых программистов. Они выполняли задачи программирования еще до того, как появилось слово “программа”, и не существовало никаких примеров или книг, на которые можно было бы опираться — и они решили, что работать в паре — лучшее решение. Потребовалось более 50-ти лет, чтобы понятие “парное программирование” вошло в обиход: в конце 90-ых Кент Бек описал его в своей книге “Экстремальное программирование”. Там представлены методы гибкой разработки ПО для широкой аудитории, одним из которых как раз является работа в паре.

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

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

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

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

Как скооперироваться?

Стили

“Ведущий и штурман” (Driver and Navigator)

Эти классические определения ролей парного программирования могут так или иначе применяться ко многим подходам.

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

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

Идея подобного разделение ролей — получить две разные точки зрения на код. Предполагается, что “ведущий” думает тактически, о деталях, о строках кода, которые пишутся прямо сейчас. “Штурман” мыслит стратегически в роли наблюдателя. В его голове складывается общая картина.

Рабочий поток выглядит так:

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

“Пинг-понг”

Эта техника соответствует разработке через тестирование (Test-Driven Development (TDD) и подходит, когда задачи определены четко и могут быть покрыты тестовыми случаями.

• “Пинг”: Разработчик 1 пишет тест, который не проходит.
• “Понг”: Разработчик 2 пишет реализацию, которая позволяет тесту пройти.
• Разработчик 2 затем начинает новый «Пинг», то есть пишет следующий тест, который не проходит.
• Каждый “Понг” может сопровождаться совместным рефакторингом кода, прежде чем они начнут новый “провальный” тест. Таким образом, вы следуете стратегии “Красный — зеленый — рефакторинг”: пишете тест, который не проходит (“красный”), делаете так, чтобы он прошел по минимально необходимым значениям (“зеленый”) и далее делаете рефакторинг.

Хороший пример стиля “Красный-зеленый-рефакторинг” описан в книге “99 bottles of OOP” (Санди Мец и Катрины Оуэн, русского издания не найдено)

Парное программирование с сильной взаимозависимостью

Эта техника особенно полезна для передачи знаний. Она детально описана у Ллевелин Фалко (на английском).

Правило: “До того, как идея из вашей головы попадёт в компьютер, она ДОЛЖНА пройти через еще чьи-то руки”. В этом подходе “штурман” — это более опытный человек, а “ведущий” — новичок (в языке, в инструменте, исходном коде и тд). Знающий человек по большей части остается в роли наблюдателя и руководит новичком.

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

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

Совместное развитие

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

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

Планирование — какова наша цель?

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

• Понимание проблемы: Прочитайте задачу и поделитесь друг с другом, как вы ее понимаете. Проясните вопросы или возможные недопонимания с заказчиком. Если в вашей команде есть Критерии готовности задач ( Definition of Ready, подробнее — есть статья в русскоязычном Хабре), пройдитесь по ним и убедитесь, что всё готово к старту.
• Поиск решений: Устройте штурм и определите возможные решения проблемы. Можете делать это вместе или сначала разделиться и потом презентовать свои идеи друг другу. Это зависит от того, насколько хорошо уже можно обозначить решения, а также от ваших собственных предпочтений. Некоторые люди любят брать время на размышления с самим собой, другие любят “размышлять вслух”. Если кто-то менее знаком с областью или технологией, потратьте время, чтобы поделиться необходимым бэкграундом друг с другом.
• Планирование действий: Если вы нашли решение проблемы, какие шаги необходимо осуществить? Есть ли определенный порядок задач, который нужно помнить? Как вы будете это тестировать? В идеале запишите шаги в общий документ или на клеящиеся стикеры. Это поможет вам следить за ходом работы, или когда для решения задачи понадобится привлечь помощь со стороны. Записи также помогут легче запомнить то, что требуется сделать — мы очень часто недооцениваем, насколько много мы забываем чуть ли не на следующий день…

Поиск и изучение

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

Вот один из подходов к этой задаче при совместной работе:

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

Документация

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

Документация — прекрасный пример задачи, которая помогает дисциплинировать обоих партнеров. Обычно это задача, остающаяся напоследок, и та самая последняя вещь, которая не позволяет ощутить прекрасное чувство завершенности дела. Мы пропускаем её, или она “вылетает из головы”. Работа в паре заставляет нас быть честными по отношению к некоторым ценным, но дико раздражающим вещам. Зато мы будем очень благодарны себе за это в будущем.

Тайм-менеджмент

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

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

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

• Определите следующую задачу.
• Поставьте таймер на 25 минут. Можно использовать различные “помидорные” расширения в браузере или реальный кухонный таймер в виде помидорки.
• Работайте, не отвлекаясь.
• Сделайте паузу, когда сработает таймер — возьмите перерыв (5-10 минут).
• После 3-ех или 4-ех “помидоров” устройте длинный перерыв (15-30 минут).
• Во время коротких перерывов действительно отдыхайте: зарядитесь энергией, выпейте воды или кофе, сходите в уборную, подышите свежим воздухом. Не используйте эти перерывы для других рабочих вопросов, например, отправки почты.

Замена партнера

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

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

Другая причина — немного “встрястись” и внести разнообразие. У кого-то из вас может появиться “морская болезнь”, из-за слишком длительной работы друг с другом. Или вы работаете над чем-то очень утомительным и энергозатратным — замена даст одному из вас перерыв, а новый человек привнесет в работу свежий взгляд и энергию.

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

Мнения на то, сколько раз нужно меняться, расходятся. Некоторые верят, что каждые 2-3 дня, чтобы оставаться на том же уровне качества и получения новых знаний. Тем не менее, каждая замена требует временных затрат. Нужно время на то, чтобы найти нового человека, а также передать дела предыдущего партнера. Если на задаче не остается ни одного “человека-якоря”, увеличивается риск непонимания проблематики, потеряется контекст задачи, что приведет к последующим доработкам. Для большинства джунов выгодно дольше оставаться на одном проекте, где есть достаточно времени, чтобы погрузиться в тему и дать “уложиться” новым знаниям.

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

Термин “покажи и скажи“ по-разному используется в Agile-командах. То, о чем мы здесь говорим, — это регулярные митапы разработчиков, время на неделе, когда разработчики собираются вместе, обсуждают технические долги, новые знания, делятся фрагментами кода друг с другом и т. д.

Планирование дня

Парное программирование требует синхронизации и определенного уровня планирования. Если у вас не было времени, чтобы всё обдумать, это аукнется в будущем.

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

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

Организация рабочего пространства

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

• Убедитесь, что обоим партнерах хватает места, очистите стол при необходимости.
• Достаточно ли за столом места для двух стульев? Уберите подальше мусорные корзины и рюкзаки.
• Будете ли вы пользоваться одной или двумя клавиатурами? Также и с мышкой — одной или двумя? Здесь нет четкого правила, но мы бы порекомендовали попробовать разные варианты в разных ситуациях. Среди факторов — важна ли чистота пространства, хватает ли времени на обмен клавиатурой, как много свободного места.
• Дополнительный монитор или даже два. Если их нет, вы можете делиться скриншотами как при удаленной работе. При таком раскладе стоит использовать собственные ноутбуки с клавиатурами.
• Обсудите друг с другом, есть ли у вас предпочтения или даже требования (например, к экрану — увеличенный шрифт, высокая контрастность…).
• Если у одного из партнеров нестандартная клавиатура/IDE, удостоверьтесь, что второй партнер не против. Проверьте, можно ли временно изменить свои настройки на более стандартную конфигурацию во время совместной работы.

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

Удаленная работа в паре

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

Организационные моменты
Для подобного взаимодействия потребуется ПО с удаленным доступом, где нужно не только видеть, но также управлять чужим устройством (для обмена ролями). Большинство программ с видеоконференцсвязью поддерживают эту функцию, так что, если ваша компания уже имеет лицензионное ПО с удаленным доступом, сначала попробуйте его. Существуют также опенсорсные решения для видеозвонков с удаленным доступом, например, Jitsi. Как решение для случая с небольшой пропускной способностью сети попробуйте Ssh with tmux или расширение для онлайн-работы в Visual Studio Code.



Советы

• Не забывайте про видео. Для передачи информации люди также задействуют язык жестов и мимику, поэтому будет неплохо видеть одновременно и экран, и партнера. Некоторые программы идут с этой функцией; если у вашей нет, сделайте параллельный звонок, при котором получится увидеть друг друга.
• Планирование и проектирование. Используйте общие доски для визуализации, которые заменят вам бумагу или реальную доску.
• Звуки. Расположитесь в тихом месте и используйте наушники с микрофоном направленного действия. Если не получается избежать шума, поможет функция “нажмите, чтобы говорить”. Чтобы избежать отвлечений, подружитесь с шумоподавляющими наушниками.

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

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

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

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

В конце концов, кажется, что удаленное взаимодействие создает лишь одни препятствия. Но на самом деле во время него легче сосредоточиться — “отключиться” от лишнего помогают наушники.

Угоститесь Пончиками

Празднуйте, когда завершаете совместную задачу! “Дайте друг другу пять” может звучать глупо, но маленький ритуал поможет взбодриться и подготовиться к следующему заданию. Возможно, вы придумаете свой метод отпраздновать успех. Например, как Лара Хоган, которая отмечает достижения пончиками (англ.ресурс).

Чего лучше избегать

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

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

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

• “Печатай: “System, точка, print…”
• “Сейчас нам нужно создать новый класс под названием”...
• “Нажми “command+shift+O..."

Раздражительность
Применяйте “Правило 5 секунд”: если вы как “штурман” видите, что “ведущий” делает что-то “неправильное” и ждете пояснений, подождите 5 секунд перед произнесением чего-либо — возможно, “ведущий” уже подумал об этом, а вы зря прервёте его мыслительный процесс.

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

Клавиатура в заложниках
Следите, чтобы не “захватывать в заложники” клавиатуру: проверьте, вы случайно не контролируете её всё время, не давая партнеру хоть что-то напечатать?

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

Работа в паре по 8 часов
Некоторые команды преданы идее парного программирования и иногда работают в парах по 8 часов. По нашему опыту, это провальная схема. Во-первых, это очень утомительно. И, во-вторых, это не работает на практике, потому что есть много дел, помимо написания кода: проверка писем, собеседования, совещания, исследования/изучения и так далее. Поэтому планируйте день так, чтобы совместное написание кода не занимало 100% времени.

НЕТ идеального подхода

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

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