Как справиться с проблемами парного программирования?

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

С чем именно у них проблемы? Они не ладят, не понимают друг друга? Находятся ли они на разных уровнях программирования?

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

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

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

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

По моему опыту, лучший способ подойти к парному программированию - это детально обсудить, чего вы хотите достичь во время сеанса, прежде чем приступить к программированию. Это направит ваши мысли на один и тот же путь. Когда вы в чем-то не согласны, прекратите кодировать, обсудите это вдали от компьютера, попытайтесь найти общий язык и, самое главное, не отвергайте никаких идей, которые могут быть у вашего партнера. Делайте перерывы; не работайте в течение 2 часов подряд, старайтесь вставать или делать перерыв каждые 45 минут или около того.

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

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

Пересмотрите свои методы найма и убедитесь, что вы выбираете сотрудников, ориентированных на работу в команде.

В противном случае дыхание мяты.

-Адам

Второй вопрос мулоха - с какими вещами у них проблемы?

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

Мэри не ладит с Фредом, потому что Фред недостаточно знает о том, как здравомыслящие люди работают с базами данных? Фред не ладит с Джо из-за того, что Джо не купается так регулярно, как следовало бы? Джо не ладит с Мэри, потому что Мэри грубая сука? Если это так, вы можете почти гарантировать, что Фред, Джо и Мэри также раздражают остальную команду аналогичным образом.

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

Если команда плохо работает вместе, это не команда.

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

Другой подход - постоянно менять пары в схватке. Имейте таймер, который можно установить на 1/2/3 часа. Когда прозвенит звонок, поменяйте пары. Это имеет несколько эффектов:

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

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

Необязательно, чтобы все пары нравились друг другу. Важно то, что они эффективны. Учитывая, что пары меняются часто (для каждой карты или чаще), личность не так важна. Если кто-то не попадает в пары, и после тренировки все еще остается проблема, его или ее следует попросить покинуть команду.