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 / Blog / 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.
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“.
Z dlhodobého pohľadu viacero vecí:
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.
Tento pattern nachádzame aj v iných prípadoch, ako napr.:
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.
Prečo, ako, čo, pre koho? Keď si dáme dokopy otázky ktoré počujeme najčastejšie, bude to pravdepodobne zoznam ktorý...
Rozmachom Agile sa paleta nástrojov a praktík používaných pri vývoji produktov v IT prudko zväčšila. Začiatok...
...
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