Обмін парами: які плюси і мінуси?

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

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

Обидва твердження звучать розумно; з точки зору менеджменту, це здається, що ви підвищуєте стабільність і якість, і тому такі часті заміни - це майже стандартна теорія в більшості книг Agile / XP, які я переглядав.

Отже, коли насправді реалізують на практиці, з чого люди насправді думають про заміну пари

Точка зору програміста?
Точка зору менеджера?

Що слід визначити, коли хтось заміниться на / на пару?

agile pair-programming

Це те саме, що і "Парне програмування?"

— Роберт Харві

@Robert Harvey - Ну, це один із аспектів парного програмування. Після того, як команда вирішить, що збирається програмувати в парах (протягом деякої частки свого робочого дня), тоді їм потрібно вирішити, як розташувати програмістів на пари, тобто коли один програміст повинен залишити пару (інший повинен приєднатися одночасно ). Тобто "Обмін парами".

+1 за велике запитання. На жаль, я думаю, що досить складно знайти магазин, який здійснює спарювання на регулярній основі, не кажучи вже про достатню кількість даних про парування. Сподіваюся, я помиляюся з цього приводу, і ви отримаєте кілька хороших відповідей, мені дуже цікаво їх почути.

— Джессі Маккаллоч

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

— Роберт Харві

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

Відповіді:

Парне програмування складно.

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

Я виявив, що навіть у середовищах, де проводиться створення пари, заміна пар не вартує витрат. Однак це може бути пов’язано з нашими завданнями, які ніколи не перевищують ~ 1,5 дня. Ми знайшли велику користь для розбиття завдань, яка не повинна перевищувати ~ 1,5 дня роботи. Переміщення пар може мати більше сенсу в контексті більш тривалих завдань.

— дієтабудда
джерело

Особисто мені подобається спілкуватися з людьми на всіх рівнях. Іноді я навчаюсь, іноді викладаю, а іноді ми просто робимо справи. Але навчання та викладання формують тривалий потенціал команди, що, на мою думку, так само важливо, як перевірка функцій.

— Вільям Піетрі

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

— jwenting

@William Pietri: На мій досвід, поєднання не є гарним форматом для викладання. У мене немає проблем взяти когось і провести їх через код, щоб пояснити їм, що відбувається. Однак це не парне програмування.

— дієтабудда

@jwenting: Якщо ви говорите, що програмування пар не буде добре працювати в магазинах, які зосереджуються на термінах фігнями щодо якості та стійкості, я б не заперечував. Моя порада: працювати десь, що не божевільно.

— Вільям Піетрі

@dietbuddha: Для мене працює! Найшвидший спосіб для мене вивчити нову мову, рамки чи бібліотеку - це поєднання з людьми, які добре її знають. І я знаю, що немає кращого способу довести нооба до швидкості, ніж сполучення. Наприклад, це переживає досвід: slesinsky.org/brian/code/starting_xp.html

— Вільям Пітрі

Я і програміст, і менеджер. Ось мій прийом:

Регулярні заміни - це чудово. Я віддаю перевагу обміну 2-4 рази на день, що приблизно так швидко, як я думаю, ви можете піти. Для нас це відбувається в природних точках розриву: як правило, обід та південь. Щодня міняти день чи два - це, мабуть, добре, але я б хвилювався про те, щоб піти значно довше. (Я чув про те, щоб одне місце мінялося так рідко, як кожні шість тижнів, що, на мою думку, є божевільним; після того, як багато часу разом ви будете готові колоти святого.)

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

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

Щодо того, хто залишається з поточною роботою, я відчуваю, що це головним чином залежать від людей, які беруть участь у цьому. Іноді хочеться щось побачити, а іноді ти готовий до змін. Ми також іноді обмінюємось, щоб принести досвід, або так хтось може дізнатися щось, що їм цікаво. Ми намагаємось зберегти наші підрозділи роботи досить маленькими (0,5-2,0 пари-дні), тому це не є великою справою, проте заміна йде .

— Вільям Пітрі
джерело

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

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

— Вільям Піетрі

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

Чому ми не перемикаємо пари кожні дві / чотири години? Ну, насправді я був у командах, які теж практикують це. Це, звичайно, спосіб прохолодніший і продуктивніший. Але ось угода, часовий інтервал заміни пар не повинен бути правилом, це має відбуватися самостійно; лише тоді менеджер або бізнес бачать його переваги.

Я був свідком і переживав це. Я зараз євангеліст. Його немає теорії. Швидше її всебічно прагматично :) Щасливе парування пінг-понгу та обмін парами.

— картки
джерело

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