Agilné postupy, pre nezainteresovaných a nedostatočne informovaných, sa niekedy môžu javiť ako metodiky vývoja softvéru ad hoc a projektového riadenia. Pravda je úplne iná.
Jeden z 12 princípov agilného softvéru uvádza: „Najlepšie architektúry, požiadavky a dizajn vychádzajú zo samoorganizujúcich sa tímov.“ Avšak väčšina organizácií, ktoré uplatňujú agilné postupy, vrátane scrumu a Kanbanu, presadzuje niektoré významné procesné dôsledky a rituály. Napríklad veľa organizácií implementuje agilné plánovacie postupy vrátane odhadu príbehových bodov, štandardov architektúry a disciplín riadenia vydaní na zlepšenie obchodného dopadu, kvality a spoľahlivosti vydaní aplikácií.
Väčšina tímov sa rozhodne používať agilný nástroj, ako je Jira Software alebo Azure DevOps, na správu nevybavených položiek, šprintov a spolupráce medzi agilnými tímami. Primárnym účelom týchto nástrojov je centrálne spravovať požiadavky, stav šprintu, pracovný tok a spoluprácu medzi agilnými členmi tímu a viacerými agilnými tímami. Čím dôslednejšie organizácie však používajú tieto nástroje, tým viac môžu tieto nástroje pomôcť vedúcim a tímom identifikovať problémy, podávať správy zainteresovaným stranám o stave a zlepšovať ich vykonávanie.
Jednou z najbežnejších okamžitých správ je správa o spustení. Pretože agilné postupy umožňujú vlastníkom produktov opätovne určiť prioritu nevybavených položiek na základe spätnej väzby od zákazníkov, tradičné správy, ako sú Ganttove diagramy, nezachytávajú plynulosť agilného vykonávania. Základné pre graf podrobností je, že zohľadňuje dokončenú prácu, novú prácu pridanú do rozsahu a ďalšie zmeny rozsahu. Burndown graf môže poskytnúť rýchly obraz o tom, ako tímy kráčajú k svojim cieľom.
Čítanie základnej tabuľky otáčok šprintu
Burndownove grafy majú zvyčajne čas na osi x a odhady na osi y. Mnoho tímov odhaduje v bodoch príbehu, ale veľa agilných nástrojov dokáže mapovať vyčerpanie podľa počtu príbehov alebo odhadov v hodinách. V tomto článku predpokladám, že sa budú používať príbehové body.
Správa o spustení sprintu vykreslí počet bodov príbehu, ktoré sú v rozsahu pre časový interval. Keď tím dokončuje príbehy, graf ukazuje, ako „vypaľujú“ zoznam príbehov a iných typov práce (problémy v Jire, typy pracovných položiek v Azure DevOps), kým nie je práca dokončená alebo kým sa šprint neukončí. Keď tímy dokončia prácu venovanú šprintu, vynesená čiara pretína os x, čo naznačuje, že je všetko hotové.
Koncepcia sprintu je najjednoduchšia. Prvý deň v šprinte sa tím zaviaže k niektorým príbehom a celkovému počtu bodov príbehu. Ak si v ten deň pozriete graf útlmu, mal by sa na osi y zobraziť jediný bod predstavujúci počet bodov, ku ktorým sa tím zaviazal v deň nultého sprintu.
Keď sú príbehy označené ako odbavené, podrobný rozpis sprintu zobrazuje zostávajúci počet bodov, ktoré je potrebné dokončiť.
Ako sa v praxi využíva rozjazd sprintu? Zdravý útlm vykazuje lineárnu a ideálne exponenciálnu krivku až po nulu. Ak má zákruta v počiatočnej časti šprintu plochý sklon, môže to znamenať bloky alebo veľa rozpracovanej práce a že šprint môže byť ohrozený. Plochý alebo pomaly klesajúci pokles môže byť veľmi problematický, ak sa veľa testuje na príbehoch dokončených pomocou kódu a ak testovacie práce nemôžu začať skôr ako v posledných dňoch sprintu.
Rýchlo klesajúci pokles sprintu je všeobecne dobrá vec, ale môže to naznačovať, že tím je nedostatočný alebo sa rozhodol v sprinte prijať iba menšie príbehy.
Epické zmeny sledujú pokrok oproti obchodným a technickým faktorom
Zistenia sprintu sú veľmi užitočné na sledovanie krátkodobého vykonania a pomáhajú tímom úspešne plniť záväzky sprintu. Na lepšie sledovanie pokroku oproti dlhodobým cieľom je potrebné zviditeľniť epické a uvoľňovacie rozpisy.
Epické zmeny fungujú najlepšie, keď tímy definujú niekoľko dlhodobých snáh, ako je implementácia hlavných schopností koncových používateľov, stratégie technického dlhu, vylepšenia výkonu alebo vývoj procesov. Na využitie výhod epického burndownu by mal mať backlog:
- Medzi piatimi a 15 eposmi, ktoré budú trvať najmenej niekoľko mesiacov a ktorých dokončenie vyžaduje šesť alebo viac šprintov.
- Funkcie, príbehy a pahýly príbehov, ktoré sa valia pod eposom a predstavujú plán na vysokej úrovni na uskutočnenie eposu.
- Odhady na vysokej úrovni, ideálne v bodoch príbehu pre každý príbeh alebo príbeh, ktorý spadá pod eposy.
Len čo budú zavedené, epické zmeny zaznamenajú zmeny v tomto pláne. Jeho os x predstavuje šprinty a os y predstavuje celkový odhad príbehov a častí príbehov priradených k eposu. V epickom grafe rozbaľovacieho programu Jira Software vidíte stĺpcový graf s jednou farbou, ktorá predstavuje príbehy dokončené v šprinte a druhou, ktorá zobrazuje pridané body príbehu. Body príbehu sa zvyšujú, keď sa k eposu pridajú nové príbehy alebo pahýly príbehov alebo keď sa zmenia odhady.
Existuje niekoľko spôsobov, ako použiť graf epického rozpadu:
- Ilustruje rýchlosť dokončovania funkcií a príbehov oproti plánu. Keď sú plány presné a konzistentné s rýchlosťou tímu, môže to poskytnúť indikátor po dokončení práce eposu.
- Väčšina agilných plánov nie je úplná a tímy pridávajú, menia a odstraňujú príbehy na základe spätnej väzby koncových používateľov, objavenia technických komplikácií a riešenia technického dlhu zavedeného počas cesty. Epické rozloženie potom naznačuje, ako ďaleko od plánu je epos založený na tom, ako veľmi rastie počet nevybavených vecí oproti dokončeniu šprintom za šprintom.
- Epické rozpisy tiež pomáhajú porovnávať úsilie vo viacerých šprintoch a merajú, koľko práce na plánovaní a dodaní sa robí v jednom epose oproti iným.
Burndowns vydaní informujú tímy, či vydania zasiahnu dátum a rozsah
Pokročilé tímy, ktoré plne automatizujú svoje doručovacie kanály pomocou nepretržitej integrácie, nepretržitého testovania a nepretržitého doručovania, nemusia potrebovať zverejnenie informácií o vydaní. Tímy, ktoré nasadzujú často, by mali sledovať, ktoré funkcie a príbehy sa viažu k vydaniu, ale podrobný prehľad vydaní nie je príliš užitočný, pretože často sleduje pokrok v šprinte.
Pre ďalšie tímy, ktoré dodržiavajú postupy správy vydaní a štandardizujú vydania s viacerými výtlačkami, môže byť vydanie vydania najdôležitejším nástrojom vlastníka produktu a tímu.
Burndown verzie je podobný epickému burndownu okrem toho, že namiesto sledovania funkcií, príbehov a stubov príbehov priradených k eposu, burndown vydania ukazuje, čo je priradené k vydaniu. Os a pruhy sú potom identické s epickými podrobnosťami.
Tímy, ktoré využívajú znižovanie vydaní, tak môžu sledovať rozsah a časovú os vydania. Tímy, ktoré sú na ceste, uvidia klesajúci sklon až k osi x so sklonom zodpovedajúcim rýchlosti tímu. Vydania, ktoré sa môžu krútiť mimo trať, majú buď menší sklon, alebo zobrazujú viac pridaných príbehových bodov (keď je do vydania pridaný väčší rozsah) ako dokončované.
S týmito projekciami vám pomáha Jira Software. Za predpokladu, že tím pracoval na projekte najmenej tri šprinty, Jira Software vypočíta priemernú rýchlosť tímu a na základe tejto rýchlosti predpovedá konečný šprint pre vydanie.
Zúženie sprintu, epiky a uvoľnenia dáva tímom niekoľko ľahko použiteľných nástrojov na zosúladenie cieľov. Keď majú tímy spoločné pochopenie rozsahu, dohodnú sa na prioritách, naplánujú niekoľko šprintov dopredu a zodpovedajúcim spôsobom označia príbehy v backlogu, podrobný rozbor vypovie o tom, či je plánovanie a vykonávanie v súlade s cieľmi. Ak nie sú, jedná sa o nástroj založený na údajoch, ktorý môže podnietiť diskusiu o tom, aké úpravy môžu byť potrebné.
