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

Ми приблизно перебуваємо на середині нашого переходу від водоспаду до спритного за допомогою scrum; ми перейшли від великих команд у технологічних / дисциплінарних силосах до менших міжфункціональних команд.

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

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

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

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

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

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

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

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

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

Вони просто не знаходять радості в роботі, як раніше.

Правильно.

Це великий симптом того, що ви робите це неправильно.

Agile не повинен нав'язувати людям поганий новий порядок.

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

Самоорганізація означає, що управління не нав'язує дивних правил. Він не нав'язує поганих графіків і не нав'язує зайвої взаємодії.

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

Чому вони не можуть продовжувати це робити?

Навіщо їх змінювати?

Будь ласка, прочитайте кілька разів Agile Manifesto.

Промовляє Agile Manifesto

Індивіди та взаємодія над процесами та інструментами

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

Якщо ви примушуєте людей до занадто низької «взаємодії», значить, ви зайшли занадто далеко.

Працює програмне забезпечення над всеосяжною документацією.

Вони роблять це? Потім залиште їх у спокої.

Співпраця з клієнтами щодо укладання договорів.

Ви вже робите це? Тоді не змінюйся.

Відповідаючи на зміни протягом наступного плану.

Де ці люди вже можуть відповісти на зміни? Якщо так, то вони вже були спритними. Їх не потрібно було міняти.

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

В останньому випуску я був у "спритній" команді, у якій IMHO надто багато розробників з рівнем кваліфікації, і ми намагалися залучити усіх до одного проекту. Це було катастрофою. Ми більше говорили / сперечалися, ніж працювали, і врешті-решт те, що команда підготувала, була середньою роботою (читайте Peopleware або Mythical Man Month про середнє значення). Забудьте про шаблони дизайну, забудьте про низьке з'єднання або розбиття коду на невеликі класи та методи. Забудьте про те, щоб спробувати зробити щось цікаве, тому що а) цього не можна було пояснити та зрозуміти всім членам команди (принаймні, не вчасно) та б) оскільки ми були спритні, що б я не починав цю ітерацію, хтось інший, що абсолютно не розуміє продовжиться в наступній ітерації. Особисто,

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

У той же час в моїй компанії є мало (дуже мало) людей, з якими я б абсолютно хотів би працювати пліч-о-пліч і ділитися всім своїм кодом.

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

То що ти робиш?

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

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

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

Що таке Agile?

Є це:

• набір правил, яких ви повинні дотримуватися, щоб досягти того, що встановили правила встановлення правил?

• підхід, який найкраще здогадується, щоб зробити справи в межах ваших сильних сторін, вимог та обмежень?

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

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

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

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

“Помістіть 4-6 людей у ​​кімнату з робочими станціями та дошками та доступом до користувачів. Дозвольте їм доставляти користувачеві тестоване програмне забезпечення користувачам кожні один-два місяці, а в іншому випадку залишайте їх у спокої ».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всього мої 2 копійки.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Звучить, що вони "Самотні рейнджери". У канонічному Scrum ці люди просто не можуть вписатись у Команду (вони пропускають біт "взаємодії").

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

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

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

Якщо Джо (ваш розробник Hero) трохи гнучкий, то я не бачу проблеми:

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

Єдині виклики, які залишаються в межах кількох обмежень, які накладає Scrum:

1. Надання функціональних можливостей через регулярні проміжки часу: Якщо ви дозволяєте Джо жувати проблему місяцями, і нічого не показувати до самого кінця, тоді Джо справді не спритний: Він бере заручника власника продукту і не дає йому можливості повторно проаналізувати та частина виробу. При такій практиці також є ризик, що він запізнюється, і ніхто цього не помічає. (Але за вашим описом це не так вже ймовірно). Засіб усунення: Чи було б занадто багато запитати у Джо, щоб сидіти разом із спеціалістом з питань технічної підтримки, розбивати історію користувача та домовлятися про проміжні результати, бажано (але не обов'язково) з цінністю для користувача?

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

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

Правила для спритної команди повинні бути налаштовані відповідно до команди - це може бути дійсно особиста настройка; Наприклад, я працював над командою, де було таке правило:

Весь код повинен бути написаний парою, за винятком того, що Девід може писати код самостійно.

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

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