Blog
22. ledna 2019 EEA s.r.o.

Jak sladit Epic a Scrum board?

V agilních metodách je epic velký uživatelský příběh (user storie). Co to znamená? V praxi by se dalo říct, že při agilní práci stačí vytvářet stories, které popisují určité use case-y.

Epic

From an Agile perspective:

V agilních metodách je epic velký uživatelský příběh (user storie). Co to znamená? V praxi by se dalo říct, že při agilní práci stačí vytvářet stories, které popisují určité use case-y. Často se ale ukazuje, že mnohé stories mají něco společného a právě epic slouží ke zgrupování těchto stories. Je to jakási „miska“, ve které jsou cukrovinky jednoho druhu, v druhé misce jsou cukrovinky jiného druhu, ale celkově tvoří projekt „Sladkosti“.

Tento postup bych nazval bottom-up, protože se nejprve vytvářejí nejmenší jednotky (stories) a potom se grupují do větších jednotek (epics). V mnoha projektech ale funguje opačný top-down princip – nejprve se vytvoří větší jednotky (epics) – například funkcionality produktu – a potom v nich malé jednotky (stories) – jednotlivé části konkrétní funkcionality.

Z pohledu Jiry:

Jak jsem již zmínil, epic je poměrně abstraktní jednotka. V Jirě již máme dvě abstraktní jednotky (bez životního cyklu) – komponenty a releasy (verze). Zavedení třetí abstraktní jednotky by už bylo asi kontraproduktivní, proto byl epic „vymyšlen“ jako typ úlohy (issue type), tedy má svůj workflow, obrazovky a všechny související prvky. Kromě toho byla vymyšlena speciální pole (Epic Name, Epic Link, Epic Status, Epic Colour – kolikrát jsme nadávali, že kromě Summary je potřeba vyplnit i Epic Name?), která umožňují agilní práci, i speciální pravidla – v systému existuje jen jeden issue type „Epic“. Je sice možné ho přejmenovat, ale pokud otevřeme issue, stejně vidíme „Issues in Epic“ i přesto, že je epic přejmenovaný*. Není možné vytvořit issue type typu „Epic“. Pouze standardní typ nebo sub-task**.

*Hovoříme o vestavěné funkčnosti, existují aplikace, které toto mohou změnit.

**Administrátoři vědí, o čem mluvím.

Scrum board:

Scrum je metoda agilního plánování. V Jirě se pracuje na tzv. scrum boardu, kde je možné vytvářet stories (a jiné typy úkolů), přiřazovat je k epikům, releasům a plánovat je ve sprintech. A právě zde se můžeme setkat se chováním epicu, které se nám může zdát „nelogické“.

 

„Ale přeci jsem ten epic uzavřel!“

 

Takovýmto způsobem vypadá jednoduchý scrum board:

Zkusme si popsat konkrétní případ.

Na scrum boardu jsme naplánovali všechny stories patřící k určitému epicu. Tyto stories byly v sprintech vyřešeny. To znamená, že ten konkrétní epic už dále nepotřebuji při plánování, potřebuji ho tedy „odstranit“ z boardu. Zde se může stát dva případy.

Případ č. 1:

Použiji funkčnost vestavěnou na boardu a uzavřu epic.

Epic zmizí z boardu.

V mých filtrech ale epic není označený jako hotový, když ho otevřu, svítí tam jiný status!

Případ č. 2:

Otevřu epic a změním status na „Done“.

Otevřu board a co nevidím? Epic je stále tam.

Proč je to tak?

Tím tajemstvím je to, že workflowvý status epicu nerozhoduje o tom, zda má být epic na scrum boardu nebo ne. Rozhoduje o tom pole „Epic Status“, které je výběrovým polem a také obsahuje hodnoty „To Do“, „In Progress“, „Done“. V případě č. 1 při stisknutí „Označit jako hotové“ změní JIRA toto pole na hodnotu „Done“ a epic zmizí z boardu. Nezmění se ale jeho workflowvý status. V případě č. 2 měníme workflowvý status, pole „Epic Status“ je v klidu a proto nemá důvod zmizet z boardu.

Co doporučuji?

Rada č. 1:

Pole „Epic Status“ standardně není na obrazovkách pro epic. Přidejte proto toto pole na obrazovky. Můžete potom přes Edit mód řídit, zda má být nebo nemá být na boardu. Pozor – je tu riziko – někdo může změnit hodnotu pole, i když to není nutné. Přes Edit se dá ale „vrátit“ zpět.

nebo

Rada č. 2:

Jste-li administrátor, dejte na transitions postfunkce, které určí hodnotu pole Epic Status. Pokud ne, požádejte o to administrátora a vysvětlete mu, proč to potřebujete. Workflowvý status tak bude vždy odpovídat hodnotě v poli „Epic Status“. V takovém případě ho ale nedávejte na create nebo edit obrazovku.

Na závěr

Existuje i jiný scénář: chování epicu vám vyhovuje a nepotřebujete nic měnit. To je také naprosto v pořádku. Tento článek je určený pro vysvětlení, proč se takto epicy chovají a co se dá změnit, pokud to uživateli nevyhovuje. Pokud doporučujete jinou radu než já, uvítáme vaše komentáře.

Poznámka na závěr: toto neplatí pro next-gen-project v Cloudu, tam se epicy neuzavírají přes board a není dostupný ani jejich workflow.

 

Radim Drinka

Atlassian Certified Technical Sales

Pokud vás tato téma zajímá, podívejte se na video na téma Scrum, kde se dozvíte, jak to funguje.

 


Pokud potřebujete pomoc od expertů se zavedením nebo nastavením Jira, nebo poradit, jak ji co nejefektivněji využít ve vaší firmě, tak nás neváhejte kontaktovat.

Podobné projekty