Požiadavky v Agile

Aj v agilnom projekte sa požiadavky musia zbierať, nejako evidovať a manažovať. V porovnaní s tradičnými prístupmi manažmentu požiadaviek je v Agile výrazná snaha o minimum zbytočnej dokumentácie, ktorá nikomu neprináša hodnotu. Aj forma evidencie požiadaviek tento princíp odráža svojou jednoduchosťou, zameraním sa na hodnotu a klienta, resp. používateľa.

Typy požiadaviek

Backlog požiadaviek je v agile zámerne tvorený tak, aby nebol detailný vo všetkých častiach. Detaily musia pribúdať postupne podľa priorít a potrieb používateľov. Backlog sa tak prirodzene rozpadá do menších častí s rôzou mierou detailov. Pre tieto rôzne veľkosti požiadaviek sa zaužívali rôzne pojmy, ako napr. epik, capability, feature, user story, atď.

Produktový backlog by mal popisovať produkt z dvoch hlavných pohľadov: z pohľadu štruktúry produktu a z pohľadu biznisu.

Stavdba product backlog

Správna stavba produktového backlogu. V niektorých zdrojoch nájdete navzájom zamenenú úroveň vlastností a epikov.

Téma, iniciatíva

Biznis prichádza s iniciatívami podľa trhu, klientov a konkurencie. Obchodné zámery sú vyjadrované biznis prípadmi, iniciatívami. V agile sa používa aj pojem téma. Pre naplnenie danej iniciatívy je potrebné v produkte zasiahnuť do viacerých častí produktu, do rôznych či už systémov, alebo komponent. Témy umožňujú spravovať produktový backlog z pohľadu biznisu.

 

Téma product backlog

Téma v produktovom backlogu

 

Téma, iniciatíva, umožňuje udržať si prehľad o zdroji primárnej potreby vlastností, vyhodnocovať stav a aj náklady vývoja danej obchodnej iniciatívy. V elektronických nástrojoch je veľmi často dostupná samostatná položka, ktorá umožňuje evidenciu obchodnej témy. Za evidenciu tém je zodpovedný produktový vlastník.

Epik

Veľký celok vlastností typicky zameraný na jeden biznis proces, často pre viaceré typy používateľov. Príkladom v ERP systéme môže byť napr. Správa klientov, Logistika, Účtovníctvo, HR atď. V praxi sa načastejšie používa aj anglický výraz Epic.

Epiky sú rozdelené na menšie vlastnosti (ang, features).

Feature, vlastnosť

Menšia množina vlastností zameraná na jednu konkrétnu časť produktu. Napr. Filtrovanie, Prílohy, Tlačové zostavy a pod. Komplexnejšie rámce ako SAFe používajú aj ďalšie pojmy ako napr. Capability, alebo Feature. Tie sa líšia od epicu iba veľkosťou požiadavky. Najkomplexnejší epik je rozdelený na niekoľko capabilít a tie na features a následne na user stories.

User story

V Agile sa zaužíval iný spôsob zápisu požiadaviek. User Story formát dáva tímu informáciu o kontexte. Poskytuje informáciu o tom, kto potrebuje vyriešiť nejaký problém. Prečo. Neposkytuje informáciu ako ho má tím vyriešiť, tu im dáva slobodu a možnosť ukázať svoju expertízu.

User story formát sa používa hlavne pre popis biznis požiadaviek produktu.

Formát zápisu je nasledovný:

Ako <kto> potrebujem <čo>, aby <benefit>.

 

Časť <kto> je popisom používateľa, persony, ktorá bude danú požiadavku používať. Časť <čo> definuje požadovanú funkčnosť.

Časť <benefit> popisuje typicky problém, aktivitu, alebo výhodu, ktorú daný používateľ chce vyriešiť. Túto časť môžete referencovať podľa Value Proposition Canvasu.

 

Priklad user story

Príklad reálnej user story

Ako klient poisťovne
potrebujem asistenčnú službu v prípade nehody,
aby som vedel ako riešiť problém a zmenšil tak stres.

Ako obchodník
potrebujem spravovať kontakty klientov,
aby ktokoľvek z firmy vedel s nimi udržiavať komunikáciu.

Ako vodič
si potrebujem jednoducho privolať rýchlu zdravotnú pomoc,
aby som prežil aj v prípade keď neviem kde sa presne s autom nachádzam.

 

 

User story formát nemusí úplne popisovať požiadavku. Je dôležitejší pre vyvolanie konverzácie a pre ľahšie referencovanie požiadaviek počas plánovania. Ďalšie detaily požiadavky sú zachytené v akceptačných kritériách, priloženej podrobnej analýze, dizajnu, alebo UX návrhu.

Dobrá user story by mala spĺňať pravidlo INVEST:

IndependentNezávislá na iných požiadavkách. User story môže rozšíriť existujúcu funkčnosť, no kvôli jej realizácii by sme nemali mať závislosti na iných požidavkch, ktoré by sme kvôli tomu museli zaradiť do sprintu.

Na začiatku je to veľmi často ťažké dosiahnuť predovšetkým kvôli nedostatku skúsenosti zo správneho delenia požiadaviek

NegotiableUser story má byť jasná a zrozumiteľná pre všetkých v tíme. Zrozumiteľnosť podporujú predovšetkým akceptačné kritériá, dizajn realizácie a UX dizajn.
ValuableHodnotná. Produktový vlastník by mal vedieť prečo je daná user story potrebná, aký problém rieši a nakoľko je hodnotná.
EstimableOdhadnuteľná. Tím by mal vedieť danú user story odhadnúť. Ak nevie, potom je to indikácia nejasne pripravenej požiadavky. Neskoršia realizácia by znamenala veľké riziko, že tím vytvorí iný výsledok v porovnaní s očakávaním produktového vlastníka a klientov.
SmallMalá, realizovateľná počas jednej iterácie.
TestableOtestovateľná. Story by malo byť možné overiť. Z pohľadu kvality technickej implementácie a aj z pohľadu akceptácie používateľa.

 

Ďalším pravidlo aplikovaným dobrými produktovými vlastníkmi je YAGNI (You Ain’t Gonna Need It) – nebudeš to potrebovať. Toto pravidlo súvisí s počtom nepoužívaných vlastností. Znamená to, že ak produktového vlasntíka napadne nejaká nová vlastnosť, mal by ju nechať „odležať“. Mal by jej dať čas, aby sa ukázalo, či je skutočne potrebná. Mal by validovať jej potrebu u klientov a až potom ju zaradiť do backlogu.

Vzhľadom na aplikáciu lean pravidla Tak neskoro ako sa dá neodporúčame pripravovať user stories detailne vo väčšom počte. Stačí na najbližší sprint. Zmeny biznisu sú tak časté, že úsilie venované do detailizácii požiadaviek by znamenalo zbytočnú stratu.

Pri písaní user stories na fyzické karty si dohodnite formát takejto karty. Umožní vám to udržať konzistentný a veľmi čitateľný backlog s rýchlou orientáciou. Prázdne karty pre vaše user stories si môžete stiahnuť tu.

 

User story karta

Príklad karty user story pre plánovanie

 

Na karte je priestor aj pre priorizačné hodnoty používané pri plánovaní sprintu, resp. produktového inkrementu.

 

PoložkaŠkála hodnôtPopis
MoSCoW{Must Should Could Won’t}Dôležitosť z pohľadu klienta, používateľa.
Business Value€, $, {0,1/2,1,2,3,5,8,13,20,40,100}Hodnota z pohľadu dodávateľa
Riziko{L,M,H}, {0,1,2,3,4,5,6,7,8,9}Riziko implementácie.
Odhad{0,1/2,1,2,3,5,8,13,20,40,100}Náročnosť, typicky v story pointoch.

Iné typy požiadaviek

V produktovom backlogu by mali byť evidované všetky požiadavky. Backlog je tak jediným miestom, v ktorom sa dajú požiadavky nájsť, plánovať a spravovať.

V agile nie je nutné písať všetky požiadavky vo forme user story. V prípade technických požiadaviek, operatívnych činností a nefunkčných požiadaviek to je dokonca kontraproduktívne a vedie to k nezrozumiteľnému a často umelému zápisu.

Aj takéto požiadavky by však mali byť priorizované predovšetkým voči biznisovým. Umožní to tímu pridávať správnu hodnotu do produktu z biznisového aj technologického pohľadu.

Produktový backlog

Produktový backlog je množinou požiadaviek, ktoré klient skutočne potrebuje. Nie je to kopa nápadov, je to výber hodnotných nápadov, ktoré sme sa ako tím spolu s klientom rozhodli implementovať.

Backlog produktu je utriedený zoznam, resp. lepšie mapa, v ktorej je jasné poradie požiadaviek tak, aby tím si mohol z tejto kopy ťahať požiadavky na realizáciu podľa svojej kapacity.

Položky, ktoré sú prvé v backlogu by mali byť natoľko detailné, aby ich tím mohol a vedel implementovať. Ďalšie položky môžu mať ešte neúplnú definíciu, ktorá bude priebežne aktualizovaná.

O produktový backlog sa stará produktový vlastník. V prípade veľkých projektov backlog pozostáva aj z viacerých backlogov, za ktoré zodpovedá viacero produktových vlastníkov spolu s chief product ownerom. Priebežný manažment požiadaviek v backlogu sa nazýva product backlog grooming.

Mapa user stories

V mnohých produktoch je neprehľadné mať backlog iba ako utriedený zoznam pre manažment vlastností produktu.

User stories mapping je technika, ktorú Jeff Patton začal používať predovšetkým na prípravných workshopoch k produktom,na ktorých sa tím snažil vymyslieť, brainstormovať, to čo produkt bude robiť.

Mapa zachytáva spodrobnenie požiadaviek, ich dôležitosť a aj plán ich dodávok:

  • Produktový rozpad, pohľad produktu po vlastnostiach, epikoch a user sotries.
  • Minimum Viable Product, skupina vlastností definujúcich predateľnú a použiteľnú verziu produktu.
  • Releases – rozdelenie MVP a požiadviek do viacero releasov.
  • Sprinty – rozdelenie user stories do jednotlivých sprintov.
Uset story mapa

Organizácia user story mapy

Mapa je organizovaná takto:

  • Stĺpce reprezentujú rozpad požiadaviek na menšie vlastnosti, typicky až na úroveň user stories. V záhlaví stĺpca sú umiestnené epiky (modré karty), nad ktorými môže byť ešte umiestnená feature (tmavooranžová karta).
  • Swimlines (modré čiary) sú širšie riadky zoskupujúce user stories do MVP, releasov, alebo sprintov.
  • Karty sú na mape zoradené podľa dôležitosti zľava doprava (po epikoch) a zhora dole po user stories.

Mapa samozrejme nie je statická, časom sa bude vzhľadom na dynamiku biznisu meniť. Za jej udržiavanie zodpovedá produktový vlastník. Je to jeho nástroj pre včasnú prípravu požiadaviek.

Tímy zvyknú na mape zaznamenávať aj stav riešenia danej karty. Majú tak vysokú transparentnosť celkového stavu produktu. Výrazne to zjednodušuje výber požiadaviek pre nasledujúce verzie.

 

 

Ďalším pokračovaním je vytvorenie poradia kariet a ich postupný prepis do backlogu produktu. To umožní oddeliť prípravu požiadaviek z pohľadu produktu a biznisu od časového plánovania. Karty sa typicky vezmú na release planning.

Backlog sprintu

Zoznam vybraných požiadaviek, ktoré je tím schopný dokončiť počas sprintu. V porovnaní s backlogom produktu obsahuje backlog sprintu požiadavky rozpadnuté na konkrétne implementačné úlohy vedúce k funkčnému výsledku. Tieto úlohy sú počas plánovania sprintu pridané podľa Definície Hotovo.

Backlog sprintu je reprezentovaný najčastejšie Kanban tabuľou vo fyzickej a aj elektronickej forme. Tímy veľmi často používajú obe súčasne kvôli viditeľnosti celého backlogu sprintu a zároveň kvôli podpore spolupráce nástrojmi.

 

 

Tím môže pre označenie typov úloh použiť rôzne farby. V dobre pripravenom backlogu sprintu by každá úloha mala byť odhadnutá časovou jednotkou. Pri tomto odhade uvažujeme s ideálnou situáciou kedy pracovník nie je prerušovaný. Karty úloh môžu, ale nemusia byť priradené konkrétnym ľuďom. Nepriradzujte ich ak chcete v tíme aktívne vybudovať zastupiteľnosť. V tomto prípade tím musí konzistentne pracovať na úlohach podľa poradia.

Funkčný prírastok produktu

Prírastok produktu (ang. product increment) je funkčný výsledok práce tímu na konci jednej, alebo viacerých iterácií. Mal by byť skutočne funkčný a použiteľný klientmi, nielen množina čiastočne funkčných výsledkov bez chýbajúceho otestovania.

Funkčný inkrement sa snažia agilné tímy na konci iterácie nasadiť. V prípade enterprise produktov je to často iba na testovacie, integračné, alebo predprodukčné prostredie, aby iné, závislé, tímy mohli pokračovať vo vývoji nadväzujúcich častí komplexného systému.