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

Зачастую можно услышать такое мнение:

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

Или же:

«Я замкнутый человек. Я бы не хотел постоянно общаться с партнером на работе».

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

И вот почему:

Преимущества:

# 1: Парное программирование ослабляет влияние Всезнаек

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

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

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

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

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

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

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

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

Правильное решение - соединить Всезнайку с другим программистом!

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

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

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

# 2: Парное программирование делает процесс адаптации потрясающим

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

Новым сотрудникам не нужно проходить «тренировочные лагеря» продолжительностью в неделю или следовать устаревшему руководству по настройке среды.

Новичкам просто назначают партнера по парному программированию и они начинают учиться!

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

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

Эти двое могут уравновесить друг друга.

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

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

# 3 Парные программисты создают кода больше, чем в два раза по сравнению с отдельными лицами, а парная работа отлично подходит для интровертов

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

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

К счастью, суть программирования сводится не к этому.

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

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

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

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

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

Парное программирование отлично подходит для интровертов. 80% программистов в Menlo идентифицируют себя как интроверты. Тем не менее, они любят метод парного программирования. Зачем? Интроверты любят людей, которые находятся на одной волне с ними.

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

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

Тем не менее, парное программирование не идеально.

Недостатки

# 1: парное программирование может усложнять простые задачи

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

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

Хотя это действительно может зависеть от пары. Иногда наличие партнера по паре может повысить моральный дух при работе над простой задачей.

# 2: парное программирование не полностью устраняет роль Всезнайки

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

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

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

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

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

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

# 3 Парное программирование держит сотрудников в чрезмерно напряженном состоянии

В Menlo многие сотрудники говорят, что покидают работу, чувствуя себя «умственно отсталыми»

Они утверждают, что в Menlo думают усерднее и дольше, чем на любой другой работе, которую они когда-либо имели.

Это потому, что невозможно расслабиться, когда у вас есть партнер по парному программированию. Наличие товарища по команде, который наблюдает за тобой весь день, держит тебя супер подотчетным. Трудно срезать углы. Трудно «отключиться» на работе.

Это и хорошо и плохо.

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

Вот почему в Menlo они следят за тем, чтобы пары программистов делали перерывы в течение дня. Утром сотрудники Menlo проводят мероприятие под названием «stand-up», где они делятся тем, над чем они будут работать в этот день. Во второй половине дня они проводят мероприятие под названием «walkies», где они гуляют по кварталу.

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

Как реализовать парное программирование в вашем рабочем пространстве

Заинтригованы парным программированием? Хотите попробовать? Вот как это сделать.

Хорошая вещь в парном программировании заключается в том, что он не должен быть методом «все или ничего».

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

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

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

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

No Comments