Елемент спринту займає більше часу, ніж очікується завершення. Що нам робити?

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

У такій ситуації ми повинні

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

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

З "пунктом", я думаю, ви маєте на увазі "завдання".

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

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

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

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

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

Як ми можемо уникнути такої ситуації в майбутньому?

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

• У команди чи деяких членів команди тиждень поганий
• Трубопроводи вашої команди працюють горизонтально (наприклад, резервний-> передній-> QA)
• Історії завеликі помилково
• Команда «золоті тарілки» розповіді, додавши додаткову роботу, яка не є строго необхідною для завершення розповіді.
• Історії за своєю суттю дуже великі, потрібні довші спринти (навряд чи)
• Команда оцінює розповіді точно (непослідовно)
• Проект має багато технічної заборгованості / гнилої кодової бази, і ваша швидкість занадто низька
• Ви не вимірюєте та не оцінюєте свою здатність спринту правильно (або взагалі).

тощо.

Ви кажете, що не закінчите, але це непогано, це лише дані.

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

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

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

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

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

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

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

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

Інша річ може бути, щоб призначити завдання іншому члену вашої Команди розвитку, щоб уникнути того, як ваш пізній розробник копав себе в норі. І якщо завдання дійсно критичне, вирішенням може стати деякий XP.