Blog
22. januára 2019 Radim Drinka

Ako zosúladiť Epic a Scrum board

Epic v agilných metódach je veľká user story. Čo to znamená? V praxi by sa dalo povedať, že pri agilnej práci stačí vytvárať stories, ktoré popisujú určite use case-y.

Epic

Z pohľadu agile

Epic v agilných metódach je veľká user story. Čo to znamená? V praxi by sa dalo povedať, že pri agilnej práci stačí vytvárať stories, ktoré popisujú určite use case-y. Často sa ale ukazuje, že mnohé stories majú niečo spoločné a práve epic slúži na zgrupovanie týchto stories. Čiže je to akási „miska“, v ktorej sú cukríky jedného druhu, v druhej miske sú cukríky iného druhu, ale celkovo tvoria projekt „Sladkosti“ .

Tento postup by som nazval bottom up, pretože sa navytvárajú najmenšie jednotky (stories) a potom sa grupujú do väčších jednotiek (epics). V mnohých projektoch funguje ale opačný top down princíp – najprv sa vytvoria väčšie jednotky (epics) – napríklad funkcionality produktu a potom v nich malé jednotky (stories) – jednotlivé časti konkrétnej funkcionality.

Z pohľadu Jiry

Ako som už spomenul, epic je dosť abstraktná jednotka. V Jire už máme dve abstraktné jednotky (bez životného cyklu) – komponenty a releasy (verzie). Zavedenie tretej abstraktnej jednotky by už bolo asi kontraproduktívne, preto bol epic „vymyslený“ ako typ úlohy (issue type), čiže má svoj workflow, obrazovky a všetky náležitosti s tým spojené. Okrem toho boli vymyslené špeciálne polia (Epic Name, Epic Link, Epic Status, Epic Colour – koľkokrát sme nadávali, že okrem Summary treba vyplniť aj Epic Name?) umožňujúce agilnú prácu, i špeciálne pravidlá – v systéme je len jeden issue type „Epic“. Je síce možné ho premenovať, ale ak otvoríme issue, aj tak vidíme „Issues in Epic“ napriek tomu, že je epic premenovaný*. Nie je možné vytvoriť issue type typu „Epic“. Iba štandardný typ alebo sub-task**.

*Hovoríme o vstavanej funkcionalite, existujú apps, ktoré toto môžu zmeniť.

**Administrátori vedia, o čom hovorím 

Scrum board

Scrum je metóda agilného plánovania. V Jire sa robí na tzw. scrum boarde, kde je možné vytvárať stories (a iné typy úloh), tieto priraďovať k epicom, releasom a plánovať ich v sprintoch. A práve tu sa môžeme stretnúť so správaním epicu, ktoré sa nám môže zdať „nelogické“.

„Ale veď som ten epic zatvoril!“

Takto nejako vyzerá jednoduchý scrum board:

Skúsme si opísať konkrétny prípad.

Na scrum boarde sme naplánovali všetky stories patriace k určitému epicu. Tieto stories boli v sprintoch vyriešené. To znamená, že ten konkrétny epic už ďalej nepotrebujem pri plánovaní, potrebujem ho teda „odstrániť“ z boardu. Tu sa môžu stať dva prípady.

Prípad č.1:

Použijem funkcionalitu vstavanú na boarde a zatvorím epic.

Epic zmizne z boardu.

V mojich filtroch ale epic nie je označený ako hotový, keď ho otvorím, svieti tam iný status!

Prípad č. 2:

Otvorím epic a zmením status na „Done“.

Otvorím board a čo nevidím? Epic je stále tam.

Prečo to tak je?

Tým tajomstvom je to, že workflowový status epicu nerozhoduje o tom, či má byť epic na scrum boarde alebo nie. Rozhoduje o tom pole „Epic Status“, ktoré je výberovým poľom a tiež obsahuje hodnoty To Do, In Progress, Done. V prípade č. 1 pri stlačení „Mark as done“ zmení JIRA toto pole na hodnotu „Done“ a epic zmizne z boardu. Nezmení sa ale jeho workflowový status. V prípade č.2 meníme workflowový status, pole „Epic Status“ je v pokoji a preto nemá prečo zmiznúť z boardu.

Čo odporúčam?

Rada č.1:

Pole „Epic Status“ štandardne nie je na obrazovkách pre epic. Pridajte preto toto pole na obrazovky. Môžete potom cez Edit mód riadiť, ci má byť alebo nemá byť na boarde. Pozor – je tu riziko – niekto môže zmeniť hodnotu poľa, aj keď to nie je nutné. Cez Edit sa dá ale „vrátiť“ späť.

alebo

Rada č. 2:

Ak ste administrátor, dajte na transitions postfunkcie, ktoré určia hodnotu poľa Epic Status. Ak nie, požiadajte o to administrátora a vysvetlite mu, prečo to potrebujete. Workflowový status tak bude vždy odpovedať hodnote v poli „Epic Status“. Vtedy ho ale nedávajte na create či edit obrazovku.

Na záver

Existuje aj iný scenár: správanie sa epicu vám vyhovuje a nepotrebujete zmeniť nič. To je tiež absolútne v poriadku . Tento článok je určený pre vysvetlenie, prečo sa takto epicy správajú a čo sa dá zmeniť, ak to používateľovi nevyhovuje. Ak odporúčate inú radu ako ja, uvítame vaše komentáre.

Poznámka na záver: toto neplatí pre next-gen-project v Cloude, tam sa epicy nezatvárajú cez board a nie je dostupný ani ich workflow.

 

Radim Drinka

Atlassian Certified Technical Sales

 

 

 

 

 

Podobné projekty