Pair Programming

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

Я часто слышу:

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

Или:

«Я интроверт, мне было бы сложно постоянно работать с другим человеком».

Да, это справедливо. Если бы я не попробовал парное программирование, скорее всего, я согласился бы с этими высказываниями.

Не так давно я занимался разработкой ПО в Menlo Innovations — в этой компании не принято самому писать код. Хочешь работать над кодом продукта? Найди себе партнера. 

Поработав у них несколько месяцев, я подсел на парное программирование. Мне кажется, что парное программирование — это отличное решение во многих ситуациях.

Давайте разберемся, почему.

Плюсы

#1: Парное программирование помогает решить проблему «башен знаний»

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

Они знают весь код, как свои пять пальцев. Именно к ним обращаются, когда нужно срочно добавить новую функцию или устранить множество багов.

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

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

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

Авторы статей о технологиях и бизнесе усугубляют ситуацию: в своих статьях они предлагают неправильные стратегии решения проблемы «башен». 

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

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

Правильное решение — поставить «башню знаний» в пару с другим программистом. 

Так передача знаний будет незаметной. Если кто-то неделю проработал над кодом в паре с «башней», у «башни» больше нет монополии на знания об этом коде. 

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

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

#2: Парное программирование помогает новым сотрудникам адаптироваться

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

Новичкам не нужно проходить стажировку длиной в несколько недель, не нужно изучать устаревшие инструкции и руководства.

Новичок просто объединяется в пару с другим программистом и начинает учиться.

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

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

Если объединить таких сотрудников в пару, они отлично дополнят друг друга. 

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

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

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

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

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

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

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

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

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

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

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

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

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

Такое сотрудничество не только полезно, это еще и весело. Вдвоем проще решать рабочие проблемы, это мотивирует.

Тем не менее, у парного программирования есть свои недостатки.

Минусы

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

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

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

Все зависит от пары: иногда два программиста в паре могут мотивировать друг друга при работе с простыми задачами.

#2: Парное программирование не полностью решает проблему «башен знаний»

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

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

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

Я все еще считаю, что объединение «башни» в пару — это лучшее решение. Это намного лучше, чем другое распространенное решение— увольнение или понижение «башни». 

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

Парное программирование не устраняет проблему «башен» полностью. Тем не менее это лучшее решение в долгосрочной перспективе.

#3 Парное программирование выматывает 

По словам сотрудников Menlo, в конце рабочего дня они «не в состоянии думать».

Они считают, что в Menlo им приходится работать интенсивнее, чем в других компаниях. 

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

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

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

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

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

Как перейти на парное программирование

Понравилось парное программирование? Хотите попробовать? Тогда вам повезло. 

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

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

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

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

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

Перевод статьи Max Albert: The Pros and Cons Of Pair Programming