Я часто слышу, как люди говорят о том, что их работа продвигается более эффективно и плодотворно когда они остаются одни. Также я знаю, что некоторые идеи/методы, полезные для одного человека, могут оказаться вредными для другого. Тем не менее, я твердо верю во фразу, которая гласит: “одна голова хорошо, а две — лучше”. Нижеприведенные видео являются отличными примерами того, какой потрясающий результат получается, если два человека работают «слаженно». Первое видео — “Соната для фортепиано в 4 руки до мажор, K.381/123a” Моцарта, а второе — гитарная пьеса в четыре руки “Tico Tico no Fubá” Зекуньи де Абреу:
Конечно, музыка не единственная область, в которой сотрудничество двух и более людей может привести к успеху. Майкл П. Фаррелл, профессор социологии в Университете Буффало, провел исследование о тесных творческих группах и описал их в своей книге “Collaborative Circles: Friendship Dynamics and Creative Work.” В исследовании рассматривалась групповая динамика в шести коллаборативных кругах, таких как социальные реформаторы Элизабет Кэди Стэнтон и Сьюзен Б. Энтони, а также Клайв Стейплз Льюис, Дж. Р. Р. Толкин и Инклинги. Фаррелл писал: “Большинство хрупких и неустойчивых идей, положивших начало новому видению, возникли не тогда, когда вся группа была вместе, и не тогда, когда члены работали в одиночку, а в тот момент, когда участники сотрудничали и реагировали друг на друга парами.”
В истории сохранилось множество примеров, когда сотрудничество обеспечивало прочный каркас для достижения великих результатов: Моне и Ренуар, Пабло Пикассо и Жорж Брак, Бэтмен и Робин… список можно продолжать еще очень долго! На самом деле, за последние тридцать пять лет, около половины Нобелевских премий по физиологии и медицине были присуждены партнерам.
В книге “Powers of Two: Finding the Essence of Innovation in Creative Pairs,” Джошуа Вульф Шенк приводит цитату из интервью Джона Леннона, в котором тот говорит, что они по очереди с Полом Маккартни “писали хорошие биты или кусочки текста, вроде ‘I read the news today’ или что-нибудь похожее на этот отрывок”. Одному из них не хватало вдохновения на большее, пока не появлялся другой. Леннон продолжил: “Я пел половину текста, и в этот момент он вдохновлялся, чтобы написать следующий бит, и наоборот”. Время от времени любой из нас впадает в творческий кризис, но два человека редко делают это одновременно.
В Википедии определение парного программирования гласит:
Парное программирование — техника программирования, при которой исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. Один программист («ведущий») управляет компьютером и, в основном, думает над кодированием в деталях. Другой программист («штурман») сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они меняются ролями, обычно, каждые полчаса.
Ошибочно полагать, что парное программирование сводится к поочередному использованию компьютера или к тому, чтобы один из участников был учителем, а другой учеником. Наставнические отношения совсем не похожи на те, что возникают у двух людей, работающих вместе на равных условиях, даже если у одного из них значительно больше опыта. По своей сути, парное программирование вовлекает два ума к решению одной и той же проблемы, что позволяет добиться более быстрого и качественного результата, чем если бы один человек занимался этим в одиночку. С повышением качества проекта, позже появится и выгода. Сначала все может показаться неудобным, но, как и другие новые навыки, парное программирование требует определенного количества времени, чтобы привыкнуть. Парное программирование чем-то похоже на свидания — это социальный навык, который совершенствуется с опытом. Основная цель ПП заключается в стремлении совместно выполнять поставленные функции. Это подразумевает полную отдачу от каждого партнера, независимо от их корпоративного статуса. Многие считают, что идеальное парное программирование — это сидеть бок о бок перед одним монитором, двигая клавиатуру туда-сюда. Подробнее об этом позже…
В структуре парного программирования предусмотрено две роли: ведущий и штурман.
- Ведущий — это тот, кто держит руки на клавиатуре и пишет код.
- Штурман — это тот, кто следит и проверяет каждую строчку кода, по мере ее ввода.
Основная задача ведущего состоит в том, чтобы разобраться с тем, как запихивать в компьютер свои идеи. Однако главная цель ведущего — быть полезным штурману, оказывая поддержку и выказывая доверие. Ведущие должны высказывать свое мнение или подвергать сомнению те вещи, в которых у них возникают вопросы, но, поскольку их основная работа заключается в наборе кода, им может быть трудно думать на несколько шагов вперед. Хотя они и не полностью понимают задачу, это не мешает им работать более эффективно, чем штурманы.
С другой стороны, штурман работает с более подробным контекстом, поскольку ему нет необходимости вводить код. Основная задача штурмана — предоставить информацию ведущему в таком виде, чтобы та обрабатывалась им легко и непринужденно. Штурманы должны думать о проблеме с более концептуальным мышлением. Штурман должен оперативно предоставить ведущему указания, необходимые для реализации с приемлемым уровнем абстракции, чтобы ведущий мог ввести их наиболее эффективно. Поскольку навигатор думает о проблеме на более высоком уровне абстракции, он понимает общую задачу и направление, в котором им нужно идти.
Если у ведущего появляются идеи о том, что делать дальше, в то время как штурман руководит рабочим процессом, самое время поменяться ролями. Это может помочь остаться в гармонии друг с другом. Обоюдный обмен идеями во время мозгового штурма не только поможет уменьшить количество ошибок в ходе рабочего процесса, но и даст стимул к творческому подходу во время решения проблем. Ключевым моментом в парном программировании является тот, когда нужно сказать: “Давай сначала попробуем твою идею!”
Еще один совет, который я могу дать всем, кто программирует или только собирается программировать в паре: сделайте перерыв и задайте друг другу вопросы. Это поможет завязать содержательную беседу и лучше понять друг друга. Кроме того, перерывы идеально подходят для передачи клавиатуры туда-сюда.
Рабочий процесс и парное программирование
Во время поиска методик по организации рабочего процесса при парном программировании, я обнаружил, что существует несколько разных стратегий. Один из наиболее интересных подходов называется «Пинг-понг». По сути, этот подход выглядит примерно так:
- Программист “А” пишет тест и видит, что он провален.
- Программист “Б” переписывает код для того, чтобы успешно пройти тест.
- Программист “Б” пишет новый тест и видит, что он провален.
- Программист “А” переписывает код для того, чтобы успешно пройти тест.
- Вернуться к началу.
Не сказал бы, что это идеальный рабочий процесс, однако я не успокоюсь, пока не опробую его в деле.
Недавно я узнал от коллеги о том, что у Atom есть пакет под названием Teletype, который позволяет разработчикам делиться своим рабочим местом с членами команды, а затем совместно работать над кодом в режиме реального времени. Ваши коллеги смогут подключаться к вашему хосту в гостевом режиме и самостоятельно набирать и редактировать код в одной рабочей области вместе с вами. Когда разработчик на хосте открывает другой рабочий файл и начинает его редактировать, все “гости” автоматически перенаправляются в тот же файл. Я думаю, что это действительно классная функция, и я обязательно опробую ее в своем следующем проекте. Возможно, таким образом я смогу значительно повысить производительность своей команды.
Некоторые преимущества парного программирования:
- Парное программирование ускоряет процесс разработки проектов
- Ускоряет процесс адаптации новых членов команды
- Возможно обоюдное обучение/обмен опытом
- Коллектив становится более сплоченным
- Взаимный контроль ведет к снижению количества отвлекающих факторов, что в конечном итоге приведет к повышению производительности
Запомните несколько советов:
Очень важно меняться ролями в течение всего дня. Однако вовсе не обязательно следовать какому-то таймеру, так как рабочий процесс может нарушиться. Многие люди советуют меняться ролями, начиная от 1–2 минут и заканчивая 20–30 минутами.
«Период адаптации к парному программированию похож на поедание острого перца. В первый раз, когда ты пробуешь его, тебе может не понравится, потому что ты не привык к его вкусу. Однако чем больше ты его ешь, тем больше он тебе нравится». — Аноним
Вышеприведенная цитата нашла во мне отклик. Но вдохновение для написания этой статьи я получил от прочтения статьи в журнале The New Yorker, под названием “The Friendship That Made Google.” (Прим.ред.: “Дружба, которая сделала Google таким, каким мы знаем его сейчас.”). В статье подробно рассказывается о том, как Джефф Дин и Санджай Гемават стали старшими научными сотрудниками Google — первыми и единственными инженерами 11-го Уровня. Если два ведущих инженера Google смогли успешно изменить путь развития целой компании, а также всего Интернета в целом, значит существует сильная взаимосвязь между парным программированием и великими достижениями.
В заключение…
Льюэллин Фалько, наставник по гибкой методологии разработки, говорит: “Для того, чтобы идея нашла путь из головы в компьютер, она должна пройти через чужие руки. Этот стиль программирования направлен на рост общения и сотрудничества между людьми.” Основной вывод из его слов — общение и сотрудничество являются залогом успеха.
По своему опыту я могу сказать, что работаю более продуктивно в паре или в группе. Играя музыку, я предпочитаю выступать в ансамбле, чем быть сольным артистом. Дело не в том, что я во всем полагаюсь на другого человека(людей), а в том, что моя вера в себя растет в геометрической прогрессии тогда, когда я чувствую ответственность перед кем-то еще, а не перед самим собой. Кроме того, я питаюсь энергией других людей. Когда я разрабатываю программу в паре, моя производительность значительно увеличивается. В настоящий момент мои навыки показали, что в роли штурмана я гораздо лучше, чем в роли ведущего, но я планирую стать профессионалом в обоих. Надеюсь, после прочтения вы поймете, почему парное программирование полезно и почему оно будет полезным для ваших будущих проектов.
Перевод статьи Andrew Sproul: The Old Saying: “Two Heads are Better than One.”
