Коли працює парне програмування? Коли цього уникати?

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

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

Коли використовувати парну програму і чому?

Коли уникати парного програмування? Чому?

Дослідження, складене Лорі Вільямсом, свідчить про те, що програмування пар найкраще працює в промислових колективах

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

В особистому досвіді я виявив, що моя команда XP в середньому витрачає близько 60% нашого часу на програмування пари. Решту часу витрачається на індивідуальний розвиток. Не рідкість поєднуватись, щоб створити початковий дизайн, попрацювати над самою розробкою кілька годин, а потім повернутися разом, щоб закінчити складні чи складні частини коду.

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

Парне програмування працювало на мене в дуже, дуже мало ситуаціях.

Там, де програє парне програмування для мене

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

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

Я перерахую великі проблеми, які виникають з програмуванням пари на передньому плані, і викладу детальніше та анекдоти пізніше.

1. Розділити фокус.
2. Ніяких експериментів.
3. Ні високих нот.
4. Немає гордості у власності.
5. Без втечі ...

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

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

Нарешті - просто соромлячись через три місяці, і вперше за всю історію - мене звільнили за те, що не працював у команді під час парного програмування.

Не сам

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

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

"Молодший / старший" - не єдиний шлях. «Проміжний / молодший» корисний; це допомагає хлопцеві середнього рівня синтезувати отримані знання, змушуючи його передавати його комусь іншому. "Проміжні / проміжні" виклики двоє людей працюють разом, щоб ділитися своїми знаннями, спілкуватися та працювати як частина команди. І навіть якщо у вас є два дійсно старших хлопця, швидше за все, вони мають різні сфери знань і можуть придумати різні підходи. Аспекти обміну знаннями не закінчуються, коли хтось розпливчасто «набирає швидкість» на проекті. Скоріше, парне програмування є втіленням організації навчання . Нові методи та передовий досвід швидко поширюються.

Парне програмування також допомагає підтримувати якість коду (менша кількість дефектів) та розумність коду (він не просто робить те, що має намір, але робить те, що повинен ... Ідеально, не знижуючи багатотижневого кролика, дірка робить неправильну річ або дві різні правильні речі, які будуть дико конфліктувати). Це допомагає програмістам зберегти свою увагу: тут, в самому центрі Силіконової долини, будинку 80-годинного робочого тижня, ми можемо працювати лише 40 годин на тиждень, тому що робимо інтенсивне кодування вісім годин на день, перемикаючи речі одне з одним. (Крім того, якщо ви більше не займалися парним програмуванням, ви, ймовірно, вигортаєте. Або принаймні вигораєте.) Це чудово підходить для балансу між роботою та життям, а також допомагає вашій організації, коли важливо мати швидкий поворот (зокрема, з низькою затримкою).

Це не все, повністю, 100% персики і вершки; Я вважаю, що парне програмування періодично перешкоджає моєму застосуванню інтуїтивних мозкових процесів, які корисні при певних проблемах. Зовсім недавно на завдання з витоку пам’яті я провів деякий час як з парами, так і без них; без одного я почував себе вільніше возитися і пробувати експерименти, не знаючи, як саме пояснити, що я робив у будь-який момент. Є також деякі переваги в роботі синглтон, вміння виходити на дотичну і робити певні динамічні зміни (оцінені в методології XP) на примху.

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

(Ми розробляємо програмний прилад в Perl, ~ $ 4000 - $ 40 000 за ціновою лінією.)

Я ніколи не працював у налаштуваннях «Пара програмування», але все ж можу стверджувати, що був частиною трьох обставин, які ви перерахували. Сценарій, про який ви згадуєте, здається більш "регулярним програмуванням" з фазами допомоги / тренувань, що введені. Чи ми цього не робили до появи "парного програмування"? Пара програм програмування, я припускаю, вимагає більш відданого підходу, коли процес спільного використання в команді не зупиняє хвилини, коли ви вирішите найближчу задачу чи проблему. Але тоді це те, що я "думаю", а не те, що я "знаю".

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

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

Інший товариш по команді спробував використовувати парне програмування з тестом, щоб зробити ATDD, і вони були цілком задоволені результатами (згідно з його підрахунками, збільшення вартості dev на 20% призвело до зниження на 50% часу тестування)

Надобраніч

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

Парне програмування здається також ризикованим, якщо припустити, що один програміст перериває один одного. З іншого боку, важче перервати роботу двох програмістів. Наприклад, для програмування Solo, його буде легше перервати, тому соловному програмісту майже неможливо залишитися в "зоні".

Якість коду - це ще одна ситуація, коли мертвий рядок знаходиться за кутом Люди завжди поспішають, будуть програмістами для пар або соло-програмістом: вони не застосовуватимуть певних найкращих практик і просто забудуть про тестування одиниць.

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

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

Щодо того, де уникнути парного програмування, грубіть робочі завдання, які є чіткими, де було б краще розділити роботу на дві групи і дозволити кожному розробнику виконати якусь роботу окремо, щоб виконати роботу. Для деяких завдань може знадобитися досить багато введення тексту, але вони не такі великі, що варто витратити кілька годин на пошук кращого способу її виконання, як це можна зробити, якщо кожен розробник застосовує грубу силу підходу для кількох годин.