Comments 9
Думаю, что есть проблема в самой модели. Начиная со стоимости задачи, которая в реальном мире часто декомпозируется и разделяется по исполнителям, которые обладают нужными знаниями.
Парно кодить это не только сложение компетенций по направлениям (например, GO и SQL), но более долгая концентрация, возможность обсудить что-то с тем, кто всегда в контексте. Ещё не обязательно иметь одинаковый грейд. Меня, например, работа с джунами отлично бустит и их, я надеюсь, тоже.
Парно кодить это не только сложение компетенций
С этого публикация и начинается. Что все сложно. Но бизнес по факту интересуют обычно только человеко-часы. И их же проще всего смоделировать.
Ещё не обязательно иметь одинаковый грейд
Возможно, я окуклился в энтерпрайзе, но уже лет как семь или больше джунов видел только на собеседованиях, безуспешно пытающимися выдать себя за миддлов. Один работодатель гордился корпаративными стажировками, но тех стажеров или их кода ни в одной продуктовой команде в глаза не видели. Работают люди уровня миддл и выше. Процентов 90-95 примерно одного уровня. Другие просто не проходят все этапы найма. Так что предпосылка одинаковых разработчиков продиктована не только стремлением к упрощению, но и личным опытом.
Думаю, что есть проблема в самой модели
Остальные немногочисленные предпосылки (ограниченность набора навыков, невозможность владения в совершенстве всеми ими и трудности про недостаточном владении) исходят из здравого смысла. Модель проста как пять копеек, просто воплощение программистского принципа KISS. Проблем бы ей как раз добавили дополнительные абстракции и предположения (бритва Окама).
Вывод делается тоже очень осторожный. Менеждеры как от огня, зажмурившись, шарахаются от ПП, а если присмотреться, то потенциально оно может быть целесообразно с точки зрения временных затрат при некоторых условиях. Каких - вопрос для отдельного изучения.
в реальном мире часто декомпозируется и разделяется по исполнителям, которые обладают нужными знаниями
В жизни все исполнители всегда обладают всеми знаниями хотя бы на уровне "где-то что-то слышал, сейчас поисковик/ИИ спрошу". И далеко не каждый проскочивший найм и испытательный срок признается, что местами не дотягивает. Как объективно определять нужного исполнителя? Что делать с командой, если на все задачи нужным окажется один и тот же человек?
Кстати, про декомпозицию в статье тоже можно найти.
Менеждеры как от огня, зажмурившись, шарахаются от ПП, а если присмотреться, то потенциально оно может быть целесообразно с точки зрения временных затрат при некоторых условиях. Каких - вопрос для отдельного изучения.
Боюсь, что ни в каких условиях, покуда менеджеры рассуждают в "ресурсной парадигме". Им и так-то сложно со всеми этими "хэдкаунтами", "степенью загрузки" и "человекочасами", а Вы тут со своей синергией лезете. Мой опыт показывает, что до большинства даже не доходят базовые выводы из теории массового обслуживания, а-ля "если систему нагружать под максимум, то задержки улетают в небеса". Во главу угла ставится принцип "во что бы то ни стало нагрузить каждого", иначе, якобы, люди будут зря зарплату получать. А когда получаем задержки, то надо просить больше людей. Какое тут ещё ПП, ну?
, где можно 
, и копи-пасту спагетти-кода у людей с опытом 10+ лет.Коснусь всё же недочётов модели. В некоторых режимах ПП происходит вот какой интересный эффект.
У отдельного программиста ресурс внимания, "рабочая память", имеет достаточно ограниченный объём, и в рамках одиночной работы в эту ограниченную память приходится по очереди загружать разные аспекты задачи. Частое переключение между разными аспектами (например, между низкоуровневым кодом и общей архитектурой, или между требованиями и ограничениями) приводит к когнитивной нагрузке и замедляет работу.
А вот если над кодом работают два человека, то они могут разделить эту нагрузку на двоих. Например, в режиме "водитель+навигатор" один человек ("водитель") фокусируется на решении текущего шага задачи, а второй ("навигатор") тем временем планирует следующий шаг и следит, чтобы решение в целом вписывалось в требование. Как результат, у каждого участника нагрузка становится меньше, переключений становится меньше, и работа делается быстрее и качественнее.
Т.е., сам подход "у разных людей разные скиллы", безусловно, правильный, но далеко не полный. Излишняя простота модели может приводить к появлению иллюзии того, что всё остальное несущественно. Типа: на локальных масштабах поверхность земли кажется плоской, так давайте и глобально считать Землю плоской. Модель же проста как пять копеек!
del. <не туда>
Ну и название статьи 😂
"Спаривание разработчиков" - это что-то из области биологии, а не программирования :).
Спаривание разработчиков в интересах бизнеса, или узкий взгляд на парное программирование с ограниченной точки зрения