Як ви демонструєте продуктивність у середовищах парного програмування?

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

Як ви демонструєте (або навіть вимірюєте) індивідуальну ефективність у такому середовищі?

включіть значення, яке ви додали до програмування пар в огляді продуктивності - чи допомогли ви іншому програмісту дізнатися корисні речі? (і навпаки, ви слухали його / її поради мудреця та добре співпрацювали?)

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

Було б важко остаточно довести одну користь від продуктивності над іншою науково.

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

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

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

Це не ідеальний експеримент, але я був би захоплений почути, чи хтось спробував щось подібне.

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

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

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

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

Чи часто комутуються пари? Якщо це так, ви можете використовувати анонімні огляди, щоб розібратися в оцінці. Наприклад, якщо людина A сказала, що B виконала 60% роботи, людина C сказала, що людина B виконала 30% роботи, а людина D сказала, що людина B виконала 90% роботи, ви могли б оцінити це з людиною B, яка робить 60% роботи. Якщо робота, яку виконала людина Б у своїх парах, має відносний коефіцієнт 100 балів, то людина Б зробила роботу на 60 балів!

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

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

Ви опинилися в тій ситуації, через яку мій учитель ставить нас студентів у нашій навчальній програмі розвитку ігор. Нас парно (2, 3 або 4 людини, залежно від розміру класу та розміру проекту), і в кінці нам кажуть оцінити кожного окремого члена команди та себе стосовно проекту та того, яка робота була виконана, а також проекти інших команд в цілому. На основі цих оцінок формулюється оцінка.

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

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

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

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

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

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