Požiadavky v Agile

Typy požiadaviek     |     Téma     |     Epik     |     User story     |     Úloha     |     Chyby     |     Iné typy požiadaviek

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.

Pri tradičnom prístupe projektového riadenia sú produkty pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov, vrátane „bezpečnostnej vaty 10-15%“. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená „čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no projekt realizujú odlišným spôsobom:

  • Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
  • Plán vždy obsahuje veľké požiadavky, tzv. epiky . Produktového vlastníka zaujímajú epiky vytvárané na základe vízie produktu.Príklad:  Správa zákazníkov, Správa produktov, Prehľady.
  • Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením epiku. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Typy požiadaviek

Agilný plán obsahuje „tehly aj piesok“. Epiky (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily. Produktový vlastník tak má čas pripravovať epiky dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

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. Okrem pojmu epik sa pre tieto rôzne veľkosti požiadaviek zaužívali rôzne pojmy, ako napr. 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.

stavba 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 v 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

Epik (používa sa aj anglický výraz Epic) je 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ď.

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

User story

user story

Príklad reálnej user story

User story formát sa používa pre popis biznis požiadaviek produktu. 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.

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.

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.

Príklady user story:

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.

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.

Súvisiace články

Na stiahnutie

Naše tréningy