Я несколько раз пытался создать парное программирование, в том числе в организации, которая (кратко) рассматривала развертывание как обязательный процесс для всех инженеров (вы можете догадаться, насколько удачной оказалась эта идея). Лично я ненавидел это.
Причины, которые я перечисляю ниже, являются только моим субъективным опытом, и я не могу «измерить» их влияние в конкретных терминах. Но вот они все одинаковые
1 - Наличие «навигатора» и «водителя» помогает только в том случае, если первый вокал, а второй будет слушать.
Мы все встречали разработчиков, которые упрямы, ревностно относятся к какой-то теоретической проблеме или патологически неспособны - психологически - «выбросить» старую работу, когда кто-то предлагает проблему с ней. И все мы знаем людей, слишком застенчивых или неуверенных в себе, чтобы высказывать опасения или выдвигать на первый план дела.
Когда разработчики такого типа работают в паре, навигатор быстро берет на себя пассивную роль, и в результате вы получаете только программирование с автоматическим пересмотром кода. Это монументальная трата ресурсов.
2 - Спаривание мешает творчеству.
Вопреки тому, что раньше чувствовалось в отношении ценности «группового мозгового штурма», в наши дни все согласны с тем, что творческое познание требует независимости и автономии . Когда вы работаете в одиночку, вы можете быстро соединить какую-то сумасшедшую идею, чтобы увидеть, возможно ли это на самом деле. Вы можете без слов собрать какой-нибудь странный прототип, и если вы потерпите неудачу, это не имеет значения, потому что никто не знает .
Сравните это с сопряжением: когда я хочу опробовать какую-то новую концепцию, я должен убедить своего партнера, пошагово обсудить его реализацию и надеяться, что они не будут судить меня, если это не удастся. Такая среда токсична для создания новых идей.
3 - Самый низкий общий дизайн знаменателя.
Когда пара не может раскрутить новые идеи, как указано выше, или когда люди не могут договориться о каком-то фундаментальном принципе того, как должна быть разработана особенность, получается запутанная конструкция, которая пытается пойти на компромисс и никого не удовлетворяет.
Если вы объедините разработчика, который создает замечательные, красноречивые, небывалые абстракции функционального программирования, с быстрым и грязным уродом производительности, код, который они будут вместе создавать, обычно не будет ни ужасно элегантным, ни особенно быстрым.
4 - Отсутствие автономии и насильственной прозрачности.
Violent прозрачность является фразой я набрался от умеренно известной (и весьма спорной) полемики против методологии Scrum. Он описывает, как некоторые организации заражают разработчиков и относятся к ним с подозрением, обычно присущим непрофессиональным работникам.
Что бы вы ни думали о «вреде» того, чтобы сделать работу разработчиков полностью прозрачной (и вы, возможно, не согласны с тем, что это на самом деле вред), многие люди ценят их автономность и способность работать в одиночку, доверяя тому, чтобы делать правильные вещи. Это важная психологическая потребность, и принуждение разработчиков к объединению в пару (как я видел, по крайней мере, в одном магазине) оставит сотрудников встревоженными, расстроенными и отчужденными.
5 - Некоторые разработчики просто плохо играют в парах.
Некоторые люди не будут или не могут вести себя должным образом в парной среде. У них могут быть плохая гигиена, плохие рабочие привычки, абразивный характер, «громкий» и «интенсивный» характер или целый ряд других атрибутов, которые делают их хорошими отдельными работниками, но плохими программистами.
Вы можете решить это? На самом деле, нет. Изменить личное поведение сложно. Магазин парного программирования должен быть очень осторожен при найме на работу и уделять много времени тому, чтобы увидеть, как кто-то работает и смогут ли они хорошо работать со своими сверстниками. Однако жесткая дискриминация личности означает, что наем на работу займет больше времени, если вы не ослабите свои стандарты в отношении навыков и опыта.