А сработает это или нет, зависит от вас и вашей команды.
Парное программирование. Люди ненавидят или любят. Множество других авторов освещали общепринятые достоинства и недостатки. У меня была возможность поработать в компании, которая начинала как магазин парного программирования на полную ставку, но на полпути к этому времени почти полностью отказалась от этой практики.
Что такое парное программирование?
Парное программирование - это когда два разработчика работают вместе на одной рабочей станции. Один из них традиционно называется Драйвером, а другой - Навигатором. Драйвер кодирует, а навигатор проверяет код, дает советы, ищет ошибки и думает наперед.
Это также можно сделать удаленно. Единственное, что нужно, - это приличное подключение к Интернету, гарнитура и любое программное обеспечение для демонстрации экрана.
Вначале мы работали в паре для каждой задачи. Людям оставалось выполнять только несколько вспомогательных задач после того, как они их освоили. Мы сделали спаривание как локально, так и удаленно.
Парное программирование страдает от убывающей отдачи
Хорошие разработчики, следуя передовой практике, обычно пишут хороший код. Но не все знают все. Если вы объедините двух программистов, которые знают что-то, чего не знает другой, пара станет более продуктивной. В конце концов, знания у всех должны быть на одном уровне.
И это случилось с моей командой. Чем больше мы сочетались, тем меньше я чувствовал, что нам нужно создавать пары. По-прежнему было преимущество создания более безопасного кода с меньшим количеством ошибок, но стоимость была выше.
Ограничения на пары вне влияния
В паре сложно просто пойти и почитать что-нибудь в Интернете. Найдите другое решение проблемы, отличное от тех, которые вы пробовали.
Код, создаваемый такими парами, может быть лучше и безопаснее, чем код, созданный двумя людьми самостоятельно, без консультации с внешним миром. Однако люди с большей вероятностью пойдут и посмотрят, что придумала община.
Инновации и новые эксперименты были величайшими изменениями после отсутствия пары. Не то чтобы при объединении не было никаких инноваций, но они были ограничены.
Парное программирование требует дисциплины
Одна из лучших практик заключается в том, что водитель и навигатор должны часто переключаться, а пары также должны часто менять партнеров.
При спаривании иногда мы переключались только после выполнения задачи. Пары обычно имели импульс и старались использовать его наилучшим образом. Это повредило обмену знаниями и фактору автобуса. В конце концов, некоторые задачи были выполнены определенными парами более эффективно - одна из вещей, которую пара должна устранить.
Несмотря на то, что программу можно объединить в пары на любой рабочей станции, удобная станция парного программирования может быть оборудована двумя зеркальными экранами, а иногда даже двумя клавиатурами и мышью для каждого разработчика.
Два экрана - хорошая идея. Но я обнаружил, что наличие клавиатуры для навигатора увеличивает количество случаев «кражи ввода». Что сильно отличается от правильного переключения между навигатором и драйвером.
Парное программирование требует от команды дисциплины. Если они не могут сосредоточиться на своих ролях, парное программирование не сработает.
Это неподходящий инструмент для правильной работы
Для парного программирования не существует подходящей работы, потому что любую задачу можно выполнить в паре. Даже простые и понятные задачи могут выиграть от другой пары глаз. Но не каждая пара хорошо работает вместе. Парное программирование - правильный инструмент для правильной команды.
Некоторые люди преуспевают в паре, а другие нет. Создание пары может вызвать стресс, поскольку у всех разные темпы и стиль работы.
Парное программирование требует тщательного планирования. Руководители команд, менеджеры и программисты, которые хотят использовать парное программирование, должны создавать пары и команды таким образом, чтобы каждый разработчик работал так, как он лучше всего подходит для них.
Льготы для пары старший-младший требуют больших затрат.
Еще одно преимущество пары состоит в том, что она быстро приводит юниоров в норму. Но это может стоить дорого. Юниорам нужно уделять много времени за рулем, и из них обычно не получается хороших навигаторов. Юниоры могут в конечном итоге стать пассивными зрителями, особенно если есть необходимость делать что-то.
Сопряжение с младшим требует значительных усилий от старшего. Некоторым юниорам просто нужно проводить время с кодовой базой самостоятельно. Хотя они все еще собираются задавать вопросы, им может не понадобиться постоянное объединение.
Постоянная обратная связь незаменима
Не менее важны три вещи: скорость работы команды, удовлетворенность команды и удовлетворенность клиентов.
В другой команде, которая использовала парное программирование, удовлетворенность и скорость работы команды увеличились после того, как парное программирование было прекращено. Однако в моей команде мы не могли сказать, потому что не было надлежащих показателей. С моей точки зрения, оба пострадали.
Команду использовали для объединения программ, что в краткосрочной перспективе сказалось на производительности, но опять же без надлежащих показателей трудно сказать, когда и улучшилось ли когда-либо. Поскольку моя команда раньше приписывала очки истории исправлению ошибок, похоже, это не повлияло на общую скорость.
Скоро стали заметны и изменения в удовлетворенности команды. Особенно после того, как один из пожилых людей, который считал необходимым создание пары, ушел (однако я не могу сказать, насколько это было из-за того, что не спаривались).
Удовлетворение потребностей клиентов - сложная задача. Одна вещь, которую легко измерить, - это количество дефектов в программном обеспечении. Сопряжение часто может устранить значительное количество ошибок. Одна из ошибок нашей команды заключалась в том, что мы не отслеживали количество ошибок, обнаруженных в новых функциях, разработанных до и после того, как было принято решение о прекращении спаривания. Такая метрика была бы бесценной.
Так это работает?
Да, но это под силу не каждому. В правильной команде производительность увеличивается. Уменьшается количество дефектов в программном обеспечении и количество жалоб от клиентов. Знания в команде распределяются равномерно. Если всем нравится объединяться в пары, текучесть кадров в команде будет ниже.
Но команда должна заставить это работать. Я считаю, что люди, которым нравится работать в паре, работают в командах, созданных для парного программирования, и посвящают этому много усилий.
