Епичните са мъртви. Ето какво трябва да направим вместо това.

Какво вече не е обявено за мъртво? Test Driven Development беше погребан преди години. И все пак продължава да се разпространява. Разбира се, Agile също е мъртъв. Но дори традиционните компании влизат в контакт със Scrum. Мъртвите продължават да живеят, но обявяването на нещо за мъртво винаги е добре за бързо заглавие. В този смисъл станете свидетели как унищожавам епосите като пъргава практика.

Какво представляват епосите?

Терминът е неясен. Това има предимства. Epics са повече за комуникация, отколкото за спецификация. Неясността ги прави многостранни. Но съществува риск от недоразумения. Придържам се към определението на Майк Кон:

Scrum epic е голяма потребителска история. (Източник)

Използвам термина по следния начин: Епосът е история, която е твърде голяма, за да бъде приложена в спринт на Scrum. По този начин елементите в горната част на натрупаните продукти не са епоси, а малки истории. Надолу в изоставането обикновено ще намерите епоси. С течение на времето еповете се „нарязват“ на истории, които могат да бъдат изтеглени в спринт.

Това съм преподавал години наред в курсовете си за обучение. Изглежда, че е общият консенсус. Интуитивен на пръв поглед. Тук съм, за да обясня защо не е практично.

3 непрактични начина за справяне с епосите

Досега съм срещал три начина, по които компаниите се справят с епосите. Нито един от тях не е практичен. Нека ги наречем:

Разтваряне

Връзки

Дървета

1. Разтваряне

Принципът на разтваряне е прост. Епопеята е напълно раздробена на своите компоненти, отделните малки истории.

Например епичен „Книжен полет“ на онлайн портал за полети може да бъде разделен на отделните стъпки на процеса. Така че „Вход“, „Търсене на полет“ и т.н. Всяка стъпка от процеса се превръща в история. Екипът оценява историята. Докато е твърде голям, екипът продължава да го нарязва. След като всички истории са достатъчно малки, за да се поберат в спринтовете, екипът изтрива епоса и започва разработването на историите.

Притеснява ме идеята за пълнота. Разпускането предполага, че дадена тема може да бъде завършена с предварително определен обхват.

Но ако по време на разработката са възможни промени в историите, не можете да дефинирате всички истории предварително.

Scrum Guide казва:

Натрупването на продукти никога не е пълно. […] Изискванията никога не спират да се променят.

Ако трябва да доставите фиксиран обхват, спрете да се преструвате. Забравете за епосите и опишете предварително подробните изисквания. Просто не претендирайте, че сте пъргави тогава.

2. Връзки

Ако не разтворите напълно вашите епоси, има смисъл да използвате връзки. Епосите остават, долу в изоставането. Свързвате нови малки истории с епосите, от които произлизат.

Рискът е, че с течение на времето количеството на епосите се увеличава. Натрупаните изоставания се подуват. Той съдържа епоси, от които повече не се нуждаете. Заинтересованата страна вече не е във фирмата. Или темата вече не е актуална.

Разбира се, можете от време на време да почиствате изоставането си. Считам това за работа без добавена стойност. И можете да го избегнете, както ще опиша по-късно.

3. Дървета

Друг начин е изобразяването на епоси и истории като дърво:

Групирате малките истории по епос. Не е лоша идея. Но това, което губите, е подреденият списък с изоставането. Как тогава определяте реда за изпълнение?

Разбира се, можете да използвате цифров инструмент, който поддържа и двата изгледа. Рискът: инвестирате твърде много време и усилия в инструментите. Какви са възгледите? Какви са атрибутите? Какъв е основният модел на данните? Интересни въпроси. Но при пъргав подход те не трябва да имат висок приоритет.

В обобщение, идеята за групиране е добра. Но правенето му отнема много време.

Алтернативата на епосите

Отдавна има алтернатива. Дори се споменава в същата публикация в блога на Mike Cohn, която свързах по-горе.

Говоря за теми .

Темата може да се разглежда като допълнителен атрибут на историите. Обикновено няколко истории споделят една и съща тема. Историята „Търсене на полет“ може да има темата „Книжен полет“. Фрагмент от изоставането може да изглежда така:

Темите не се управляват като отделни елементи на изоставането. Това елиминира работата по почистване, обсъдена в главата Връзки. Това е добре.

Но това, което губите, е процесът на постепенно усъвършенстване от големите епоси до историите, които могат да бъдат приложени в спринт. Това е лошо.

За щастие има практики, които дават възможност да се направи това усъвършенстване извън изоставането. Един от начините за идентифициране на теми е диаграма на случая на употреба:

Хубавото на такива диаграми е, че те показват „Голямата картина“ поради високото ниво на абстракция и графичното представяне. За това изоставането е неподходящо.

По-късно имената на случаи на употреба стават теми в изоставането. Но как да стигнете от случаите на употреба до историите? За това подходящо е подходящото за историята на Джеф Патън:

Горните два реда на примерната карта показват случаите на използване „Резервирайте полет“ и „Управление на профила“ и техния основен поток. В рамките на отделните стъпки екипът затваря алтернативите: други процеси, грешки и т.н. Тези жълти бележки се наричат ​​потребителски задачи.

В прецизирането на изоставането екипът извлича историите от потребителските задачи. Една задача може да служи като заглавие на разказа. Екипът добавя към историите подробности като критерии за приемане.

Последствията

Прилагането на този алтернативен подход има последствия. Например Product Backlog ще съдържа само истории за следващите 1-2 спринта. Така че може би 10–20 истории.

Всички дейности като по-нататъшно определяне на приоритети, оценка и разработване на критериите за приемане се извършват само с тези истории. Както казва 10-ият пъргав принцип:

Простотата - изкуството да максимизираш обема на неизвършената работа - е от съществено значение.

Ако ръководството иска да има представа за напредъка на развитието, това е възможно на три нива:

  • Диаграмите или темите за използване предоставят дългосрочната перспектива за управление. В продължение на 1 година или дори повече. Но: те не са подходящи за уточняване на подробности.
  • Картите с истории формират основата за планиране на освобождаването. Заинтересованите страни, заинтересовани от изданието, създават историческата карта с членове на екипа. (Поради нови открития, обхватът може да се промени по време на разработката.)
  • Тези, които искат да имат задълбочена представа и да повлияят на детайлите по време на разработката, участват в Sprint Review и Backlog Refinement .

Само на малка надморска височина виждаме детайлите. И натрупването на продукти в основата е като списък за пазаруване. Бихте ли записали какво искате да купите след една година?

И накрая, но не на последно място, смъртта на епосите предвещава умирането на консуматорството. Ако искате нещо, трябва да се съгласите с екипа и да работите в тясно сътрудничество.

Post mortem

В дискусията с колеги те посочиха, че дори след разпадането на епос могат да се добавят малки истории. Точно така и за мен това е приемливо решение. Това, което се губи в този случай обаче, е „Голямата картина“, която показах в диаграмата на случаите на употреба.

В крайна сметка, пригодността на даден продукт за потребителите определя неговия успех. Не как е направен. Това се отнася за всички практики за развитие, включително епоси.

Може би сте измислили разумен начин да се справите с епосите?

Научете как да управлявате ефективно натрупванията на продукти, като посетите моя онлайн курс. Тази статия е публикувана за първи път в HOOD Blog на немски език.