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

Я понимаю, что это помогает при базовых синтаксических ошибках и может быть полезно, если вам нужно что-то хешировать, но менеджеры, которые находятся вне цикла программирования, похоже, видят в этом способ не позволить своим дизайнерам перейти на Facebook или Reddit, а не как инструмент дизайна.

Как человек, близкий к уровню разработки, который, очевидно, не вполне может понять из книги, которую я бросил, или из вики-страницы на эту тему ... с позиции высокого уровня управления, каковы преимущества парного программирования при работе со Scrum или Agile окружающая среда?

Отчасти это зависит от того, как вы занимаетесь парным программированием. В некоторых случаях драйвер пары пишет код, а второй член пары наблюдает и обсуждает детали проектирования и реализации системы. В другом примере парного программирования оба человека пишут код одновременно - один человек пишет реализованную функциональность, а другой активно разрабатывает и пишет тестовый код на уровне модуля и интеграции, снова обсуждая детали проектирования и реализации системы.

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

Распространение знаний не ограничивается только техническими знаниями команды. В зависимости от того, кто является парой, она может позволить передавать информацию между более старшим сотрудником компании и новым членом о других вещах, которые выходят за рамки проекта - стиле кодирования, культуре компании, ожиданиях и так далее. Это также может позволить кому-то, кто более знаком с технологией или инструментом, делиться своими знаниями в этой технологии или инструменте в реальных прикладных условиях.

Как вы упомянули, это также помогает разработчикам сосредоточиться и потоке . В дополнение к потоку, многие люди реже прерывают работу нескольких людей над чем-то, чем одного работающего над чем-то. Если вы проходите мимо чьего-то стола и они работают в одиночку, но вам нужно поговорить с ним, вы можете постучать и поговорить с ним. Это менее вероятно, если вы видите двух или более людей, работающих совместно или участвующих в дискуссии - вы не будете их прерывать. Перерывы стоят времени, а тратить больше времени означает более высокие затраты. В интересах бизнеса максимизировать производительность сотрудников.

Однако есть некоторые проблемы, которые необходимо преодолеть, чтобы сделать парное программирование жизнеспособным. Подумайте о таких вещах, как столкновения личности или выбор пар, чтобы правильно распределить знания. Также учитывается, когда именно нужно вращать пары. Парное программирование, выполненное бессистемно, вероятно, не будет таким эффективным, как запланированное. В зависимости от состава вашей команды, это может быть неэффективно, чтобы пара людей вообще.

1. Меньше ошибок в конечном коде (эффективность)
   Не полностью заменяет обзоры кода, но очень эффективна для того, чтобы все исправить на ранних этапах. Существует исследование, которое указывает в этом направлении.

2. Более быстрое завершение (эффективность)
   На это указывают несколько исследований. Когда дело доходит до сложных функций, 2 головы просто более эффективны. Для этого необходим опыт сопряжения.

(примечание: это ваш коммерческий шаг для менеджера: финансово разумное решение, потому что вы получаете более эффективные за счет меньшего количества ошибок и более эффективные за счет более быстрого завершения)

1. Обучение юниоров
   Вы можете добавить младшего непосредственно к более опытному программисту. Если у вас есть группа абсолютных новичков, легко остаться и позволить им, как парам, понять основы. Держись и давай советы. Концепция, очевидно, очень старая и проистекает из мастерства.

Быстрый ответ: большинство преимуществ и затрат опубликовано в Википедии, однако, давайте посмотрим на это с разных сторон.

Я хотел бы упомянуть конкретные случаи преимуществ парного программирования, которые применяются к среде разработки Agile / Scrum, взятые из поста в блоге :

Успех или неудача программного обеспечения зависит от его качества, и парное программирование напрямую улучшает качество многими способами. Когда два разработчика работают вместе, качество шаблона проектирования улучшается, поскольку пара разрабатывает короткий, простой и легкий в обслуживании код с меньшим количеством ошибок. Ошибки - главная проблема качества в разработке программного обеспечения; с двумя взглядами на написание кода выявляется больше ошибок, что снижает стоимость разработки. Ошибки, обнаруженные на поздних этапах процесса разработки, часто требуют больших затрат. Раннее обнаружение дефектов программного обеспечения предотвращает и помогает удерживать сложные проблемы в будущем. Сложность часто возникает в программировании, и два ума, работающие над совместным решением проблемы, могут увидеть больше вариантов и сделать выводы быстрее, чем один.

В итоге:

• Способствует командному общению
• Способствует эффективной передаче знаний приложений
• Способствует ответственности за дизайн подход
• Результат в лучшем, простом в обслуживании коде
• Помогает устранить ошибочный код на ранней стадии
• Повышает производительность команды, так как члены команды будут уделять все внимание во время кодирования
• Улучшает навыки общения и совместной работы членов команды
• Строит дух товарищества на рабочем месте
• Делает работу веселее

Есть несколько преимуществ для парного программирования:

• Два программиста могут совместно разрабатывать дизайн, потенциально создавая лучшую архитектуру / код - две пары глаз могут обнаружить ошибки
• Знания учреждения сохраняются лучше - если один программист уходит или недоступен, другой должен быть в состоянии продолжить работу без значительной потери производительности
• Это один из способов быстрого обучения новых разработчиков - соедините их с опытным членом команды разработчиков, и они смогут испытать кодовую базу с точки зрения ветерана команды.
• Лучшая дисциплина - парные программисты, вероятно, будут продуктивными в течение более длительного периода времени, так как один или другой может взять на себя всплеск активности. Потенциально утомительные задачи, такие как модульное тестирование, могут быть пропущены реже, чем для индивидуальных разработчиков.

В википедии также есть хорошая сводка затрат и выгод в вики .