SCRUM: Burndown diagram
Aké by bolo skvelé, keby sa dal stav projektu (resp. aktuálnej etapy projektu) vyjadriť jedným jednoduchým grafom? Práve toto je SCRUMe možné, keď požijeme Burndown diagram. Pomocou neho je možné zistiť, koľko úloh potrebujeme dokončiť v aktuálnom šprinte. Burndown diagram sa vždy týka aktuálneho šprintu. Nový šprint sa rovná nový Burndown diagram.
Ideálny graf ma predpis funkcie y = [konštanta_celkoveho_objemu_práce_v_šprinte] - x. Na horizontálnej osi (x) je počet dní aktuálneho šprintu. Na vertikálnej osi (y) je objem práce, ktorý sa prináleží aktuálnemu šprintu. Ideálny graf šprintu v SCRUMe môžeme prirovnať k rovnakej utópií, ako želanému stavu, že všetci ľudia budú radi pracovať dobrovoľne sami od seba tam, kde ich bude spoločnosť potrebovať a budú si kupovať len to, čo budú nutne potrebovať a teda môžeme zrušiť peniaze (copyright tejto parafrázovanej myšlienky majú páni Marx a Engels).
Burndown diagram má (resp. musí) smerovať na stav y=0, čo znamená, že všetky úlohy sú splnené, teda objem práce, ktorý prináleží aktuálnemu šprintu je rovný 0. Tento stav je ale možné dosiahnuť iba v laboratórnych podmienkach. V skutočných projektoch graf kolíše okolo ideálneho stavu – raz sa nám ide karta a zvládneme väčší objem prác, inokedy napríklad zistíme, že juniori (študenti) majú pred zápočtovkami a nemajú takú produktivitu, akú sme od nich pôvodne očakávali, alebo zistíme, že využitie jednej technológie vyžaduje naštudovanie inej technológie pre správne a kvalitné nasadenie. Ako vieme, v SCRUMe je kvalita výstupného softvéru prvoradá. Pamätáte si na záver rapovej skladby JBMNT? Možno je vývoj skladieb Kontrafaktu riadený SCRUMom..
Nie je to ideálne?
Čo ak graf vypovedá, že sa šprint dokončí skorej, ako sa plánoval? Môže ísť o excelentné vypracovanie tímom, ktorý v dôsledku začiatku šprintu vynaložil viac úsilia, ako je priemerné tempo ich práce. Môže ísť ale aj o zle plánovanie úloh, ktorých čas bol precenený, čo si Product Owner môže vyložiť ako mrhanie finančných prostriedkov. SCRUM Master by si mal posvietiť na kvalitu odvedenej práce. Skutočne sú dané úlohy vyriešené, alebo sú vyriešené iba povrchne? Budeme ich musieť neskôr prerábať, čo nám (prerábanie po implementácií) zaberie 10x viac času ako teraz? A čo produktivita? Viete, aký produktívny je programátor, ktorý robil celú sobotu a nedeľu, keď dôjde v pondelok (8. deň práce bez prestávky) ráno do práce? Skúsený SCRUM Master by mal vedieť, kedy má pribrzdiť, aby tím bol v dobrej nálade a aby dokázal dosahovať konštantné výkony.
Čo ak graf vypovedá, že šprint sa nestíha dokončiť v stanovenom termíne? Opäť môžeme konštatovať, že bol šprint nevhodne naplánovaný, sily boli precenené. Možno SCRUM Master plánoval práce šlýmom „keď každý deň budeme prepínať svoje sily, tak stíhame aj toto…“. To je ako by si študentka Danka naplánovala, že vyrazí hodinu pred prednáškou, keď jej cesta električkou z Dúbravky bude trvať 55 min. Takmer určite vojde do prednáškovej miestnosti s bagetou v ústach v čase, keď už bude prednášajúci v plnom prúde a bude na ňu divne zazerať a snažiť si zapamätať jej tvár... Alebo to je ako by študent Jozef vyberal v internetovom plánovači, aké poťahy bude mať jeho nová Škoda Octavia RS, ktorú si plánuje kúpiť o 3 mesiace, no nový úver si brať nechce, veď práve dosplácal svoju starú Dáciu. Je takmer isto kúpu nestihne.
Čo ak sa graf ani zďaleka nepodobá predpisu funkcie y = konštanta -x? Opäť chybu môžeme vidieť v zlom odhadnutí času prác SCRUM Masterom. Možno je takto naplánovaný projekt „nad sily“ tímu v súčasnom zložení. Tím by mal vyriešiť najprv ľahšie úlohy, pri ktorých sa zohrá tak, aby mohol „vstúpiť na ľad zohratý v druhej a tretej tretine, ukázať čo v ňom je“ a pokúsiť sa otočiť výsledok.
Voľba osi Y
V Burndown grafe máte viacero možností, ktorú veličinu naniesť na os Y, napríklad počet User Stories v šprinte. O čom to ale vypovedá? Keby som hádal, koľko máte peňazí v peňaženke a vy by ste mi povedali, koľko máte bankoviek v peňaženke, ani zďaleka neviem odhadnúť, koľko peňazí máte.
Podľa mňa, najlepšie je os Y voliť v človekohodinách všetkých členov tímu. Celkový dostupný čas šprintu je možné vyjadriť takto:
Celkový dostupný čas = POCET_DNI_SPRINTU * POCET_TEAM_MEMBEROV * 8
za predpokladu, že priemerná dĺžka pracovného dňa je 8 hodín.
Treba počítať s tým, že odhad celkovej práce je iba odhad a nemusí byť v úplne v zhode so skutočnosťou. Napríklad vychádza z predpokladu, že všetci robia prácu rovnako efektívne, čo nie je pravda. Je to ale dostatočne užitočný odhad pre účely projektu. Mal by počítať s rezervou v prípade problémov. A drobné problémy (resp. výzvy riešenia) určite nastanú.
Úskalia
Dokonca, aj keď náš Burndown graf aktuálneho šprintu sa podobá aspoň približne ideálnemu, nemusí to tak zostať. Môžeme príjsť na zásadnú chybu pri internom testovaní inej User Story. Môžeme teda zistiť, že User Story, ktorú sme označili za dokončenú, tak nie je dokončená. Z praxe, toto sa stáva junior programátorom, ktorí pochopia úlohu, vykonajú ju na 80%, pričom stále ostáva 20% nedokončenej práce, ktorú prehliadli (napr. program nereaguje na takú kombináciu vstupných údajov, ktorú nepredpokladali).
V duchu agilného vývoja zákazník môže zmeniť resp. upraviť špecifikáciu, čím sa znovu otvoria uzavreté úlohy v šprinte. Berieme to tak, že ide o jemné úpravy, pre ktoré nebudeme zvolávať Backlog Refinement Meeting. Neodpustím si, že zákazník rád túto zmenu nazýva „bugom“, čím dáva najavo, že on chybu neurobil, možno sme sa len zle pochopili. V praxi je jedno, ako to zákazník volá, ide o to, že aj zmeny aj bugy treba v duchu agilného vývoja zo softvéru odstrániť ešte pred dokončením šprintu.
Ako začať programovať?
Úvod do programovania pre každého bez prechádzajúcich znalostí.
Stiahnite so náš ebook teraz výnimočne 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