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

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

Як впоратися з цим? Кілька проблем ..

• Під час наступного спринту учасники команди говорять, що робота над програмуванням виконана на 99% і просто потрібен огляд і тестування коду. Як ви з цим справляєтесь у SCRUM та спритній методології?
• Інші розробники скаржаться на те, що вони не брали участь у дизайнерських рішеннях, пов’язаних із цими історіями, оскільки робота була виконана поза межами групи.
• Наш власник продукту спокушається втягнути цю "безкоштовну" роботу, і досконалі члени, ймовірно, роблять це спеціально для того, щоб отримати більше можливостей у продукт, який команда інакше не змогла б виконати у спринтах. Існує думка, що це порушує "процес". Очевидно, що в цій роботі ще потрібно провести QA, інтерфейс користувача та документацію.

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

Як інтегрувати роботу, виконану переважаючим членом, в SCRUM і спритний процес розробки програмного забезпечення?

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

НЕХАЙ

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

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

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

Я думаю, що ви повинні врахувати дві речі:

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

Точка 2, ймовірно, хвилює інших розробників.

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

Отже, що ти можеш зробити?

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

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

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

Таким чином, нікому не кажуть НІ , і ніхто не створює додаткових робіт для них.

Поверніть його до команди

Вам слід запитати себе (або краще про команду, включаючи прем'єра):

Чому така поведінка є проблемою?

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

Але є й інші проблеми:

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

Наступне, чому я б так:

Чому розробник робить це?

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

Після того, як ви отримаєте відповідь на ці питання, ви можете почати відповідати на власне запитання:

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

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

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

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

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

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

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

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

ми також зіткнулися з тим самим, в основному ми зробили щось на кшталт 20 балів, але на минулому тижні чи навіть посередині спринту у нас закінчилося завдання кодування, проте через тестування та інший процес ми не ризикували вибрати інший PBI, то що? Програмісти зробили, щоб вивчити відставання та почати розробляти майбутні PBI (мовчки!) та інформувати решту команди, плануючи, що PBI готовий до перегляду та тестування коду! так, як ви сказали.

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

Просто ми почали прогнозувати PBI, а не брати на себе зобов’язання. В основному прогнозування означає, що ми вибираємо 25 балів при плануванні та початку спринту, а коли програміст звільняється в середині спринту, тому що завдання кодування більше немає, тому він / вона вибирає один із майбутніх PBI і ставить його в Current Sprint та починає працювати на цьому, якщо PBI міг би пройти весь процес (тестування, злиття тощо) в межах одного спринту, це бонусна точка для команди, якщо НЕ ми не провалимо спринт через це PBI і просто перенесли решту роботи ( тестування або межінг тощо) до наступного спринту та повторного покеру на залишилася робота. Тож це може бути зроблено у двох різних спринтах у гіршому випадку. Я знаю, що це може звучати як Scrumbut, але насправді покращив спосіб роботи. Я просто можу підсумувати його переваги, як показано нижче:

• Він перемагає фобію невдалого спринту через ризик приймати більше ПБІ
• Це робить додаткову роботу ваших програмістів та команди
• Це збільшує швидкість вашої команди

Однак, можливо, для команди з меншим досвідом, можливо, це зменшує поштовх, який надає команда доопрацювати ІПВ

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

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

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

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

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

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

Чи можливо ви даєте можливість решті команди досягти більшого?

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

Нехай вони також будуть вчителем

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

Я б розглядав виклик як "як наблизити менш досвідчених розробників до продуктивності самого передового розробника".

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

Коли ви займаєтесь етапом, один чи два рази на день, якщо ця людина закінчується без роботи, а інші все ще виконують завдання, погляньте на програмування пар, щоб вона могла з'єднатися з молодшими членами та передати свої великі знання та досвід. Обов’язково задайте питання "чи комусь потрібна допомога? Хтось шукає пару?"

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

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

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

1. Чи добре працює програміст.
2. Чи все гаразд з ним робити свою роботу самостійно (будь то добре чи погано). Зрештою, він ухиляється від проектування!
3. Платні додаткові години чи ні.

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

Це порушує орендаря Scrum, оскільки команда не вирішує роботу у спринті. Це команда scrum . Команді потрібно дисциплінувати цього програміста, якщо дисципліну потрібно передавати.

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

Команді (не PO або ScrumMaster) потрібно вирішити це з програмістом-шахраєм.