9 советов по увеличению эффективности парного программирования

[andrewzhuk]

Спасибо за материал. Не знаю, мне кажется, что в универах имеет смысл внедрять подобные системы и начинать обучение с такого подхода.

[Harr]

вот это очень здравая мысль!

[Nerlin]

У нас в институте все так и работало — всю группу разбивали по 2-3 человека на практических и лабораторных занятиях. Люди учились работать вместе над одной проблемой, анализировать задачу и оценивать код, делясь почему так надо или не надо делать. Более опытный студент помогал развиваться отстающим, если им конечно было это интересно.

[MadJackal]

Вот меня всегда интересовал вопрос — если парное программирование эффективнее одиночного, то, по-идее, программирование в тройках должно быть еще более эффективным?
Никто не пробовал?

[remzalp]

Я не представляю, чем должен будет при этом заниматься третий, больше всего это будет напоминать ПМа.

Плюс сложнее будет составить команду из троих, чтобы работали с похожей скоростью и не было трений. Сбалансировать двоих проще :)

<шутка>сопьются же в поисках пика Балмера</шутка>

[Desprit]

Ну это как про ту яму — одному копать медленно, вдвоем быстрее, а если вдесятером, то уже и лопат на всех не хватает.
Где-то явно есть предел, вероятно, как раз таки на втором человеке имхо.

[Danik-ik]

Программирование — это настолько интимный процесс, что втроём — это, извините, извращение...

Никогда не работал в паре (так уж сложитось, ни в одном месте работы кроме меня вопрос организации техпроцесса разработки никого не волновал). Однако уверен, что для эффективной работы есть только два варианта: либо один партнёр, либо ни одного. Иначе это будет совещание, а не разработка.

[ApeCoder]

Mob programming

[kraidiky]

Вот ещё парное программирование очень мешает ковыряться в носу, и раздумья длинной в 5 минут растягивать на часы. За это его и любят те, кто не любит чтобы программисты в носу ковырялись. :)

[vildulv]

Наверное парным программированием тогда лучше заниматься с тем человеком, с которым как минимум находишься в приятельских отношениях.

[lpre]

В сравнении с одиночным программированием оно позволяет программистам успешнее противостоять стрессу.

Вот это вряд ли. Скорее, парное программирование само является дополнительным источником стресса.

[dirkar]

Если задача типовая и несильно сложная то смысла в этом нет.
А вот в сложных и нестандартных задачах это то что надо.

[kopol76]

Интересная тема!

[General_Failure]

№8. Не составляйте пару из людей, которые ранее не имели опыта в парном программировании

Интересный совет. А где брать людей с таким опытом? Переманивать из других организаций, которые не следуют вашим советам?

[tmn4jq]

Все же ожидал дельных советов, а не очевидных вещей типа:

№6. Оба члена пары должны хорошо видеть экран

Сам я не особо люблю парное программирование, так как меня всегда сбивал с толку темп другого человека. Так что совет номер 5 нахожу хорошим.

Для меня работал такой хак: если вы работаете на ноутах, то можно просто сесть рядом каждый со своим ПК и изучать проблему. Когда у кого-то появляется дельная мысль, он ее озвучивает и показывает. Ведь необязательно же смотреть в один монитор, главное думать над одной задачей и делиться мыслями.

[betauser]

№10. Выдайте уже второй компьютер

[buldo]

Стоит отметить сложности парного программирования в распределённой команде:

• При разнице часовых поясов в 2 часа время в паре всего 4 часа(пересечение рабочего дня 6ч + по часу на обед). При разнице поясов в 4 часа уже не может идти речи о сидении в паре.
• Сложно сконцентрироваться на коде, когда напарник не рядом, а в скайпе. Проблема №2 проявляется ярче.

Первую проблему можно как-то решить, если один из напарников согласится приходить на работу раньше.
Со второй проблемой сложно как-то бороться. Нужны ответственные разработчики.

[Mishok8]

Напоминает уроки информатики в школе, когда количество людей было в 2 раза больше, чем компов.