icon
V máji a júni vás pozývame na tréningy Základy Agile a Scrum a Scrum Mastership zmysluplne.
→

Plánovanie v Agile

Plánovanie v Agile je viacúrovňové. Nezameriava iba na vývoj v sprintoch, teda 2–3 týždenných iteráciách. Naopak, plánovanie agilne vytváraného produktu začína jasnou víziou a stratégiou priebežne dodávaných vlastností.

Plánovanie Agile
Plánovanie Agile

Agilné plánovanie prebieha v nasledujúcich úrovniach:

  • Vízia – ako má produkt vyzerať o päť rokov. Čím produkt je, čo nie je. Pre koho je. Priebežne validovaná raz ročne, zvyčajne biznisom, chief product ownerom, manažmentom.
  • Produktová roadmapa – stratégia pre dodávku Minimum Viable Product/Minium Marketable Produkt odpovedajúcich biznis iniciatívam. Pokrýva stredný horizont dodávok, pribežne plánovaná a validovaná typicky každý štvrťrok.
  • Produkt inkrement plán – plán ďalšej verzie s konkrétnymi epikmi pre vybrané biznis iniciatívy. PI plán typicky pokrýva plán 3-6 sprintov s rozdelením epikov na user stories zaradených do jednotlivých sprintov. Končí často novou hlavnou verziou produktu. Táto môže byť nasadzovaná pre klienta v menších verziách aj priebežne.
  • Sprint – krátkodobý plán (2-3 týždne) realizácie vybraných, najhodnotnejších, najpotrebnejších, user stories. Končí novým prírastkom produktu, ktorý nemusí byť, no môže byť klientovi aj nasadený.
  • Deň – denná koordinácia vývoja s tímom, identifikácia a riadenie rizík, priebežné riadenie zmien rozsahu aktálneho sprintu na základe požiadaviek používateľov, resp. zmien identifikovaných počas akceptácie.

Viac o plánovaní v Agile:

  • Inkrement produktu
  • Backlog refinement
  • Plánovanie sprintu
  • Preplanning sprintu
  • Odhadovanie v Agile
  • Kapacita tímu v sprinte

Na stiahnutie

Product Increment planning

Ciele | Aktivity | Agenda | Príklady plánovania

Produkt inkrement (PI) je väčším balíkom zmien, vlastností, ktoré sú vytvorené počas dlhšieho časového obdobia. Je to väčšia iterácia zahŕňajúca 3-6 sprintov. Neznamená to však, že počas daného obdobia nemôžu byť fyzicky nasadené viaceré minor verzie produktu. PI je typicky identifikovaný ako major verzia.

Plánovanie so strednodobým horizontom tímu umožňuje mať výhľad do budúcnosti a prispôsobiť tak napr. architektúru, alebo dizajn pripravovaným vlastnostiam bez nutnosti ich redizajnu.

Dĺžka trvania plánovacieho stretnutia závisí od dĺžky obdobia, pre ktoré sa plánuje práca, od komplikovanosti požiadaviek a závislostí na iných sytémoch. Z praktického života sa ukazuje, že plánovanie verzie typicky trvá jeden deň. V komplexnejších prípadoch to môže byť aj 3 dni.

Ciele PI Planningu

  • Spoznať plány na dlhšie časové obdobie.
  • Identifikovať prepojenie verzie na víziu a stratégiu produktu.
  • Predstavenie features, epikov a ich spodrobnenie do user stories.
  • Identifikovať riziká.
  • Identifikovať obmedzenia, ktoré bránia dokončeniu vlastností.
  • Nastavenie správneho poradia požiadaviek.
  • Zaradenie požiadaviek do sprintu.
  • Hrubý odhad náročnosti, komplexnosti, požiadaviek v story pointoch.
  • Identifikácia závislostí na iných systémoch.
  • Zladenie vývojových plánov závislých systémov.
  • Identifikáciu chýbajúcich informácií.
  • Pochopenie zámerov celým tímom.
  • Dohodnutie kľúčových termínov, míľnikov.

Aktivity

RolaAktivity
Produktový vlastníkPredstavenie cieľov verzie.Predstavenie stakeholderov a klientov, ktorí budú danou verziou zasiahnutí a pre ktorých sa vlastnosti vyvíjajú.Predstavenie personas, pre ktoré majú byť vlastnosti implementované.Predstavenie features a epikov, popr. user stories.Spodrobnenie epikov na user stories. V niektorých tímoch to robia priamo členovia tímov.Definovanie akceptačných kritérií. Nemusia byť úplne presné, stačí úroveň potrebná pre hrubý odhad náročnosti pomocou story pointov.
Scrum masterOrganizácia stretnutia.Moderovanie stretnutia.Zabezpečenie potrebného materiálu pre workshop.Evidencia rizík.V prípade plánovania viacerými tímami vzájomná synchronizácia tímov prostredníctvom ďalších ScrumMastrov.
TímPorozumenie požiadaviekRozdelenie epikov na user stories (po dohode s produktovým vlastníkom).Pomoc s definíciou akceptačných kritérií.Identifikácia rizík.Odhad náročnosti implementácie, komplexnosti.Review poradia požiadaviek.Identifikácia závislostí, interných aj na iných systémoch.Prepis požiadaviek do backlogu produktu (záleží na dohode s produktovým vlastníkom).

Agenda

AktivitaTrvanie(max)Popis
Agenda5 min.Predstavenie agendy
Ciele verzie5 min.Hlavné ciele verizie posúvajúce produkt bližšie k víziiPredstavenie hlavných zámerov biznisu pre danú verziu
Vízia produktu, elevator statement10 min.Revízia napĺňania produktovej víziePripomenutie si elevator statementu produktuAk to je potrebné
Dôležité míľniky verzie10 min.Míľniky, významné dátumy ovplyvňujúce dodávku plánovanej verzieTermíny jednotlivých sprintov verzieMíľniky súvisiacich, závislých, systémov, na ktoré je potrebné nadviazať
Stav predošlých sprintov15 min.Revízia nedokončených vlastností predchádzajúcej verzie a jej sprintovZaradenie prípadných nedokončených user stories do plánovanej verzie
Revízia Hotovo10 min.Review Definition of Done, jej pripomenutie si kvôli lepším odhadomAk je to potrebné
Zoznámenie sa s vlastnosťami4 – 16 hod.Predstavenie jednotlivých epikov a user stories.Pre začiatok stačia najvýznamejšie epiky.Revízia a upresnenie akceptačných kritérií
Identifikácia závislostíIdentifikácia závislostí. Interných medzi tímami pracujúcimi na rovnakom produkte, aj medzi systémové závislosti na iných tímoch.
Identifikácia rizík a obmedzeníIdentifikované technologické a biznis riziká počas zoznámenia sa s požiadavkami
Poradie požiadaviekOdhad náročnostiZaradenie do sprintovPripomienkovanie poradia3 hod.Počas tejto časti tím sa zaoberá: Odhadom náročnosti v story pointoch,Stanovením správneho poradia. Prvotné poradie dané produktovým vlastníkom podľa biznisu. Poradie môže byť upravené v závislosti od technologického riešenia a závislosti na iných tímoch, systémoch.Rozdelenie požiadaviek do jednotlivých sprintov podľa velocity a pocitu tímu.Revízia výsledného poradia produktovým vlastníkom. Zmena poradia v prípadoch kedy nevyhovuje biznisovému pohľadu.
Spoločné schválenie plánu verzie15 min.Záväzok celého tímu dodať takto naplánovanú verziu.

Príklady PI plánovania

[obr]

Výber z blogu o plánovaní v Agile

Viac o PI planningu

  • Inkrement produktu
  • Odhadovanie v Agile
  • Ako to je Agilne
  • Kapacita tímu v sprinte
  • Tvorba produktu agilne

Na stiahnutie

Product increment mini

Novinky

Naše Agiloviny

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

Posielať na

spracovaním osobných údajov

Ďakujeme