Як впоратися на 50% гірше, ніж середні спринти?

Якщо я правильно розумію Scrum, саме так я визначаю роботу моєї команди в наступному спринті:

1. Я середню кількість заповнених балів за останні кілька спринтів.

2. Ця кількість - наша середня швидкість. Наступним спринтом ми беремо на себе багато сюжетних точок.

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

У 50% випадку ми взяли на себе занадто багато сюжетних моментів:

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

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

Чи правильне моє розуміння середньої швидкості та спринтерських зобов'язань?

Якщо так, то що нам робити для 50% спринтів, де ми відстаємо від середнього?

Якщо ні, то що я помилився?

Чи правильне моє розуміння середньої швидкості та спринтерських зобов'язань?

Так, ви маєте суть цього.

Якщо ні, то що я помилився?

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

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

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

Чи правильне моє розуміння середньої швидкості та спринтерських зобов'язань?

На жаль, вас дезінформували про кілька речей щодо планування спринтів у Scrum. По-перше, це команда розвитку (DT)

... структурована та уповноважена організацією організовувати та керувати власною роботою. - Scrum Guide

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

Зауважте також, прогноз, а не зобов'язання. Слово c було вилучено з Посібника з Scrum, оскільки воно використовувалося для зловживань Командою розвитку. Прогноз - бажаний термін.

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

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

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

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

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

Що б ви не робили, ви не повинні працювати пізно або надмірно з часом. Це називається стійким темпом ( Agile Alliance , Scrum Alliance ).

Показники того, що можуть виникнути проблеми, є:

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

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

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

1. Тримає розробників
2. Підвищує прозорість
3. Дозволяє для роздумів та поступового вдосконалення процесу

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

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

Чи правильне моє розуміння середньої швидкості та спринтерських зобов'язань?

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

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

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

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

Це відмінне запитання і дуже важливо для команд вдосконалюватися. Тема оманлива і широко не зрозуміла. Первісна мета наведення сюжету полягала в тому, щоб знайти швидкий і прийнятно точний метод оцінки рівня зусиль (LOE), необхідний для завершення функціональності, визначеного в розповідях. Загальна мета: дати командам метод прогнозування або передбачити, скільки часу знадобиться для завершення зусиль (наприклад, проекту). Ваше розуміння швидкості правильне: це СПІЛЬНІ бали за спринт завершено (справді зроблено). Тож якщо у вас є проект для доставки, і він становить 250 балів, а ваша команда в середньому становить 25 балів за спринт, проект займе приблизно 10 спринтів, плюс-мінус деякий час буфера.

Деякі світила, такі як Кен Швабер, припускають, що швидкість та точки використовуються лише для середньо- та довгострокового прогнозування. Вони пропонують використовувати години виконання завдань як другу "перевірку розумності" щодо того, що насправді можна зробити в спринті. Тож кількість балів у кожному спринті може змінюватися залежно від ємності. Інші (в тому числі і я) вважають, що зріла команда влаштується на дуже послідовну модель розміру, яка може точно передбачити потужність, і врешті-решт години роботи стануть марним додатковим тягарем. (Вкрай важливо виступати для нових команд принаймні від 6 до 12 спринтів, IMHO, поки команда не зрозуміє бали та розмір історії.)

Ваша перша маленька помилка полягає в тому, що ви сказали, що команда повинна знати швидкість і вносити багато сюжетних моментів. Насправді тренери заохочують команди відраховувати 10% до 20% і зобов’язатись * до цього рівня. Тож якщо ваша команда прагне набрати 25 очок за спринт, не заповнюйте спринт до 25 балів, а скоріше зупиніться на 20-22 балах. Пам'ятайте: ідеально ТОПЛИВО вносити історії, коли буде виконана інша робота. Тож ви можете «взяти на себе» 22 пункти і заповнити 28. Це чудово. Тільки будьте обережні, щоб не заохочувати команду до «мішків з піском» і постійно підкорятися. Немає нічого поганого в розтягуванні, щоб побачити, чи зможемо ми зробити більше.

Тепер, до вашої точки зору про дисперсію між спринтами. Це дуже поширена (але НЕ ОПТИМАЛЬНА) модель, щоб побачити команду, яка завершує 20 балів одним спринтом, потім 50, потім 22, 45, потім 15, потім 60. Якщо обчислити відхилення, воно може показувати коливання в 50% до 100% спринту після спринту. Чому команди заповнюють лише 15 балів в одному спринті, а потім 60 в наступному?

Це може означати, що команда насправді не знає, що їм зробити. (Гей, ми завершили 50 очок останнім спринтом, ми можемо зробити це знову цей спринт).

АБО, це може вказувати на те, що власники продуктів змушують команду надмірно виконувати зобов'язання, або додають роботу після початку спринту тощо. Це лише деякі АНТИ-ПАТЕРНЕТИ, які можуть спричинити цей дикий хит у заповнених точках.

Цей показник передбачуваності є важливим для спостерігачів майстрів scrum, щоб спостерігати та привертати увагу команди. Часто причиною того, що вони заповнили кілька балів в одному спринті, і тоді багато балів у наступному спринті - це те, що я називаю "РОЗКЛАДНА ХВИЛЬНА БЕЗКОШТОВНА РОБОТА". Ось дуже поширена модель:

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

Таким чином, спринт 1, вони планують спринт і, оскільки вони перебувають у фазі Формування, не можуть завершити всю роботу. Насправді у них більше неповної роботи, ніж виконана робота. Неповна робота ПОЧАТА, але НЕПРАВНЯ. Він переміщений до наступного спринту, і цього разу у них більше виконаної роботи, ніж неповної. До наступного спринту, що велике навантаження неповної роботи падає НАДОЛУ, і впевненість команди зростає.

Власник продукту схвильований, і тому вони знову збільшують навантаження. В кінці цього спринту у них є ВЕЛИЧЕЗНА кількість неповної роботи та невтішна кількість виконаної роботи.

Тут ви починаєте бачити ХВИЛИ Готово проти Неповний змінний спринт після спринту. Якщо команди не усвідомлюють, що відбувається, ця схема може тривати місяцями. Але в середньому вони складають близько 24 балів за спринт. То що ж відбувається, коли вони кидають зайві дії?

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

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

Якщо ви не дозволите команді певного часу «збивати», вони НІКОЛИ не встигнуть виконати роботу, яка зробить їх худішими, швидшими, кращими. Наприклад, Dev-Ops не може статися. Тестова автоматизація - Хто має на це час !? Але це саме те, над чим потрібно працювати командам, щоб вони могли збільшити швидкість.