SCRUM: Burndown diagram
Jaké by bylo skvělé, kdyby se dal stav projektu (resp. aktuální etapy projektu) vyjádřit jedním jednoduchým grafem? Právě toto je SCRUMe možné, když požijeme Burndown diagram. Pomocí něj lze zjistit, kolik úkolů potřebujeme dokončit v aktuálním sprintu. Burndown diagram se vždy týká aktuálního sprintu. Nový sprint se rovná nový Burndown diagram.
Ideální graf má předpis funkce y = [konstanta_celkového_objemu_práce_v_sprintu] - x. Na horizontální ose (x) je počet dní aktuálního sprintu. Na vertikální ose (y) je objem práce, který se přísluší aktuálnímu sprintu. Ideální graf sprintu ve SCRUMu můžeme přirovnat ke stejné utopii jako požadovanému stavu, že všichni lidé budou rádi pracovat dobrovolně sami od sebe tam, kde je bude společnost potřebovat a budou si kupovat jen to, co budou nutně potřebovat a tedy můžeme zrušit peníze (copyright této parafrázované myšlenky mají pánové Marx a Engels).
Burndown diagram má (resp. musí) směřovat na stav y=0, což znamená, že všechny úkoly jsou splněny, tedy objem práce, který přísluší aktuálnímu sprintu je roven 0. Tento stav je ale možné dosáhnout pouze v laboratorních podmínkách. Ve skutečných projektech graf kola kolem ideálního stavu – jednou se nám jde karta a zvládneme větší objem prací, jindy například zjistíme, že junioři (studenti) mají před zápočtovkami a nemají takovou produktivitu, jakou jsme od nich původně očekávali, nebo zjistíme, že využití jedné technologie vyžaduje nastudování jiné technologie pro správné a kvalitní nasazení. Jak víme, v SCRUMe je kvalita výstupního softwaru prvořadá. Pamatujete si na závěr rapové skladby JBMNT? Možná je vývoj skladeb Kontrafaktu řízený SCRUMem..
Není to ideální?
Co když graf vypovídá, že se sprint dokončí dříve, než se plánoval? Může jít o excelentní vypracování týmem, který v důsledku začátku sprintu vynaložil více úsilí, než je průměrné tempo jejich práce. Může jít ale io špatně plánování úkolů, jejichž čas byl přeceněn, což si Product Owner může vyložit jako mrhání finančních prostředků. SCRUM Master by si měl posvítit na kvalitu odvedené práce. Skutečně jsou dané úkoly vyřešeny, nebo jsou vyřešeny pouze povrchně? Budeme je muset později předělávat, co nám (předělávání po implementaci) zabere 10x více času než teď? A co produktivita? Víte, jak produktivní je programátor, který dělal celou sobotu a neděli, když dojde v pondělí (8. den práce bez přestávky) ráno do práce? Zkušený SCRUM Master by měl vědět, kdy má přibrzdit, aby tým byl v dobré náladě a aby dokázal dosahovat konstantní výkony.
Co když graf vypovídá, že sprint se nestíhá dokončit ve stanoveném termínu? Opět můžeme konstatovat, že byl sprint nevhodně naplánován, síly byly přeceněny. Možná SCRUM Master plánoval práce šlehem "když každý den budeme propichovat své síly, tak stíháme i toto...". To je jako by si studentka Danka naplánovala, že vyrazí hodinu před přednáškou, když její cesta tramvají z Dúbravky bude trvat 55 minut. Téměř jistě vejde do přednáškové místnosti s bagetou v ústech v době, kdy už bude přednášející v plném proudu a bude na ni divně zahlížet a snažit si zapamatovat její tvář... Nebo to je jako by student Josef vybíral v internetovém plánovači, jaké potahy bude mít jeho nová Škoda Octavia RS, kterou si plánuje koupit o 3 měsíce, ale nový úvěr si brát nechce, vždyť právě dosplatil svou starou Daci. Je téměř jistě koupi nestihne.
Co když se graf ani zdaleka nepodobá předpisu funkce y = konstanta -x? Opět chybu můžeme vidět ve špatném odhadnutí času práci SCRUM Masterem. Možná je takto naplánován projekt "nad síly" týmu v současném složení. Tím by měl vyřešit nejprve lehčí úkoly, při kterých se sehraje tak, aby mohl "vstoupit na led sehraný ve druhé a třetí třetině, ukázat co v něm je" a pokusit se otočit výsledek.
Volba osy Y
V Burndown grafu máte několik možností, kterou veličinu nanést na osu Y, například počet User Stories ve sprintu. O čem to ale vypovídá? Kdybych hádal, kolik máte peněz v peněžence a vy byste mi řekli, kolik máte bankovek v peněžence, ani zdaleka neumím odhadnout, kolik peněz máte.
Podle mě, nejlepší je osa Y volit v člověkohodinách všech členů týmu. Celkový dostupný čas sprintu lze vyjádřit takto:
Celkový dostupný čas = POCET_DNI_SPRINTU * POCET_TEAM_MEMBEROV * 8
za předpokladu, že průměrná délka pracovního dne je 8 hodin.
Třeba počítat s tím, že odhad celkové práce je pouze odhad a nemusí být v úplně ve shodě se skutečností. Například vychází z předpokladu, že všichni dělají práci stejně efektivně, co není pravda. Je to ale dostatečně užitečný odhad pro účely projektu. Mělby počítat s rezervou v případě problémů. A drobné problémy (resp. výzvy řešení) určitě nastanou.
Úskalí
Dokonce, i když náš Burndown graf aktuálního sprintu se podobá alespoň přibližně ideálnímu, nemusí to tak zůstat. Můžeme přijít na zásadní chybu při interním testování jiné User Story. Můžeme tedy zjistit, že User Story, kterou jsme označili za dokončenou, tak není dokončena. Z praxe, toto se stává junior programátorem, kteří pochopí úlohu, vykonají ji na 80%, přičemž stále zůstává 20% nedokončené práce, kterou přehlédli (např. program nereaguje na takovou kombinaci vstupních údajů, kterou nepředpokládali).
V duchu agilního vývoje zákazník může změnit resp. upravit specifikaci, čímž se znovu otevřou uzavřené úkoly ve sprintu. Bereme to tak, že se jedná o jemné úpravy, pro které nebudeme svolávat Backlog Refinement Meeting. Neodpouštím si, že zákazník rád tuto změnu nazývá „bugem“, čímž dává najevo, že on chybu neudělal, možná jsme se jen špatně pochopili. V praxi je jedno, jak to zákazník volá, jde o to, že i změny i bugy je třeba v duchu agilního vývoje ze softwaru odstranit ještě před dokončením sprintu.
Jak začít programovat?
Úvod do programování pro každého bez předchozích znalostí.
Stáhněte si náš ebook teď výjimečně zdarma!!!
Čo musíte vedieť o SCRUMe, aby ste vytvorili niekoľkonásobne kvalitnejší produkt za zlomok času? Stiahnite si náš ebook teraz zdarma:
Marián Knězek