Ako nepísať požiadavky v Agile: Procesné kroky

Ako písať požiadavky v Agile firme správne? Písanie požiadaviek je z pohľadu biznis agility kľúčová znalosť. Agile síce preferuje komunikáciu a spoluprácu pred byrokraciou, to však neznamená, že zrazu netreba nič písať.

Základnou schopnosťou produktového vlastníka je vycítiť ako správne rozdeliť požiadavku na malé, potom nájsť správnu mieru detailu zápisu a nakoniec popritom všetkom si udržať aj prehľad.

S agilnými tímami naši mentori zakaždým začínajú s produktovým backlogom. Práve ten vypovedá o skutočnom pochopení agilných princípov. Tie sú skutočne dôležité akokoľvek teologicky/filozoficky/ideologicky/neprakticky vyzerajú na prvý pohľad.

So zavádzaním Agile sa firmy bez pomoci často trápia samé. Pritom vzniká množstvo nepochopení, ktoré končia vo forme „našich“ pravidiel slepo, alebo nasilu, aplikovaných. Toto nepochopenie je neskôr príčinou nefunkčného agilného prostredia, čo následe vedie k frustrácii a odchodom.

Tímy majú tendenciu tvrdiť, že dokumentácia a písanie požiadaviek je proti samotným princípom Agile. Skôr to však vnímajú z pohľadu zvýšenej byrokracie.

Porozumenie ako správne písať požiadavky v Agile však výrazne zvyšuje efektivitu a rýchlosť tímu. Je potrebné nájsť mieru „ani veľa, ani málo“.

V tomto a nasledujúcich článkoch vám prinesieme pohľady na typické chyby z praxe, s ktorými sa bežne stretávame.

Dúfame, že vám tieto články uľahčia váš začiatok na ceste k zmysluplnému agile.

Nechajte procesu čo je procesné

Typickou chybou v backlogu sú požiadavky, ktoré popisujú procesné kroky. Nie je pravdou, že všetko čo tím má spraviť, musí byť v backlogu.

Produktový backlog nemá v názve produktový náhodou. Backlog by mal popisovať funkčnosť, ba ešte lepšie, výsledok z pohľadu používateľa.

Príklad: Klient vytvára webovú aplikáciu, ktorá má umožniť riadenie zamestnancov na prevádzke. Pre správny manažment prevádzky potrebuje prehľad o odpracovanej pracovnej dobe.

Produktový vlastník má v produktovom backlogu ohľadom tejto potreby nasledujúce požiadavky:

User Story 1: Report "Časový výkaz"
Ako zákazník potrebujem vidieť časový výkaz zamestnancov, aby som vedel vyhodnotiť náklady.


User Story 2: Akceptácia nového reportu
Ako stakeholderi chceme akceptovať nový report Časový výkaz, aby som dal tímu spätnú väzbu.

Bližšou analýzou backlogu sme zistili, že takýto pattern sa nachádza v backlogu viackrát. Product owner sa naučil nesprávne deliť požiadavky. V snahe vyhovieť procesu a tímu, ktorého výstupy musia prejsť formálnym schválením, radšej zapísal User Story 2 v snahe „aby sa nezabudlo“.

Čo je na to zlé?

Z dlhodobého pohľadu viacero vecí:

1. Môžeme očakávať min. dvakrát viac položiek v backlogu.
2. Čas na ich prípravu by produktový vlastník radšej mal investovať do komunikácie s klientom, výberom ďalšej správnej požiadavky, jej rozbitiu na menšie, priorizácii a nakoniec aj príprave a zápis. Hej Produktový vlastník, nemáš čas?
3. Zníženie prehľadnosti produktového backlogu. Práve kvôli počtu.
4. Menej prehľadnosti, ťažšie vybrať správnu požiadavku pre tím.
5. Závislosť požiadaviek medzi sebou, produktový vlastník musí sledovať kedy čo bude hotové a nezabudnúť na to.
6. Odhadovanie sa stáva nočnou morou. Ako máme ako tím odhadnúť náročnosť akceptácie biznisom?
7. Ťažké plánovanie sprintov. Vieme čo biznis stihne akceptovať?
8. Znekvalitnenie metrík, velocity sa napr. nebude dať veriť, pretože akceptácia nerobí tím, jej dokončenie nevie tím ovplyvniť.
9. Skomplikovanie organizačných vzťahov. Zažili sme aj takúto situáciu, ktorá na prvý pohľad nemá veľký základ v písaní požiadaviek. Akceptáciu robí viacero ľuďmi mimo tím (v user story je zápis „stakeholderi“). Kto ich bude koordinovať? Máme si ako tím viesť o tom evidenciu na našej tabuli ako úlohu? Komu ich priradiť? Kto má takéto úlohy priradiť, dokonca ľuďom pod iným vedúcim?
10. Predĺženie času dodávky. Jednoducho dodatočné aktivity vedú k natiahnutiu času, ktorý by sa dal lepšie investovať.

Ako písať požiadavky správne?

Ak akceptáciu robia ľudia mimo váš agilný tím, odporúčame vám vybrať akceptáciu samotnú mimo vašu Kanban tabuľu.

V tomto prípade napr. ešte existuje jedna Kanban tabuľa Program Kanban, kde môžete sledovať stav rozpracovanosti požiadaviek a priradiť stĺpce zodpovedným osobám.

Po tejto tabuli „plávu“ požiadavky. Ľavé stĺpce po Portfolio Backlog obsahujú požiadavky, ktoré stakeholderi spolu s produktovým vlastníkom, biznisom a architektmi, analytikmi, pripravujú pre implementáciu.

Vybranú, schválenú a pripravenú požiadavku produktový vlastník preradí do stĺpca Backlog, čo indikuje, že ju prevzal agilný tím.

Produktový vlastník presunie požiadavku do stavu Implementing v momente, keď sme ju na tímovej Scrum tabuli sme zaradili do niektorého sprintu a rozdelili na implementačné úlohy priradené jednotlivým členom tímu.

Pozn. Dobré project management nástroje dovoľujú automatizáciu zmeny stavov. V ScrumDesk aplikácii sme sa snažili meniť stavy automaticky aj bez dodatočnej konfigurácie.

Stakeholderi, resp. biznis, čaká na signál od tímu, že dokončil požiadavku. V tímovej Scrum tabuli sú v tomto prípade všetky podúlohy v DONE a samotná požiadavka (user story) sa na Program Board posunie do stavu Validating on staging/In Progress.

Požiadavka v stĺpci Validating on staging/In Progress je pre stakholderov signál pre spustenie akceptácie.

Vďaka Program Kanban boardu majú lepší prehľad o stave požiadaviek aj stakehodleri aj agilný tím. Každý je sústredený na svoje a má informácie v potrebnej miere detailu.

Iné príklady

Tento pattern nachádzame aj v iných prípadoch, ako napr.:

1. Review požiadavky
2. Analýza požiadavky
3. Nacenenie
4. UX Dizajn
5. Návrh architektúry
6. Feedback dodávateľa
7. Nasadenie na produkciu
8. Testovanie
9. Customer experience (CX)
10. Skúšobná prevádzka

Ako sa naučiť písať požiadavky v Agile?

Chcete sa naučiť písať požiadavky v Agile tíme správne? Napíšte nám a zapojíme vás či už do tréningu Perfektný Product Owner.