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.

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.

Téma, iniciatíva

Veľká, komplexná požiadavka, ktorú biznis potrebuje pre dosiahnutie vybraného cieľa, alebo kľúčového výsledku. Typicky je iniciatíva zapísaná v biznisovom jazyku a predstavuje napr.

• Mladá generácia majiteľov nehnuteľností.
• Nekonečné dáta pre podnikateľov.
• AI predikcia dodávok.

Viac o Iniciatíva…

Epik

Epik je komplexná požiadavka, ktorá je podčasťou biznisovej iniciatívy. Označuje zvyčajne z pohľadu zákazníka ucelenú funkcionalitu, ktorú vie zákazník reálne použiť. Má hodnotu, napr.

• Zabezpečenie malého spotrebného úveru.
• Reporty.
• Objednanie produktu.
• Nákupný košík.

Viac o Epiku…

User Story

User Story je zaujímavý formát písanai biznisových požiadaviek. Tie sú zvyčajne zamerané na konrétnu funkcnionalitu v danom epiku. User Stories sú dokončiteľné za 3-5 dní, zvyčajne na nich pracuje viacero členov tímu a zároveň je User Story sama o sebe hodnotnou. Zákazník, resp. používateľ, by mal vedieť používať v produkte výsledky doručené, reprezentované, danou user story. NIe je to teda aktivita.

Príklady User Stories:

• Pridanie klienta.
• Prihlásenie.
• Tlač dokumentu.
• Graf výnosov.
• Predikcia dodávky.

Viac o User Story…

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

• Ako na delenie požiadaviek? Časť 1: Podľa krokov procesu
• Ako na delenie požiadaviek? Časť 2: Podľa operácií
• Ako na delenie požiadaviek, časť 3: Podľa obchodného pravidla
• Epik epicky
• When to accept user story
• Príklad: Keď produktový vlastník chce záložku. Vyvarujte sa chýb pri písaní user story.
• Pripravená požiadavka

Ďalšie články

• Detailnejší pohľad na user story
• Úlohy alebo aj niečo viac?
• Ako na tvorbu produktu Agilne
• Ako na delenie požiadaviek
• Definition of Ready
• Definition of Done

Na stiahnutie