[Программирование, Управление разработкой, Управление персоналом, Карьера в IT-индустрии] О плюсах парного программирования
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет, это опять Дима Вдовин. В своей предыдущей статье об интеграции джунов в команду, я вскользь затрагивал тему парного программирования как эффективной практики обучения и передачи опыта. Теперь же я бы хотел более подробно поговорить о практиках парного программирования в командах. Различные их вариации я пробовал на разных проектах, и сегодня хотел бы просто поделиться, какие я вижу в этом плюсы, что дает этот подход.
Парное программирование
Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах.
Так же и в парном программировании.
Драйвер сосредоточен на написании кода, здесь и сейчас. В это время штурман держит перед собой всю картину целиком, проверяет, чтобы драйвер не делал ошибок, и говорит, куда и как ему двигаться дальше.
Единственное серьезное отличие от раллийных гонок в том, что в парном программировании драйвер и штурман должны периодически меняться местами. Распределение же функций совпадает практически полностью.
Именно полное включение в процесс обоих участников парного программирования отличает этот метод от других способов обучения и контроля. С одной стороны, мы не позволяем драйверу писать код полностью самостоятельно и не отдаем готовый «продукт» на ревью условного штурмана. При этом драйвер сосредоточен не только на конкретных строчках кода, но должен видеть создаваемый им участок в широкой перспективе. То же применимо и для нашего штурмана.
Кроме этой, классической схемы парного программирования, за годы существования индустрии было создано еще несколько эффективных подходов. Например, популярен подход «пинг понг» или «штурман на заднем сиденье». Некоторые вообще практикуют смешение разных техник. Это нормально. Эффективность того или иного метода зависит от поставленных целей и состава участников: кто участвует в паре, чего они хотят достичь, насколько опытны оба кодера. К слову, парное программирование вполне применимо не только в паре ментор-джуниор, о чем я говорил в прошлой статье, но и в паре двух опытных кодеров примерно одного уровня.
Далее давайте чуть более широко обсудим как раз варианты сетапов драйвер+штурман в зависимости от целей парного программирования.
Обучение новичка
Парное программирование отлично подходит для обучения новичков и чаще всего используется именно для этого. Однако при применении этого метода обучения вашего джуна вы должны понимать, что вы жертвуете скоростью разработки непосредственной фичи, если отработка происходит на реальном участке кода. При этом команда серьезно выигрывает в перспективе: парное программирование с опытным коллегой серьезно увеличивает скорость онбординга и обучения джуна.
Но в разрезе кейса «обучение новичка» не всегда фигурирует джун. Например, парное программирование может применяться для онбординга условного свеженанятого мидла, которого нужно быстро онбордить на проект. В этом случае скорость падает не так сильно, а ментором может выступать коллега, сопоставимый с новичком на проекте по уровню скилла. Тут уже речь идет о передаче опыта и знаний не в программировании, а именно знаний о конкретном проекте.
С другой стороны, кодинг в паре двух мидлов — чуть более рисковое мероприятие, нежеле пара джун+мидл или джун+синьор. Ведущий в паре двух мидлов должен подходить к процессу с большой ответственностью, но при соблюдении всех условий выигрыш для всей команды весьма ощутим.
Шеринг знаний и ликвидация «Башни»
Частая проблема многих команд — наличие незаменимых специалистов. Это чаще всего касается либо стартапов, либо малых изолированных групп разработчиков, которые тихо сами себе пилят какие-то фичи или отдельный проект. Незаменимый специалист — это тот, кто досконально и единолично разбирается либо в конкретном участке кода/проекта, либо только он имеет полное представление о том, как все это работает. Пул знаний о проекте такого специалиста еще называют «Башней знаний».
Незаменимый специалист или «Башня» — это опасный ботлнек, которого надо избегать любыми путями. Потому что банальный больничный лист во время интеграции новых фич в боевую часть проекта (или во время переезда, или в другой серьезный этап) — и работа команды парализована. Не говоря уже об увольнении подобных разработчиков.
Чтобы устранить такой ботлнек, незаменимым специалистам стоит делиться своими знаниями с другими разработчиками.
Как уже понятно, для шеринга знаний опять отлично подходит парное программирование. Только в этом случае мы получаем не повышение квалификации и онбординг новичка, а передачу знаний об аспектах проекта внутри самой команды. Если какую-то фичу делать в паре, то о ней будет знать уже как минимум два человека, плюс, в процессе написания, будет подтягиваться бэкграунд одного из участников пары.
Ликвидация «Башни знаний» имеет еще один неочевидный для многих плюс. Кроме децентрализации знаний о конкретных фичах и участках проекта, мы еще и снижаем нагрузку на разработчика, вокруг которого эта самая «Башня» изначально и была построена. Ведь чаще всего, если в команде есть незаменимый специалист, ему приходится часто работать в режиме на износ, с овертаймами, без выходных во время релизов и вообще, быть доступным 24/7. Все это постоянное давление рано или поздно приводит к профессиональному выгоранию или, в лучшем случае — желанию найти более спокойную работу.
Превентивное использование парного программирования — это еще и отличный способ избежать создания «Башен знаний» на ровном месте. Постоянная циркуляция знаний о фичах и разных участках проекта внутри команды — это нормальный процесс, который, к сожалению, начинают организовывать только в момент увольнения ключевого сотрудника. Правда, парное программирование не единственный способ борьбы с «Башнями» и повышения уровня понимания проекта внутри команды, но это уже совсем другая история.
Решение сложных задач
Парное программирование можно использовать как и инструмент локального брейншторма, то есть буквальное применение поговорки «одна голова хорошо, а две — лучше». Парное программирование отлично подходит для случаев, когда нужно реализовать сложную фичу или логику согласно бизнес-требованиям проекта. Тут мы уже не говорим о передаче знаний от ведущего к ведомому, а создаем систему из двух равнозначных по опыту и пониманию проекта разработчиков, которые объединяют свои усилия.
Некоторые разработчики могут возразить, что над сложными участками им комфортнее работать в одиночестве, но практика показывает, что два сильных кодера в паре с большей вероятностью дадут на выходе качественный код, чем работая по отдельности.
Сильная сторона парного программирования в таких ситуациях находится как раз за пределами процесса написания кода. Скорее, выигрыш достигается за счет возможности активно обсуждать на равных возможные пути решения проблемы — процесс написания кода в таком кейсе стоит на втором плане и не является проблемой. А вот как и что именно должно быть написано — и есть проблема. Возможность прямой коммуникации, обсуждения и обоснованного спора между двумя специалистами позитивно влияет на качество принимаемых решений. Также сокращается и время поиска удачного решения нашей задачи.
Смешанные задачи
Последний случай — сборная из всех выше описанных кейсов. Тут у нас два опытных разработчика с разными областями компетенций, которые объединяют усилия в работе над одной задачей. Возможно, один из них хорошо пишет код, а второй досконально знаком с требованиями проекта. Причем не обязательно, чтобы это были два программиста. Это могут быть пары кодер и QA-инженер или кодер и аналитик.
Тут мы получаем ситуацию чистого win-win: в случае смешанных задач каждый участник пары дополняет второго. Так мы выжимаем максимум из потенциала обоих специалистов, ликвидируя их слабости и используем только сильные стороны.
Решение смешанных задач при этом охватывает все ранее описанные нами кейсы: и онбординг, если речь идет о недостаточном знании требований проекта, и ликвидация «Башни», и решение сложного кейса.
Итого
Важно понимать, что парное программирование не является серебряной пулей и ответом на любые проблемы и вызовы разработки. Почти во всех случаях применение данного метода приводит к снижению скорости разработки, так что применять этот подход стоит осмотрительно.
Также нельзя забывать о человеческом факторе: если мы говорим об обучении джуна, то ментор в паре должен быть способен взаимодействовать с новичком на должном уровне, чтобы процесс обучения не превратился в избиение и насмешку. Если мы пытаемся ликвидировать «Башню», то состав пары должен быть подобран соответствующим образом, чтобы передача знаний проходила в нужном направлении. То же касается сложных и смешанных задач: вы не можете посадить двух рандомных девелоперов за один компьютер и ждать, то они выдадут вам готовое решение через N часов.
Но даже с учетом озвученных сложностей, парное программирование — это отличная практика, которая решает не только проблему онбординга и обучения новичков, но также позволяет ликвидировать пробелы в знаниях о проекте других участников команды или эффективно решить сложную задачу.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, CRM-системы] Интегрируем web-телефон в свою систему
- [Работа с видео, Машинное обучение, Искусственный интеллект] Nvidia показала генератор говорящих голов для видеоконференций из 2D-изображений
- [Анализ и проектирование систем, Управление разработкой, Управление проектами, Микросервисы] Скрытые расходы при переходе на микросервисы
- [Законодательство в IT, Карьера в IT-индустрии] Сенат США снимает ограничения на количество рабочих виз для высококвалифицированных рабочих
- [Python, Программирование] Как работает память в Python
- [Управление персоналом, Карьера в IT-индустрии, Удалённая работа] Убрать ковер и еду. Чек-лист перед онлайн-собеседованием
- [Учебный процесс в IT, Научно-популярное, Мозг] В IT-образовании не работают лекции. Давайте это признаем и начнем учиться правильно
- [Open source, Управление проектами, Развитие стартапа, Управление продуктом, Управление персоналом] Мы всё переписали на $HOTLANG, но стартап всё равно провалился (перевод)
- [Разработка игр, Машинное обучение, Карьера в IT-индустрии] Семь талантливых стажеров AI@Unity 2020. Часть 1 (перевод)
- [Машинное обучение, Научно-популярное, Искусственный интеллект] Кризис воспроизводимости исследований в области искусственного интеллекта (перевод)
Теги для поиска: #_programmirovanie (Программирование), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_rajffajzen (Райффайзен), #_parnoe_programmirovanie (парное программирование), #_ekstremalnoe_programmirovanie (экстремальное программирование), #_bashni (башни), #_peredacha_opyta (передача опыта), #_obuchenie (обучение), #_blog_kompanii_rajffajzenbank (
Блог компании Райффайзенбанк
), #_programmirovanie (
Программирование
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:23
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Всем привет, это опять Дима Вдовин. В своей предыдущей статье об интеграции джунов в команду, я вскользь затрагивал тему парного программирования как эффективной практики обучения и передачи опыта. Теперь же я бы хотел более подробно поговорить о практиках парного программирования в командах. Различные их вариации я пробовал на разных проектах, и сегодня хотел бы просто поделиться, какие я вижу в этом плюсы, что дает этот подход. Парное программирование Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах. Так же и в парном программировании. Драйвер сосредоточен на написании кода, здесь и сейчас. В это время штурман держит перед собой всю картину целиком, проверяет, чтобы драйвер не делал ошибок, и говорит, куда и как ему двигаться дальше. Единственное серьезное отличие от раллийных гонок в том, что в парном программировании драйвер и штурман должны периодически меняться местами. Распределение же функций совпадает практически полностью. Именно полное включение в процесс обоих участников парного программирования отличает этот метод от других способов обучения и контроля. С одной стороны, мы не позволяем драйверу писать код полностью самостоятельно и не отдаем готовый «продукт» на ревью условного штурмана. При этом драйвер сосредоточен не только на конкретных строчках кода, но должен видеть создаваемый им участок в широкой перспективе. То же применимо и для нашего штурмана. Кроме этой, классической схемы парного программирования, за годы существования индустрии было создано еще несколько эффективных подходов. Например, популярен подход «пинг понг» или «штурман на заднем сиденье». Некоторые вообще практикуют смешение разных техник. Это нормально. Эффективность того или иного метода зависит от поставленных целей и состава участников: кто участвует в паре, чего они хотят достичь, насколько опытны оба кодера. К слову, парное программирование вполне применимо не только в паре ментор-джуниор, о чем я говорил в прошлой статье, но и в паре двух опытных кодеров примерно одного уровня. Далее давайте чуть более широко обсудим как раз варианты сетапов драйвер+штурман в зависимости от целей парного программирования. Обучение новичка  Парное программирование отлично подходит для обучения новичков и чаще всего используется именно для этого. Однако при применении этого метода обучения вашего джуна вы должны понимать, что вы жертвуете скоростью разработки непосредственной фичи, если отработка происходит на реальном участке кода. При этом команда серьезно выигрывает в перспективе: парное программирование с опытным коллегой серьезно увеличивает скорость онбординга и обучения джуна. Но в разрезе кейса «обучение новичка» не всегда фигурирует джун. Например, парное программирование может применяться для онбординга условного свеженанятого мидла, которого нужно быстро онбордить на проект. В этом случае скорость падает не так сильно, а ментором может выступать коллега, сопоставимый с новичком на проекте по уровню скилла. Тут уже речь идет о передаче опыта и знаний не в программировании, а именно знаний о конкретном проекте. С другой стороны, кодинг в паре двух мидлов — чуть более рисковое мероприятие, нежеле пара джун+мидл или джун+синьор. Ведущий в паре двух мидлов должен подходить к процессу с большой ответственностью, но при соблюдении всех условий выигрыш для всей команды весьма ощутим. Шеринг знаний и ликвидация «Башни»  Частая проблема многих команд — наличие незаменимых специалистов. Это чаще всего касается либо стартапов, либо малых изолированных групп разработчиков, которые тихо сами себе пилят какие-то фичи или отдельный проект. Незаменимый специалист — это тот, кто досконально и единолично разбирается либо в конкретном участке кода/проекта, либо только он имеет полное представление о том, как все это работает. Пул знаний о проекте такого специалиста еще называют «Башней знаний». Незаменимый специалист или «Башня» — это опасный ботлнек, которого надо избегать любыми путями. Потому что банальный больничный лист во время интеграции новых фич в боевую часть проекта (или во время переезда, или в другой серьезный этап) — и работа команды парализована. Не говоря уже об увольнении подобных разработчиков. Чтобы устранить такой ботлнек, незаменимым специалистам стоит делиться своими знаниями с другими разработчиками. Как уже понятно, для шеринга знаний опять отлично подходит парное программирование. Только в этом случае мы получаем не повышение квалификации и онбординг новичка, а передачу знаний об аспектах проекта внутри самой команды. Если какую-то фичу делать в паре, то о ней будет знать уже как минимум два человека, плюс, в процессе написания, будет подтягиваться бэкграунд одного из участников пары. Ликвидация «Башни знаний» имеет еще один неочевидный для многих плюс. Кроме децентрализации знаний о конкретных фичах и участках проекта, мы еще и снижаем нагрузку на разработчика, вокруг которого эта самая «Башня» изначально и была построена. Ведь чаще всего, если в команде есть незаменимый специалист, ему приходится часто работать в режиме на износ, с овертаймами, без выходных во время релизов и вообще, быть доступным 24/7. Все это постоянное давление рано или поздно приводит к профессиональному выгоранию или, в лучшем случае — желанию найти более спокойную работу. Превентивное использование парного программирования — это еще и отличный способ избежать создания «Башен знаний» на ровном месте. Постоянная циркуляция знаний о фичах и разных участках проекта внутри команды — это нормальный процесс, который, к сожалению, начинают организовывать только в момент увольнения ключевого сотрудника. Правда, парное программирование не единственный способ борьбы с «Башнями» и повышения уровня понимания проекта внутри команды, но это уже совсем другая история. Решение сложных задач  Парное программирование можно использовать как и инструмент локального брейншторма, то есть буквальное применение поговорки «одна голова хорошо, а две — лучше». Парное программирование отлично подходит для случаев, когда нужно реализовать сложную фичу или логику согласно бизнес-требованиям проекта. Тут мы уже не говорим о передаче знаний от ведущего к ведомому, а создаем систему из двух равнозначных по опыту и пониманию проекта разработчиков, которые объединяют свои усилия. Некоторые разработчики могут возразить, что над сложными участками им комфортнее работать в одиночестве, но практика показывает, что два сильных кодера в паре с большей вероятностью дадут на выходе качественный код, чем работая по отдельности. Сильная сторона парного программирования в таких ситуациях находится как раз за пределами процесса написания кода. Скорее, выигрыш достигается за счет возможности активно обсуждать на равных возможные пути решения проблемы — процесс написания кода в таком кейсе стоит на втором плане и не является проблемой. А вот как и что именно должно быть написано — и есть проблема. Возможность прямой коммуникации, обсуждения и обоснованного спора между двумя специалистами позитивно влияет на качество принимаемых решений. Также сокращается и время поиска удачного решения нашей задачи. Смешанные задачи  Последний случай — сборная из всех выше описанных кейсов. Тут у нас два опытных разработчика с разными областями компетенций, которые объединяют усилия в работе над одной задачей. Возможно, один из них хорошо пишет код, а второй досконально знаком с требованиями проекта. Причем не обязательно, чтобы это были два программиста. Это могут быть пары кодер и QA-инженер или кодер и аналитик. Тут мы получаем ситуацию чистого win-win: в случае смешанных задач каждый участник пары дополняет второго. Так мы выжимаем максимум из потенциала обоих специалистов, ликвидируя их слабости и используем только сильные стороны. Решение смешанных задач при этом охватывает все ранее описанные нами кейсы: и онбординг, если речь идет о недостаточном знании требований проекта, и ликвидация «Башни», и решение сложного кейса. Итого Важно понимать, что парное программирование не является серебряной пулей и ответом на любые проблемы и вызовы разработки. Почти во всех случаях применение данного метода приводит к снижению скорости разработки, так что применять этот подход стоит осмотрительно. Также нельзя забывать о человеческом факторе: если мы говорим об обучении джуна, то ментор в паре должен быть способен взаимодействовать с новичком на должном уровне, чтобы процесс обучения не превратился в избиение и насмешку. Если мы пытаемся ликвидировать «Башню», то состав пары должен быть подобран соответствующим образом, чтобы передача знаний проходила в нужном направлении. То же касается сложных и смешанных задач: вы не можете посадить двух рандомных девелоперов за один компьютер и ждать, то они выдадут вам готовое решение через N часов. Но даже с учетом озвученных сложностей, парное программирование — это отличная практика, которая решает не только проблему онбординга и обучения новичков, но также позволяет ликвидировать пробелы в знаниях о проекте других участников команды или эффективно решить сложную задачу. =========== Источник: habr.com =========== Похожие новости:
Блог компании Райффайзенбанк ), #_programmirovanie ( Программирование ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ), #_karera_v_itindustrii ( Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:23
Часовой пояс: UTC + 5