Domů / Blog / Co je epik, jak ho používat a na co
Požadavky. Malé, velké, technické, byznysové, operativní, výzkumné. A především hodně. Za čtyři roky vývoje ScrumDesku máme v backlogu více než 800 požadavků. A to jsou pouze požadavky, které jsme se rozhodli implementovat, bez dalších ideí, které by bylo hezké mít. V takové hromadě je samozřejmě obtížné se orientovat bez dodatečné organizace. A právě zde přicházejí na pomoc epiky.
Každé školení Scrum nebo Agile přináší pojem Epic/epos/epik. Epiky jsou představeny jedním obrázkem a v podstatě ani nejsou moc vysvětlovány vzhledem k jejich jednoduchosti. Není to žádná věda. Otázky se však vynoří okamžitě, jak produktový vlastník začne připravovat backlog produktu. Jak organizovat epiky? Co mají popisovat?
Epik je množina požadavků, které spolu dodávají větší byznysovou hodnotu a týkají se stejné části produktu, ať už funkčně nebo logicky.
Epik, podobně jako samotný požadavek (často user story), má řešit problém jednoho nebo více uživatelů a zároveň má být použitelný a hodnotný.
Žádná velká věda. Začněte přemýšlet nad produktem ve velkých celcích. Musí být však použitelné (end to end). V praxi se setkáváme s více přístupy designu epiků, zkusme se tedy podívat, kdy je který vhodnější.
Epik může pokrývat velký funkční celek produktu. Ve ScrumDesku máme epiky BACKLOG, PLAN, WORK, REPORTS. V aplikaci můžete nalézt části, moduly, které se nazývají stejně jako daný epik.
Tato organizace backlogu je vhodná, když tvoříte produkt, který budete dlouhodobě rozvíjet.
Kdy použít tento způsob organizace epiků:
Nevýhodou tohoto přístupu je chybějící pohled na ‚user journey‘ uživatele. Není vidět, které části backlogu pokrývají jaké části toku hodnoty uživatele. Např. proces od registrace, přes nákup, košík až platbu. Každá část procesu může patřit do jiného epiku.
Epiky v tomto případě nekončí, neuzavírají se, jelikož funkční celek je dodáván dlouhodobě. Řádově v letech. V roadmapě se spíše plánuje implementace features úrovně jednotlivých epiků.
Tento přístup je založen na tom, že známe tok hodnoty, resp. obchodní proces, který umíme rozdělit do jednotlivých částí, a ty následně zpodrobňovat a dodávat iterativně.
Např. u e-shopu budou kandidáty na epiky:
Produktový vlastník se přirozeně umí zaměřit na dodávku v celé šíři procesu.
Poměrně rychle tak vznikne první plně funkční verze, která je následně zlepšována iterativně. Např. epik Platba je rozdělen na VISA, převod, hotovost. V první verzi se dodá pouze platba VISA, v další pak převod a hotovost.
Epiky jsou i v tomto případě dlouhodobější. Většinou je nemá smysl ukončovat, protože budou dále zpodrobněny v budoucnu dalšími vlastnostmi. Byznys jednodušeji pochopí stav implementované aplikace (e-shopu), což zjednodušuje komunikaci a výrazně zlepšuje spolupráci IT a byznysu.
Důležité je, aby v tomto případě nebyly používány technologické termíny pro název epiku, ale spíše obchodní.
Dodáváte produkt klientovi ve více fázích nebo projektech? V tomto případě může být jednodušší tvořit epiky podle projektů.
Takové epiky se typicky ukončují, když je projekt dodán. Výhoda je zřejmá: Je naprosto jasný stav implementace projektu. Zúčastnění a stakeholdeři mají vynikající transparentnost. Zároveň se stakeholdeři dokáží soustředit na přípravu další fáze projektu.
Na druhé straně je poměrně složité udržovat si přehled o funkčních celcích produktu samotného. Reálný stav více vnímají architekti než obchod samotný. V praxi jsme se setkali i s tím, že tento způsob vedl ke změně zaměření firmy, ba přímo k degradaci její vize.
Z firmy, které chtěla působit jako tvůrce produktů a řešení, se stala firma plně naslouchající klientům. Jejich produkty se staly „hračkou“ v rukou klientů, což vedlo dokonce i k odchodům lidí z týmů, protože ti ztratili osobní propojení s produktem.
Praktické je i použití témat jako další kategorizace požadavků. Vznikne tak virtuální matice, ve které každý požadavek patří do nějakého produktového celku a zároveň byznys tématu, které komunikujeme s klienty. Ve ScrumDesku používáme například témata pro označení klientů, kteří si žádali větší celky vlastností, a my jsme se přece jen rozhodli je zařadit do backlogů.
Jako produktový vlastník tak umím komunikovat s klientem stav jeho požadavků a nadále si udržovat přehled o implementaci produktu samotného.
Témata v produktovém světě jsou dokonce často určována top managementem na strategických setkáních. Tato témata jsou následně implementována ve více value streamech a podporována více produkty. Příkladem takového strategického tématu můžou být Mapy ve 3D, Umělá inteligence v rizikových investicích, Cestování bez bran a karet.
Aplikace kromě byznys logiky má mnoho částí, které tvoří základní kostru produktu, ale zákazník je mnohdy ani nevnímá.
Především na začátku je třeba si promyslet a zaevidovat např. návrh architektury, UX návrh layoutu aplikace, iniciativa je frameworků a technologickou přípravu. V pozdějších fázích se vyskytnou funkčnosti dotýkají ještě se celého produktu najednou. Např. logování, error handling apod. Pro takové požadavky si ve ScrumDesku držíme epik s názvem #APPLICATION.
Když jsme začínali před čtyřmi lety, rozhodli jsme se držet všechny chyby v epiku s názvem #BUGS a technologická vylepšení pod epicem #TECH. Znak # nám indikuje artificial epic.
Později jsme však tuto strategii změnili a nyní se každý požadavek bez ohledu na její typ snažíme dát pod ten správný epik, jelikož daný epik buď opravuje, nebo rozšiřuje, zdokonaluje z technologického pohledu.
V Agile by každý požadavek měl dodat dodatečnou byznys hodnotu. V případě komplexnějších aplikací je však skoro nemožné zhodnotit číslem dodávanou hodnotu na tak nízké úrovni. V tomto případě je jednodušší stanovit business hodnotu na úrovni epiku. Epik se tak může zanalyzovat, navrhnout a připravit dopředu před samotnou implementací.
Dá se k němu vytvořit i business case a následně i samotná byznys hodnota. Takový přístup doporučuje například Scaled Agile Framework, ve kterém epik dodává hodnotu do vybraného value streamu.
Produktový vlastník připravuje epiky předem, před plánováním a realizací. Pro dobrou přípravu potřebuje podporu více lidí:
Příprava epiku může, a často i má, jiný proces než požadavky samotné. V SAFe se např. doporučuje tzv. Portfolio Kanban pro přípravu epiků. Existuje tedy samostatná Kanban tabule s více stavy, na které je transparentně zobrazen momentální krok realizace epiku. Vytváří tak prostor pro pravidelná setkání přípravného mikrotýmu a průběžné zlepšování přípravy epiku.
Produktový vlastník v podstatě pracuje ve dvou časových rovinách. V první připravuje epiky pro budoucnost a ve druhé časové rovině přispívá k implementaci již vyvíjených epiků.
Jak správně psát požadavky v Agile? Vyvarujte se typických chyb při psaní user story....
Pokud je PI Planning „tlukotem srdce" SAFe, CDP je jeho hlavní tepnou. Představuje způsob řešení nových funkcionalit...
Lidé chtějí být lepší Retrospektiva je jednou z nejdůležitějších a zároveň nejvíce podceňovaných ceremonií...
Nenechte si ujít výběr toho nejlepšího z Agile, s čím se setkali naši mentoři. Nejen ze světa produktů, vývoje, tipů a triků, ale občas i humoru. Posíláme pravidelně jednou za čas #QualityOverQuantity