Čo je epik, na čo ho používať a predovšetkým ako

Požiadavky. Malé, veľké, technické, biznisové, operatívne, výskumné. A predovšetkým veľa. Za štyri roky vývoja ScrumDesku máme v backlogu viac než 800 požiadaviek. A to sú iba požiadavky, ktoré sme sa rozhodli implementovať bez ďalších ideí, ktoré by bolo pekné mať. V takejto kope je samozrejme ťažké sa orientovať bez dodatočnej organizácie. A práve tu prichádzajú na pomoc epiky.

Epic

Každé školenie Scrum, alebo Agile, prináša pojem Epic/epos/epik. Epiky sú predstavené jedným obrázkom a v podstate ani nie sú veľmi vysvetľované vzhľadom na ich jednoduchosť. Nie je to žiadna veda. Otázky sa však vynoria okamžite ako produktový vlastník začne pripravovať backlog produktu. Ako organizovať epiky? Čo majú popisovať?

Epik je množina požiadaviek, ktoré spolu dodávajú väčšiu biznis hodnotu a dotýkajú sa rovnakej časti produktu či už funkčne, alebo logicky.

Epik, podobne ako samotná požiadavka (často User story), má riešiť problém jedného, alebo viacero používateľov a zároveň má byť použiteľný a hodnotný.

Ako identifikovať epik?

Žiadna veľká veda. Začnite premýšľať nad produktom vo veľkých celkoch. Musia byť však použiteľné (end to end). V praxi sa stretávame s viacerými prístupmi dizajnu epikov. Skúsme sa teda pozrieť kedy je ktorý vhodnejší.

I. Epik ako časť produktu

Epik môže pokrývať veľký funkčný celok produktu. V ScrumDesku máme epiky BACKLOG, PLAN, WORK, REPORTS. V aplikácii môžete nájsť časti, moduly, ktoré sa nazývajú rovnako ako daný epik.

Táto organizácia backlogu je vhodná keď tvoríte produkt, ktorý budete dlhodobo rozvíjať.

Kedy použiť tento spôsob organizácie epikov?

1. Ako produktový vlastník sa musíte jednoducho zorientovať v častiach produktu a vedieť čo v nich máte a nemáte hotové.
2. Zároveň je jednoduché merať progres po častiach produktu.
3. Produktový vlastník je prirodzene navádzaný meniť poradie vlastností v epiku, čo vedie k tvorbe rýchle dodateľných minimum viable prirastkov produktu.

Nevýhodou tohto prístupu je chýbajúci pohľad na ‚user journey‘ používateľa. Nie je vidno ktoré časti backlogu pokrývajú aké časti toku hodnoty používateľa. Napr. proces od registrácie, cez nákup, košík až platbu. Každá časť procesu môže patriť do iného epiku.

Epiky sa v tomto prípade nekončia, neuzatvárajú, keďže funkčný celok je dodávaný dlhodobo. Rádovo v rokoch. V roadmape sa skôr plánuje implementácia features úrovne jednotlivých epikov.

II. Epik ako časť obchodného toku

Tento prístup je založený na tomto, že poznáme tok hodnoty, resp. obchodný proces, ktorý vieme rozdeliť do jednotlivých častí a tie následne spodrobňovať a dodávať iteratívne.

Napr. taký eshop. Kandidátmi na epiky budú:

• Prezeranie katalógu produktov – pre zobrazenie kategórií tovaru a zoznamu tovarov v danej kategórii,filtrovanie a hľadanie tovaru
• Výber produktov – výber zaujímavých produktov či už ako obľúbené, do porovnania, stráženia ceny, alebo do košíka.
• Košík produktov – prezeranie obsahu košíka, porovnávanie, rátanie celkovej ceny.
• Platba – výber z možností pre platbu, celková objednávka, doprava, samotná platba a potvrdenie o platbe.
• Dodávka produktov – zobrazenie stavu realizovanej dodávky, email a sms notifikácie.

Produktový vlastník sa prirodzene vie zamerať na dodávku v celej šírke procesu.

Pomerne rýchlo tak vznikne prvá plne funkčná verzia, ktorá je následne zlepšovaná iteratívne. Napr. epik Platba je spodrobnený na VISA, prevod, cash. V prvej verzii sa dodá iba platba VISA, v ďalšej potom prevod, cash.

Epiky sú aj v tomto prípade dlhodobejšie. Väčšinou ich nemá zmysel ukončovať, keďže budú ďalej spodrobnené v budúcnosťami ďalšími vlastnosťami. Biznis jednoduchšie pochopí stav implementovanej aplikácie (eshopu) čo zjednodušuje komunikáciu a výrazne zlepšuje spoluprácu IT a biznisu.

Dôležité je, aby v tomto prípade neboli používané technologické termíny pre názov epiku, ale skôr obchodné.

III. Projekt ako epik

Dodávate produkt klientovi vo viacerých fázach, vo viacerých projektoch? V tomto prípade môže byť jednoduchšie tvoriť epiky podľa projektov.

Takéto epiky sa typicky ukončujú keď je projekt dodaný. Výhoda je zrejmá. Je absolútne jasný stav implementácie projektu. Zúčastní a stakeholderi majú vynikajúcu transparentnosť. Zároveň sa stakeholderi vedia sústrediť na prípravu ďalšej fázy projektu.

Na druhej strane je pomerne zložité si udržiavať prehľad o funkčných celkoch produktu samotného. Reálny stav viac vnímajú architekti než obchod samotný. V praxi sme sa stretli aj s tým, že tento spôsob viedol k zmene zamerania firmy, ba priam k degradácii jej vízie. Z firmy, ktoré chcela pôsobiť ako tvorca produktov, riešení, sa stala firma plne načúvajúca klientom. Ich produkty sa stali „hračkou“ v rukách klientov, čo viedlo dokonca aj k odchodom ľudí z tímov, pretože tí stratili osobné prepojenie s produktom.

Témy

Praktické je aj použitie tém ako ďalšej kategorizácie požiadaviek. Vznikne tak virtuálna matica, v ktorej každá požiadavka patrí do nejakého produktového celku a zároveň biznis téme, ktorú komunikujeme s klientami. V ScrumDesku používame napr. témy pre označenie klientov, ktorí si žiadali väčšie celky vlastností a my sme sa predsa len rozhodli ich zaradiť do backlogov. Ako produktový vlastník tak viem komunikovať s klientom stav ich požiadaviek a naďalej si udržiavať prehľad o implementácii produktu samotného.

Témy v produktovom svete sú dokonca často určované top manažmentom na strategických stretnutiach a tieto témy sú následne implementované vo viacerých value streamoch podporované viacerými produktmi. Príkladom takejto strategickej témy môže byť Mapy v 3D, Umelá inteligencia v rizikových investíciách, Cestovanie bez brán a kariet.

Umelé epiky

Aplikácia okrem biznis logiky má veľa častí, ktoré tvoria základnú kostru produktu, no zákazník ich mnohokrát ani nevníma.

Predovšetkým na začiatku je potrebné si premyslieť a zaevidovať napr. návrh architektúry, UX návrh layoutu aplikácie, iniciatíva je frameworkov a technologickú prípravu. V neskorších fázach sa vyskytnú funkčnosti dotýkajú ešte sa celého produktu naraz. Napr. logovanie, error handling a pod. Pre takéto požiadavky si v ScrumDesku držíme epik s názvom #APPLICATION.

Keď sme začínali pred štyrmi rokmi,  rozhodli sme sa držať všetky chyby v epiku s názvom #BUGS a technologické vylepšenia pod epicom #TECH. Znak # nám indikuje artificial epic.

Neskôr sme však túto stratégiu zmenili a teraz sa každú požiadavku bez ohľadu na jej typ snažíme dať pod ten správny epik, keďže daný epik buď opravuje, alebo rozširuje, zdokonaľuje z technologického pohľadu.

Epik a business hodnota

V Agile by každá požiadavka mala dodať dodatočnú biznis hodnotu. V prípade komplexnejších aplikácii je však skoro nemožné zhodnotiť číslom dodávanú hodnotu na tak nízkej úrovni. V tomto prípade je jednoduchšie stanoviť business hodnotu na úrovni epiku. Epik sa tak môže zanalyzovať, navrhnúť a pripraviť dopredu pred samotnou implementáciou.

Dá sa k nemu vytvoriť aj business case a následne aj samotná biznis hodnota. Takýto prístup odporúča napr. Scaled Agile Framework, v ktorom epik dodáva hodnotu do vybraného value stream.

Ako pripravovať epiky?

Produktový vlastník pripravuje epiky vopred, pred plánovaním a realizáciou. Pre dobrú prípravu potrebuje podporu viacerých ľudí:

• architekta pre hrubý návrh architektúry potrebnej pre implementáciu epiku,
• stakeholderov, pre ktorých bude funkcionalita dodaná, pre stanovenie business hodnoty a business case,
• UX dizajnéra pre prípravu rámcových princípov dizajnu rozhrania a použiteľnosti epiku,
• ľudí z prevádzky a podpory pre dobrý návrh epiku z pohľadu ekonomiky správy už hotovej a nasadenej implementácie,
• a ktokoľvek iný potrebný.

Príprava epiku môže, a často aj má, iný proces než požiadavky samotné. V SAFe sa napr. odporúča tzv Portfolio Kanban pre prípravu epikov. Existuje teda samostatná Kanban tabuľa s viacerými stavmi na ktorej je transparentne zobrazený momentálny krok realizácie epiku. Vytvára tak priestor pre pravidelné stretnutia prípravného mikrotímu a priebežné zlepšovanie prípravy epiku.

Produktový vlastník v podstate pracuje v dvoch časových rovinách. V prvej pripravuje epiky pre budúcnosť a v druhej časovej rovine prispieva k implementácii už vyvíjaných epikov.

Typické chyby

• Epic podľa technologickej vrstvy. Databáza, backend, frontend. Funkčnosť nie je pokrytá end to end, dodáva iba jej časť.
• Epic podľa verzie produktu. Verzia produktu je množina vlastností z rôznych epikov. Na rozdiel od epiku má verzia aj časový údaj.
• Epik podľa zákazníka, resp. stakeholdera, ktorému sa časť funkčnosti dodáva. Takýto údaj odporúčame evidovať samostatnom atribúte a epiky organizovať podľa postupov vyššie.
• Keď sa zmenia predpoklady produktu, forma organizácie epikov sa neprispôsobí. Adaptujte a vyberajte si prístup podľa potreby.
• Nebojte sa pracovať s backlogom a meniť ho tak, aby ste sa v ňom orientovali rýchlo, vedeli si vybrať ďalšie implementácie a predovšetkým ho mať transparentným pre tím aj stakeholderov.

Odkazy a referencie

• Definícia epiku podľa Scaled Agile Framework
• Portfólio Kanban pre riadenie prípravy a implementácie epikov