Многие программисты скептически относятся к парному программированию: технике разработки программного обеспечения, при которой за одним рабочим местом работают два программиста.
Я часто слышу:
«Звучит как пустая трата денег: команда из двух программистов, сидящих за разными компьютерами, напишет в два раза больше кода».
Или:
«Я интроверт, мне было бы сложно постоянно работать с другим человеком».
Да, это справедливо. Если бы я не попробовал парное программирование, скорее всего, я согласился бы с этими высказываниями.
Не так давно я занимался разработкой ПО в Menlo Innovations — в этой компании не принято самому писать код. Хочешь работать над кодом продукта? Найди себе партнера.
Поработав у них несколько месяцев, я подсел на парное программирование. Мне кажется, что парное программирование — это отличное решение во многих ситуациях.
Давайте разберемся, почему.
Плюсы
#1: Парное программирование помогает решить проблему «башен знаний»
«Башни знаний» — это лучшие работники компании, которые негативно влияют на продуктивность всей команды.
Они знают весь код, как свои пять пальцев. Именно к ним обращаются, когда нужно срочно добавить новую функцию или устранить множество багов.
«Башни знаний» — это проблема, потому что вся остальная команда слишком сильно полагается на них. Чаще всего, «башни знаний» слишком загружены на работе, потому что к ним постоянно приходят с различными вопросами. Они часто работают сверхурочно, иногда даже по выходным. Как только «башня знаний» принимает решение уволиться, это ставит компанию в затруднительное положение: никто в команде, кроме «башни знаний», не разбирается в коде продукта настолько хорошо.
«Башни знаний» — это опасный замкнутый круг. Все остальные программисты активно обращаются к ним за помощью. Именно поэтому «башня знаний» все больше изучает код продукта, все больше работает над ним и все больше в нем разбирается. Это увеличивает интеллектуальный разрыв между членами команды.
«Башни» снижают мотивацию команды: все остальные чувствуют себя некомпетентными по сравнению с ними. Более того, работа всей остальной команды встает на целый день, если «башня» возьмет отгул.
Авторы статей о технологиях и бизнесе усугубляют ситуацию: в своих статьях они предлагают неправильные стратегии решения проблемы «башен».
Все авторы, от Ленсиони до Тейла, рассказывают, как они уволили или понизили своего лучшего работника, и продуктивность всей остальной команды резко выросла. Они рассказывают, как поначалу сложно было без «башни», но мотивация всей остальной команды намного важнее. Конец.
Это в корне неверный подход к бизнесу. Во-первых, неправильно наказывать лучшего работника за то, что он хотел принести пользу команде. Во-вторых, довольно скоро в такой команде появится новая «башня».
Правильное решение — поставить «башню знаний» в пару с другим программистом.
Так передача знаний будет незаметной. Если кто-то неделю проработал над кодом в паре с «башней», у «башни» больше нет монополии на знания об этом коде.
«Башня» может все еще оставаться лучшим работником, но теперь, если «башня» уволится или уйдет на больничный, компания не столкнется с негативными эффектами, который я перечислил выше: вся остальная команда сможет положиться на того, с кем работала «башня».
Если каждую неделю менять партнера «башни», то со временем все остальные программисты станут лучше разбираться в коде своего продукта и смогут почувствовать себя компетентными и важными членами команды. Мотивация всей команды поднимется.
#2: Парное программирование помогает новым сотрудникам адаптироваться
При парном программировании знания незаметно передаются от одного партнера к другому, что помогает новым сотрудникам влиться в проект.
Новичкам не нужно проходить стажировку длиной в несколько недель, не нужно изучать устаревшие инструкции и руководства.
Новичок просто объединяется в пару с другим программистом и начинает учиться.
Если в компании принято использовать парное программирование, у новичка всегда будет наставник, у которого можно учиться: в такой ситуации новый сотрудник быстро разберется в базе исходного кода и начнет приносить пользу компании.
У новых сотрудников достаточно навыков программирования, но им не хватает понимания контекста, в котором существует база исходного кода. Те, кто долго работают над проектом, прекрасно понимают контекст, но они иногда халтурят, чтобы работа шла быстрее.
Если объединить таких сотрудников в пару, они отлично дополнят друг друга.
(Справедливости ради скажу, что новички тоже часто халтурят. Тем не менее, опытный сотрудник в паре с новичком будет меньше халтурить и больше стараться, показывая пример новичку).
Обычно, новички не приносят никакой пользы компании в первый месяц работы: они изучают контекст, в котором идет работа над исходным кодом. В случае парного программирования у новичков есть возможность приносить пользу компании с самого первого дня.
#3 Программисты в паре пишут в два раза больше кода, и такая работа подходит интровертам
Давайте честно: большую часть времени программисты тратят не на само написание нового кода, а на отладку, тестирование, разработку стратегии и т.д.
Если бы работа разработчика заключалась в том, чтобы написать десять тысяч бессмысленных слов в день, то да, было бы эффективнее посадить двух программистов за два разных компьютера и дать им задачу непрерывно печатать.
К счастью, разработка ПО выглядит совсем не так.
Большую часть времени мы тратим не на написание кода, а на обдумывание.
Время на отладку может увеличиваться в геометрической прогрессии. Если кто-то в команде знает, как исправить ошибку, отладка занимает несколько секунд. Если никто не понимает, в чем проблема, отладка может длиться минуты, часы, а иногда и дни.
Два программиста за одним рабочим местом, столкнувшись с проблемой, решают ее в два раза быстрее. Более того, они реже обращаются за помощью к другим членам команды.
Команда из двух программистов будет реже отвлекать других незначительными вопросами. Если хотя бы у одного есть идея, как исправить ситуацию, то они сначала попробуют сами, а уже потом попросят помощи.
Более того, они будут охотнее обращаться за помощью, если она нужна. Если работающий в одиночку программист не может решить какую-то проблему, ему не очевидно, нужно ли обращаться за помощью: вдруг ее можно решить одним google-запросом. Работающим в паре программистам это более очевидно: если они вдвоем не справились, значит им определенно нужна помощь.
Парное программирование подходит интровертам. В компании Menlo 80% программистов называют себя интровертами, тем не менее, им нравится работать в паре. Почему? Потому что интровертам нравится работать сообща с людьми, похожими на них самих.
Программисты в паре думают об одном и том же, работают над одним и тем же кодом, задаются одними и теми же вопросами.
Такое сотрудничество не только полезно, это еще и весело. Вдвоем проще решать рабочие проблемы, это мотивирует.
Тем не менее, у парного программирования есть свои недостатки.
Минусы
#1: Программистам в паре сложнее выполнять простые задания
Если нужно исправить простой баг или реализовать какую-то простую функцию, довольно дорого ставить двух программистов на такую задачу. Более того, паре программистов будет сложно с интересом выполнять работу, которая не требует обдумывания. Если ваша компания много занимается тестированием и интеграцией, скорее всего, парное программирование слишком дорого вам обойдется.
Парное программирование может усложнить выполнение простых задач, но я не думаю, что это большой недостаток.
Все зависит от пары: иногда два программиста в паре могут мотивировать друг друга при работе с простыми задачами.
#2: Парное программирование не полностью решает проблему «башен знаний»
Многие авторы статей о парном программировании преувеличивают его влияние на «башни знаний». Некоторые утверждают, что оно полностью решает проблему «башен». Соглашусь, парное программирование во многом помогает облегчить ситуацию, но не устраняет ее полностью.
В любой команде есть человек, который лучше всех в чем-то разбирается. В этом нет ничего плохого, желание накапливать важные знания довольно естественно.
Парное программирование не может устранить это естественную для людей черту. Всегда найдутся люди, которые захотят обладать монополией на знания.
Я все еще считаю, что объединение «башни» в пару — это лучшее решение. Это намного лучше, чем другое распространенное решение— увольнение или понижение «башни».
Увольнение лучшего сотрудника может быть выгодно в краткосрочной, но в не долгосрочной перспективе: такие меры побуждают сотрудников работать хуже.
Парное программирование не устраняет проблему «башен» полностью. Тем не менее это лучшее решение в долгосрочной перспективе.
#3 Парное программирование выматывает
По словам сотрудников Menlo, в конце рабочего дня они «не в состоянии думать».
Они считают, что в Menlo им приходится работать интенсивнее, чем в других компаниях.
Так происходит, потому что работая в паре, сложно расслабиться, нужно все время быть сосредоточенным, сложно схалтурить, отвлечься.
Это и хорошо, и плохо.
С одной стороны, важно оставаться сосредоточенным на работе. С другой стороны, не менее важно иногда отвлекаться и смотреть на работу свежим взглядом.
Именно поэтому в Menlo принято устраивать перерывы в течение дня. Утром сотрудники Menlo собираются на планерку, во время которой они обсуждают, над чем они сегодня работают. Днем они делают перерыв на прогулку.
Такие перерывы в работе чрезвычайно важны для компании, которая хочет внедрить парное программирование.
Как перейти на парное программирование
Понравилось парное программирование? Хотите попробовать? Тогда вам повезло.
Плюс парного программирования в том, что оно необязательно должно работать по принципу «все или ничего».
В Menlo приняли радикальное бизнес-решение, что все должны работать парами. Однако, это не обязательно. Если вы работаете в более консервативной компании, вы можете объединиться с коллегой и поработать в паре над какой-то одной важной задачей.
Более того, если ваша компания работает, используя agile-методы, это тоже хороший повод объединиться с коллегой.
Такие полумеры помогают попробовать парное программирование, не тратя много ресурсов. После такой попытки можно сравнить парное и обычное программирование и понять, что больше подходит компании.
Если вы хотите попробовать, я бы порекомендовал вам начать не с простых, неважных и коротких задач, а с долгих, сложных и критически важных: именно на таких задачах видно, насколько эффективно парное программирование.
Специально для сайта ITWORLD.UZ. Новость взята с сайта NOP::Nuances of programming