Комментарии 19
Прям отвратительная статья, зря потратил время. Особенно вот это место: "Участники процесса меняются ролями раз в полчаса, час или реже — всё зависит от опыта работы в паре, навыков, самой задачи и других нюансов". Неужели?? Может разъясните что это за нюансы, а не будете писать о том "Как появилось парное программирование".
Бывают и психологические барьеры: не все готовы по шесть часов в день (обычно столько получается) общаться с другим человеком.
А я не готов общаться даже час
Применяли экстремальное программирование (по полной методологии, не только парное) в небольшом коллективе - 7 человек.
Зашло не сразу, но результатами остались довольны даже те, кто сперва весьма скептически отнёсся к этой идее.
Вероятно, сыграло роль то, что коллектив давно знакомый и дружный а так же то, что уровень каждого был достаточно высок.
Для такой работы нужно что бы оба программиста были примерно с одним бекграундом за спиной, психологические совместимы и уважали мнение друг друга. Это сложно. Очень.
Исследование потрСающее. Пары закончили быстрее на 12 минут.
А всего блин сколько? Если пара сделал за неделю, а одиночку за неделю и 12 м нут, то это одно, если пара сделала за 5 минут, а одиночка за 17 то это другое.
Вспомните школу: иногда домашку делали с другом или подругой
Вспомнил. Не было такого. Никогда. И друзей не было, а подруг - тем более.
со временем штурман на соседнем кресле начинает только раздражать
Меня раздражает сама мысль о том, что рядом кто-то пасётся.
не все готовы по шесть часов в день (обычно столько получается) общаться с другим человеком
И один час не готов. За шесть я его скорее всего удавлю или пошлю в пешее эротическое.
Самые лучшие программисты в мире - аутичные интроверты. Индустрия: "А давайте писать код вместе, разработка - это общение!"
Беда метода в том что у вас фактически выходит один программист с двойным окладом. При этом фактически 50% этого оклада идет на Code review, который делается сразу. В других методологиях Code review сильно дешевле, ибо это бегло пробежать глазами финальный код, а не мониторить 100% времени его написания и исправления.
Кстати почему бы не садить по три-четыре программиста? это по такой логике будет еще эффективней!)
Кстати почему бы не садить по три-четыре программиста? это по такой логике будет еще эффективней!)
Один штурман ускоряет работу ведущего (предположительно) в два раза***. Два штурмана ускоряют работу ведущего (предположительно) в те же два раза***. Поэтому нет смысла сажать по три-четыре программиста.
*** Это не доказано. И вообще, ускорение зависит от многих параметров (типа задачи, личных качеств и т.д.)
Мне изредка случалось работать в паре. Впечатления всегда положительные. (Наверное, любой программист с опытом работы сталкивался с ситуацией, когда кто-то смотрит, как он кодит или случалось смотреть, как кодит кто-то другой).
Для обучения джунов или новеньких сотрудников подходит хорошо.
(почти так и написано в статье)
Для других случаев бессмысленно.
Не знаю, мне кажется можно по фану попробовать, если конечно коллектив хороший и время этим заниматься позволяет. Если это будет интересно этой паре, то почему и нет? Опытом обменялись, задачу сделали, пообщались, все довольны в итоге)
Если только небольшую задачу. Если задача большая то могут быть разные подходы. Кто-то людит сначала по верхам, потом постеменно углубляясь. Кто-то кусочек за кусочком.
Первый тип несовместим ни самим собой ни со вторым. С собой не совместим - ибо слишком часто прыгаешь от куска к куску, примерно как шелкать пультом. Тебе норм, а остальным напряжно
Если честно, то это в основном, хороший способ обучения, но не как, не выполнение определённых задач и создание проекта.
Добавлю свой опыт, когда это хорошо заходит на общем примере.
Допустим, один хорошо знает систему и в целом понимает в какую сторону копать, а куда можно не копать, но при этом он не знает всех деталей реализации. Второй занимается разработкой фичи и есть определенный ступор, но при этом он уже много чего попробовал для поиска решения задачи.
В этом случае парное программирование реально заходит, поскольку вдвоем они могут проверить разные гипотезы быстрее. Первый накидывает гипотезу, она обсуждается, второй быстро накидывает прототип для проверки на базе своего имеющегося кода. Так может пройти несколько итераций.
!!! Когда решение найдено, сессия заканчивается, чтобы не мешать второму все причесать и превратить прототип в готовое решение — нечего глаза мозолить. Другое использование сомнительное мероприятие.
Два программиста — пара. Теория и практический опыт Сбера в парном программировании