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.

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

  • 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ík
  1. Predstavenie cieľov verzie.
  2. Predstavenie stakeholderov a klientov, ktorí budú danou verziou zasiahnutí a pre ktorých sa vlastnosti vyvíjajú.
  3. Predstavenie personas, pre ktoré majú byť vlastnosti implementované.
  4. Predstavenie features a epikov, popr. user stories.
  5. Spodrobnenie epikov na user stories. V niektorých tímoch to robia priamo členovia tímov.
  6. Definovanie akceptačných kritérií. Nemusia byť úplne presné, stačí úroveň potrebná pre hrubý odhad náročnosti pomocou story pointov.
Scrum master
  1. Organizácia stretnutia.
  2. Moderovanie stretnutia.
  3. Zabezpečenie potrebného materiálu pre workshop.
  4. Evidencia rizík.
  5. V prípade plánovania viacerými tímami vzájomná synchronizácia tímov prostredníctvom ďalších ScrumMastrov.
Tím
  1. Porozumenie požiadaviek
  2. Rozdelenie epikov na user stories (po dohode s produktovým vlastníkom).
  3. Pomoc s definíciou akceptačných kritérií.
  4. Identifikácia rizík.
  5. Odhad náročnosti implementácie, komplexnosti.
  6. Review poradia požiadaviek.
  7. Identifikácia závislostí, interných aj na iných systémoch.
  8. 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ízii
  • Predstavenie hlavných zámerov biznisu pre danú verziu
Vízia produktu, elevator statement10 min.
  • Revízia napĺňania produktovej vízie
  • Pripomenutie si elevator statementu produktu
  • Ak to je potrebné
Dôležité míľniky verzie10 min.
  • Míľniky, významné dátumy ovplyvňujúce dodávku plánovanej verzie
  • Termíny jednotlivých sprintov verzie
  • Míľ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 sprintov
  • Zaradenie 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 odhadom
  • Ak 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žiadaviek

Odhad náročnosti

Zaradenie do sprintov

Pripomienkovanie poradia

3 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

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