Этот тип непрерывного парного программирования хорош?
Я работаю в компании, где меня заставляют заниматься парным программированием с парнем на 6 лет более опытным, чем я. В то же время мы работаем над одним и тем же кодом, дизайном или какой-то другой проблемой на одном компьютере.
Недостаток.
Это устраняет чувство принадлежности к результату. Настроение друг друга начинает влиять на обоих.
Преимущество.
Хороший продуманный результат и результат для компании.
Я хочу знать, как другие разработчики справляются с такой ситуацией.
7 ответов
Парное программирование похоже на фигурное катание
- Вам не нужно быть вместе 24x7, только когда вы на льду! (т.е. есть много частей проекта, которые выигрывают от того, что кодируются по отдельности, пара в конечном итоге перегруппируется для проверки / отладки, но не активно "конкурирует" за его завершение).
- все зависит от вашего партнера: он может работать очень хорошо или не работать вообще, независимо от навыков катания (или программирования).
- это требует правильного баланса честности и терпения (говорите, откровенно, но в нужное время, о вашем явном недостатке владения или о том, какое большое удовольствие вы испытываете от выполнения некоторых задач или от недостатка другой части и т. д.)
По этим причинам не должно быть никаких догм и предписаний в отношении парного программирования. Я лично очень поддерживаю эту практику, но я считаю, что программисты и менеджмент должны понимать требование "правильной химии", и не должно быть ни малейшего возмущения или суждения, когда пара плохо работает вместе,
Чтобы быть уверенным, программисты должны попробовать эту дисциплину в целом и серьезно поработать с конкретными партнерами (в течение достаточно длительных периодов, а также для различных типов проектов), прежде чем объявить личностный конфликт. Может также случиться, что данная пара лучше работает на определенных типах проектов.
Я так понимаю, вы хотите что-то владеть, взять на себя ответственность за модуль / набор модулей и назвать это своим? Это действительно зависит от вашего проекта, может быть, вам стоит посидеть с вашим PL и поговорить об этом. Таким образом, он мог бы взять на себя какую-то часть ответственности, вы все равно могли бы создать программу для пары.
Одним словом - ДА!
Но я думаю, что всем поначалу это трудно.
Большинство хороших программистов, которых я знаю в XP, говорили, что "мой босс заставляет меня спариваться". Ты не одинок!
Продюсер Если вы хотите больше ощущать лидерство, вы можете ввести в команду роль "продюсера истории". У каждой истории есть "продюсер" - это лицо, ответственное за то, чтобы убедиться, что конкретная история полностью завершена (тщательно продумана, согласована с заказчиком, протестирована, развернута и продемонстрирована). Быть продюсером может означать выработать значительную часть функциональности и почувствовать ответственность за что-то, даже если вы не работаете над этим каждый день в итерации. Разработчики подписываются, чтобы быть продюсером в начале итерации, написав свое имя на карточке истории.
- Спаривание означает, что люди могут видеть, в чем ты силен и в чем ты слаб. Требуется смелость, чтобы люди могли точно видеть, как вы поступаете, и требуется определенная степень доверия.
- Это означает, что есть определенный уровень компромисса - иногда вы слушаете, а иногда делаете и объясняете.
- Требуется время, чтобы развить навыки объяснения технических вещей, которые вы делаете - не только что, но и как сотрудничать с другими разработчиками.
- В этом есть социальное измерение. Проводя время с другими разработчиками, вы обнаружите, что у вас есть
Есть плюсы:
- Вы можете увидеть различные способы решения проблем.
- Вы научитесь лучше объяснять вещи.
- Спаривание гораздо разнообразнее - вы не застряли в одной и той же части кодовой базы.
- Когда разработчики учатся работать вместе, вы пишете лучший код и разрабатываете "командный стиль"
- Вы можете заняться вещами, которые обычно бывают за пределами вашего непосредственного набора навыков - например, сопряжение с администратором баз данных или графическим дизайнером. Здорово иметь представление о нескольких новых вещах.
Отрицательных:
- Выбор пар может быть сложным, и некоторым парам сложнее установить взаимопонимание.
- Некоторые "знают все" относятся к спариванию как к тому, что они говорят другим людям, что делать. Это действительно трудно заставить их сотрудничать должным образом.
- Очень сильный разработчик, с которым я работал, разочаровался, потому что он больше не был единственным, кто работал над определенной базой кода. Он потерял чувство собственности.
Я помню, как хотел создать парную программу, но я все еще чувствовал ужас в первые несколько недель.
До сегодняшнего дня я все еще чувствую себя истощенным после интенсивного парного общения - гораздо больше, чем просто программирование.
Вы привыкли к сопряжению через некоторое время. Иногда мне хочется обсудить "какой путь" с дизайном - вот когда я скучаю по паре… Я чуть не обернулся и спросил эту бабушку, которая вела у меня на поезде, однажды об объектном дизайне!;-)
Снижение собственности может рассматриваться как преимущество
Парное программирование, особенно когда вы часто меняете партнеров, в контексте гибкой команды отчасти предназначено для усиления коллективной собственности. Это уменьшает объем знаний (иначе говоря: увеличивает " номер грузовика " вашего проекта) и уменьшает отношение: "эта часть кода плохая, но это не моя проблема, потому что я ей не владею". С другой стороны, гибкие команды выбирают программу для команды, потому что считают, что она работает лучше всего.
Парное программирование повышает средний уровень команды / уровень опыта
Когда программисты спариваются, знания, навыки и опыт передаются между членами команды. Эта передача имеет тенденцию быть двунаправленной, если нет существенного несоответствия, как в вашем случае. Тогда это имеет тенденцию быть односторонним. Это одна из причин, по которой гибкие команды часто меняют пары.
Заставить людей, особенно программистов, беспокоить
Навязывание практики на людей, даже хорошая практика, само по себе является проблемой. Это особенно плохо, если вы заставляете программистов.
Если вы не можете решить проблемы людей, и вы не можете жить с ними, кто-то может пойти
Конечно, личности могут вызвать трения во время парного программирования. Но если люди не могут решить это зрелым образом, то я считаю, что это проблема людей, а не практики. Есть все еще разработчики, которые сильно предпочитают работать в одиночку и "владеть" частями проекта. Может быть трудно убедить их работать иначе. Если это не может быть решено, то это либо гноится, либо кто-то уходит добровольно, либо кого-то отпускают.
Я думаю, что главное преимущество с вашей точки зрения - это возможность учиться у кого-то более опытного.
Исключением является ситуация, когда ваш партнер менее компетентен, чем вы, несмотря на то, что у него больше опыта работы.
Есть несколько факторов, которые повлияют на то, как я отвечу на это:
Общая команда разработчиков - это только вы двое? Если это так, то вначале это может быть полезно, чтобы помочь вам освоить скорость и помешать одной из пары писать много кода, а другая ничего не знает об этом. Я не уверен, что я хотел бы видеть одну и ту же пару вместе так сильно, что вам все равно придется держаться вместе.
Вы работаете над новой разработкой или исправляете ошибки? Если новая разработка, то было бы хорошо, если бы пара глаз смотрела на код. С другой стороны, исправление ошибок не обязательно лучше всего делать с помощью пары, если только это не очень сложная проблема.
Вы можете рассматривать это как способ работать над тем, чтобы проявить терпение и насколько хорошо вы действительно понимаете кого-то другого. Может быть полезно быть настолько близким с кем-то, что вы могли бы почти закончить его предложения для них.
Там, где я работаю, у нас может быть парное программирование новых функций, и это, как правило, хорошо. Всего в команде около 7 разработчиков, поэтому может быть несколько пар и соло-работа. Были даже прозвища, данные некоторым парам, которые помогают команде придать сплоченность и связь. Обычно пара работает над историей, и когда история закончена, пара распадается, если нет другой истории, которую оба хотят сделать. Обычно я считаю полезным объяснять вещи и заставлять кого-то другого видеть мой поезд, или, если я даю обратную связь, так как у другой половины пары есть идея, которую я должен проверить и посмотреть, насколько хорошо это будет работать.
Вы решаете проблему очень быстро. Вы, вероятно, уменьшаете количество ошибок в процессе. в чем именно проблема?:
Считаете ли вы, что ваш более опытный партнер доминирует в процессе и лишает вас чувства ответственности за результат?