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.
Tyto webové stránky používají soubory cookies, abychom vám mohli poskytnout co nejlepší uživatelský zážitek. Informace o souborech cookie se ukládají ve vašem prohlížeči a plní funkce, jako je rozpoznání, když se na naše webové stránky vrátíte, a pomáhají našemu týmu pochopit, které části webových stránek považujete za nejzajímavější a nejužitečnější.
Nezbytně nutné soubory cookies
Nezbytně nutný soubor cookie by měl být vždy povolen, abychom mohli uložit vaše preference nastavení souborů cookie.
Pokud tento soubor cookie zakážete, nebudeme moci uložit vaše preference. To znamená, že při každé návštěvě těchto webových stránek budete muset soubory cookies znovu povolit nebo zakázat.
Soubory cookies třetích stran
Tyto webové stránky používají službu Google Analytics ke shromažďování anonymních informací, jako je počet návštěvníků webu a nejoblíbenější stránky.
Povolení tohoto souboru cookie nám pomáhá zlepšovat naše webové stránky.
Povolte prosím nejprve nezbytně nutné soubory cookies, abychom mohli uložit vaše preference!