Я працював у декількох магазинах, де менеджмент передав ідею парного програмування мені чи іншому менеджеру / розробнику, і я зовсім не можу за цим піти. З точки зору розробника, я не можу знайти причину, чому перехід на цей стиль кодування був би корисним, і я, як менеджер невеликої команди, не бачив жодної користі.

Я розумію, що це допомагає в основних синтаксичних помилках і може бути корисним, якщо вам потрібно щось вимкнути, але менеджери, які перебувають поза циклом програмування, схоже, продовжують бачити це як спосіб утримувати своїх дизайнерів від відвідування Facebook чи Reddit, ніж як інструмент дизайну.

Оскільки хтось, близький до підлоги розвитку, який, очевидно, не може зрозуміти з книги, яка кинула мені дорогу або сторінку з вікі на цю тему ... з позиції управління на високому рівні, які переваги Пара програмування в роботі з Scrum або Agile середовища?

Частково це залежить від того, як ви займаєтесь парним програмуванням. У деяких випадках драйвер пари пише код, а другий член пари спостерігає та обговорює деталі проектування та впровадження системи. Інший екземпляр парного програмування передбачає одночасне написання коду обома людьми - одна людина записує реалізовану функціональність, а інша активно розробляє та пише тестовий код на рівні одиниці та інтеграції, знову обговорюючи деталі проектування та впровадження системи.

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

Поширення знань не обмежується лише технічними знаннями колективу. Залежно від того, хто така пара, вона може дозволити передачі інформації між старшим членом компанії до нового члена про інші речі, які виходять за рамки проекту - стиль кодування, культура компанії, очікування тощо. Це також може дозволити тому, хто більше знайомий з технологією чи інструментом, поділитися своїми знаннями з цієї технології чи інструменту в реальному світі.

Як ви вже згадували, це також допомагає тримати розробників зосередженими та потоковими . Крім потоку, багато людей мають меншу ймовірність перервати декількох людей, що працюють над чимось, ніж окремі особи, які працюють над чимось. Якщо ви проходите за чиїмсь столом, і вони працюють поодинці, але вам потрібно поговорити з ними, ви можете стукати і поговорити з ними. Це менш ймовірно, якщо ви бачите двох або більше людей, які спільно працюють або ведуть дискусію - ви не перебиватимете їх. Перерви витрачають час, а витрачати більше часу означає більші витрати. В інтересах бізнесу - максимізація продуктивності працівників.

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

1. Менше помилок у підсумковому коді (ефективність)
   Не повністю замінює огляди коду, але високоефективна для того, щоб виправити речі на ранньому етапі. Там є дослідження, які вказують у цьому напрямку.

2. Швидше завершення (ефективність)
   Про це свідчить декілька досліджень. Що стосується складних особливостей, 2 голови просто ефективніші. Для цього необхідний досвід спарювання.

(Примітка. Це ваш продавець для менеджера. Фінансово обгрунтоване рішення, оскільки ви отримуєте більш ефективну через меншу кількість помилок та ефективнішу, швидше закінчуючи)

1. Викладання юніорів
   Ви можете додати молодшого класу безпосередньо до досвідченого програміста. Якщо у вас є група абсолютних початківців, неважко триматися за ними і нехай вони, як пари, визначають основи. Потримайся і дай пораду. Концепція, мабуть, дуже стара і випливає з майстерності.

Швидкий відповідь: більшість переваг і витрат розміщені у Вікіпедії, однак давайте розглянемо це з дещо іншого кута.

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

Успіх або провал програмного забезпечення залежить від його якості, а програмування пар безпосередньо покращує якість численними способами. Коли два розробника працюють разом, якість дизайну покращується, оскільки пара розробляє короткий, простий та простий у підтримці код із меншою кількістю помилок. Помилки є головним питанням якості в розробці програмного забезпечення; з двома наборами очей, що пишуть код, виявляється більше помилок, тим самим зменшуючи витрати на розробку. Виправлені помилки в процесі розробки часто виправляють дорого. Швидке виявлення дефектів програмного забезпечення запобігає та допомагає стримувати складні проблеми в дорозі. Складність часто виникає в програмуванні, і два розуми, які працюють над вирішенням проблеми, можуть бачити більше варіантів і робити висновки швидше, ніж один.

в резюме:

• Сприяє командному спілкуванню
• Сприяє ефективній передачі знань додатків
• Сприяє підзвітності підходу до проектування
• Результати в кращому, простому для обслуговування коді
• Допомагає усунути баггі-код на ранній стадії
• Збільшує продуктивність команди, оскільки члени команди будуть приділяти нероздільну увагу під час кодування
• Удосконалює навички спілкування та співпраці членів команди
• Будує товариство на робочому місці
• Робить роботу веселішою

Є кілька переваг для парного програмування:

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

У Вікіпедії також є хороший підсумок витрат та переваг у вікі .