company_banner

О плюсах парного программирования



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

    Парное программирование


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

    Так же и в парном программировании.

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

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

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

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

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

    Обучение новичка




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

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

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

    Шеринг знаний и ликвидация «Башни»




    Частая проблема многих команд — наличие незаменимых специалистов. Это чаще всего касается либо стартапов, либо малых изолированных групп разработчиков, которые тихо сами себе пилят какие-то фичи или отдельный проект. Незаменимый специалист — это тот, кто досконально и единолично разбирается либо в конкретном участке кода/проекта, либо только он имеет полное представление о том, как все это работает. Пул знаний о проекте такого специалиста еще называют «Башней знаний».

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

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

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

    Ликвидация «Башни знаний» имеет еще один неочевидный для многих плюс. Кроме децентрализации знаний о конкретных фичах и участках проекта, мы еще и снижаем нагрузку на разработчика, вокруг которого эта самая «Башня» изначально и была построена. Ведь чаще всего, если в команде есть незаменимый специалист, ему приходится часто работать в режиме на износ, с овертаймами, без выходных во время релизов и вообще, быть доступным 24/7. Все это постоянное давление рано или поздно приводит к профессиональному выгоранию или, в лучшем случае — желанию найти более спокойную работу.

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

    Решение сложных задач




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

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

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

    Смешанные задачи




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

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

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

    Итого


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

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

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

    Комментарии 17

      0
      А зарплату потом тоже пополам будут делить, так как планы были разные и занимались решением задачи только одного из коллег? )
        +6
        Если у вас принято планировать задачи не на команду, а на человека, то это не совсем хороший подход (особенно, если вы хотите в scrum). И в таком случаи, на мой взгляд, рано думать о парном программировании
          –2
          В scrum не хотим (про данный метод, справедливости ради, в статье и не упоминается).
          Есть команда, у команды есть TeamLead — он получает задачу на команду, дробит на части (составляет планы на месяц для каждого), следит за соблюдением сроков, делает CodeReview.
          Именно потому я и оставил свой первый комментарий что усомнился в применимости парного программирования в нашей модели программирования. У нас применяется мозговой штурм с бОльшим количеством участников и меньшим количеством затрачиваемого на совместную работу временем.

          Вероятно, это моя «детская травма» от учебы в гимназии, когда учителя физики и математики, видя в старших классах что ученики советуются на контрольной (а советуются именно про правильность предполагаемого метода решения задачи, делегируя одному роль «штурмана») задавала как раз тот самый вопрос: «Когда сдадите решения — ваши оценки тоже пополам делить?»
            +2

            Ок, даже если не говорить про scrum и agile, мне кажется очень странно и не правильной практика, когда получает и декомпозирует задачу только "тимлид", и потом их спускает вам. Но это отдельная история.


            Что касается применения парного программирования у вас. Я в статье попытался донести, что ПП не решение всех проблем. А инструмент, которым можно решать разные задачи. Который может быть полезен всем.
            Про деление зп не совсем корректный вопрос. Не должно же быть желания просто утилизировать ресурс программиста только на написание кода. Шаринг знаний, обучение коллег, пбр — это тоже работа. И вот такая работа, по моей практики, лучше получается в паре, чем в одиночку.

              +2
              Про обмен знаниями, обучение и т.д. — полностью согласен… ровно как и утилизацию в написание кода.
              Спасибо, теперь есть над чем задуматься.
                0
                Шаринг знаний, обучение коллег, пбр — это тоже работа.


                Подскажите, пожалуйста, что такое пбр.
                  0
                  Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта

                  Подробнее можно почитать можно тут, например
                0
                Вероятно, это моя «детская травма» от учебы в гимназии, когда учителя физики и математики, видя в старших классах что ученики советуются на контрольной (а советуются именно про правильность предполагаемого метода решения задачи, делегируя одному роль «штурмана») задавала как раз тот самый вопрос: «Когда сдадите решения — ваши оценки тоже пополам делить?»

                Контрольная — это как собеседование. Там цель выявить знания конкретного индивида. А работа — это кооперация, и там важен результат и эффективность его достижения, важны также и последствия и побочные эффекты выбранного способа. Вклад индивида важен, но только как кооперативная составляющая.

                  0
                  Ну так это и не Scrum, а XP.
                    0
                    Если практика парного программирования в принципе используется в команде, то ТимЛид просто закладывает её в объём работы при распределении, а то и в трудооценку.
                0
                А как насчет удаленного парного программирования? Для себя решил, что точно не мое, и ушел из компании, где ПП было обязательным. Проблемы коммуникации — задержки с ответом, плохое звуковое оборудование участников. В результате борешься не с проблемой, а со средствами связи и моя обычная производительность падала в несколько раз.
                  +3

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


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

                    0
                    Естественно надо сначала убирать проблемы с оборудованием, задержки и.т.д.
                    Но есть ещё проблема с удобным совместным доступом к коду.
                    Пока нашли более менее приемлемое решение во встроенном в Visual Studio Live Share.
                    Что используете вы?
                    +1
                    To vdovin_ds: Дмитрий, если когда-нибудь (или вдруг) попадете на Запад, постарайтесь поменьше употреблять в общежитии слово «джун» — сейчас это приравнивается, практически, у частому употреблению слова «Jew», или еще хуже — тут не скажу ;) В западных (а, точнее, американских) компаниях такой термин не употребляется от слова «вообще» — все ваши коллеги будут инженеры (а их «ранжир» будет в соответствии с company policy — то-ли software engineer II, или senior software engineer etc.), но junior-ов там не будет 100% (но могут быть interns — это другое дело).

                    Что же касательно «парного программирования», то задолго до того, как это стало «модным, молодежным трендом», подобный подход употреблялся в индустрии десятилетиями (просто без особого хайпа и паблисити). Дело тут в особенностях человеческого мышления: зачастую, когда рассказываешь/делишься идеей с кем-то другим, мысль неожиданно находит новый, «улучшенный» вариант или путь. В этом, собственно, и весь секрет («секрет Полишинеля»). Да, подобная практика весьма полезна, и лично я ее очень люблю; кстати даю новаторскую идею (опробуйте в деле!): вовсе не обязательно чтобы этот «кто-то второй», рядом, был умудренным «сеньором», архитектором или гуру, вовсе нет! Посадите рядом жену, ребенка (ничего не понимающих в программировании), и попробуйте развить им свою идею, которую вы собрались реализовывать в коде — сработает не хуже (а, возможно, и лучше), если бы рядом сидел умудренный годами и опытом программер. И, кстати, от того, что вы перейдете на «общежитейскую» лексику, у вас может открыться абсолютно иной взгляд на решение проблемы (со мной такое случалось неоднократно!).
                      +1
                      новаторскую идею

                      Эту идею можно еще сильнее обобщить, заменив ребенка на неодушевленный или даже несуществующий предмет — получится метод утенка.
                        0
                        «Метод утёнка» — прямой путь к безалкогольному пиву и резиновой женщине! :D Но, если серьезно, то неодушевленные предметы «не работают» (по крайней мере, для меня).
                        +2
                        Можно ещё проще:
                        Моя кошка замечательно разбирается в программировании. Стоит мне объяснить проблему ей — и все становится ясно.
                        John Robbins (с).

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

                      Самое читаемое