Scrum: як поводитися з предметами відставання, які довші, ніж один спринт

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

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

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

Слід також відповідати структурі відставання виробів Айсберга.

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

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

Коли Scrum вперше був «винайдений», спринт за замовчуванням зазвичай становив 4 тижні.

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

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

Сьогодні я вважаю, що більшість команд вважають 4 тижні дуже тривалими спринтами. У мене таке враження, що 2 тижні - це цілком нормально. Команди XP виконують лише 1 тиждень ітерацій, і вони закінчують повну історію користувачів у кожній ітерації.

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

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

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

Ось чудовий плакат, який допомагає розбивати сюжети, його на веб-сайті під назвою agileforall.com, і ви можете знайти тут плакат, його дійсно корисно мати, коли ви вдосконалюєте затримки:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

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