Späť
Základné a nadstavbové vzdelávacie programy pre tím.
Dlhodobá podpora tímov mentormi.
Spoznajte potenciál pre zlepšenia tímu.
Príprava a nastavenie tímu pre tvorbu komplexných produktov škálovaným Agile.
Ucelený a zmysluplný rozvoj tímu
Základné a nadstavbové vzdelávacie programy pre Scrum Mastrov.
Dlhodobé programy rozvoja schopností.
Identifikujte svoje potenciály pre ďalší profesionálny rozvoj.
Príprava Scrum Mastrov pre prácu v škálovanom Agile.
Pripravte sa na prácu produktového vlastníka škálovaného portfólia produktov.
Základné a nadstavbové vzdelávacie programy pre Produktových vlastníkov.
Príprava firmy pre škálovanie agilných praktík.
Vzdelávanie pripravujúce firmu pre zavedenie Agile.
Dlhodobé rozvojové programy pre zavedenie agilných praktík do firmy.
Hodnotenie agility firmy a identifikácia potenciálov pre ďalšie zlepšovanie.
Naše služby
TRÉNINGY
ROZVOJ
HODNOTENIE
ŠKÁLOVANIE
Ďalšie odkazy
Domov / Knowhow / 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ý 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.
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.
Viac o Iniciatíva…
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.
Viac o Epiku…
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:
Viac o User Story…
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.
Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity