Около года назад руководитель моей группы решила, что она начнет делегировать задачи мне и коллеге, которые нужно решать в паре. Все началось просто отлично, это была наша первая работа в паре, и мы пытались адаптироваться, и мы вроде как разобрались во всем, и начали получать преимущества от парной работы примерно через неделю. Но дело в том, что, может быть, мы не слишком совместимы, может быть, мы не думаем одинаково, но когда мы расходимся во мнениях по поводу двух жизнеспособных решений, часто кажется, что обсуждение разногласий непродуктивно, и мы зацикливаемся на мелочах без взаимного согласия. решение, и при достаточном обсуждении это становится утомительным.
Так или иначе, по мере того, как тянулись месяцы, необходимость постоянно сидеть вместе и работать бок о бок стала утомительной, поэтому мы привыкли каждый работать над разными частями задачи, или один работал, а другой не слишком активно участвовал. . У нас очень похожие уровни навыков, поэтому в конце концов мы просто обсуждаем, что нужно сделать, а затем один делает это, пока другой ждет, вмешиваясь только в том случае, если возникает что-то неожиданное. Мы как бы выгорели друг из друга, по крайней мере, мне так казалось. Я попытался поднять эти опасения со своим начальством, и они отреагировали, спросив о конкретных причинах, почему мы устали, и я не мог толком объяснить, поэтому они в основном намекали, что мы просто делаем это неправильно, и просто «дайте время», и мы разберусь с вещами.
Прошел уже почти год. Я взял отпуск, и по возвращении мы вернулись к работе в паре, и у нас были действительно продуктивные первые несколько недель, мне казалось, что все, что мне нужно, это перерыв, но теперь мы снова на расстоянии и не работаем вместе, хотя мы технически сопряжение.
Я хотел бы знать, это обычное дело? Компания делает что-то не так или у нас неправильная пара? Как часто одна и та же пара работает вместе целый год? Что с этим делать?
Брак парного программирования — это антипаттерн парного программирования. Вы не должны всегда быть в паре с одним и тем же человеком неделями, даже днями.
Вот выдержка из содержания Agile во флеш-карте, связанной с парным программированием :
Весь производственный код
Должна быть разработана парой
Обе стороны вносят свой вклад в решение
частая смена ролей между «водителем» и «штурманом».
Часто меняйте пары
три раза в день и более
Развивайтесь на удобном рабочем месте
который вмещает двух человек бок о бок
Завершите сопряжение, когда устанете
Ограничение не более чем 3/4 вашего рабочего дня
И подробный вариант:
Мне нравится возможность сидеть и программировать как половина пары. Я уверен, что это не для всех, но я тоже когда-то был одним из тех, кто сопротивлялся этой идее. Частью моего сопротивления был страх, что люди могут понять, что я знаю не так много, как они думали. Я преодолел это. Многие люди, которые приложили честные усилия для создания пар (сделанных по правилам), обнаружили, что это на самом деле очень приятно и эффективно.
Еще одним распространенным сопротивлением является непонимание того, что такое спаривание и какие преимущества вы можете от него получить. Чтобы быть эффективным, вы не можете просто сидеть рядом с кем-то еще и ожидать, что произойдет волшебство. Правила просты, но не очевидны. Мне совершенно понятно, почему кто-то ненавидит спаривание после того, как сделал это плохо. Наименее очевидное правило — «чаще меняйте пары». Типичная концепция состоит в том, что пары женятся на бедре в течение нескольких дней или даже недель. Нет, я бы перерезал запястья Тима, а он перерезал бы мне, если бы это было так. Вместо этого мы часто меняем пары. Помимо утомительной работы с одним человеком в течение всего дня, одна из наших целей при переключении часто заключается в том, чтобы не два, а как минимум три человека способствовали решению задачи.
Обратной стороной частого переключения являются накладные расходы на переключение контекста. Требуется время, чтобы объяснить вещи! Но именно здесь проявляется синергия исходных практик XP: если вы хорошо работаете с TDD, следуя простому дизайну, быстро пройти тест не так уж и сложно. И на самом деле необходимость минимизировать накладные расходы на переключение контекста — это тонкая сила, направленная на улучшение качества кода.
Дэн Пичелман
пользователь8365
Сандра К
bpromas