Burndown grafy

Sice už jsem tu párkrát o burndown grafech psala, ale nedávno jsem rozšířila a opravila původní template, a nakonec, opakování je matka moudrosti, tak ho tu popíšu ještě jednou.

Microsoft Excel Scrum Burndown template najdete zde.

A teď k popisu jednotlivých záložek. Na prvním obrázku je reprezentace product backlogu. V levé části jsou definovány jednotlivé Super User Story a User Story, spolu s ohodnocením. V pravé části je zaznamenán progress na konkrétní User Story v daném Sprintu.

backlog-representation

V další záložce se vlastně všechna data počítají. Jediné co musíte udělat je každý Sprint vyplnit aktuální hodnoty do sloupce C a D – Data from Backlog (Points Remaining Velocity a Actual Points Complete). Zároveň před začátkem projektu nastavit očekávanou rychlost týmu a buffer / očekávaný přírůstek bodů za sprint – sloupce K a L (Plan: Planned Velocity a Planned New Points (Buffer)). Chcete-li sledovat i jak se Vám posouvá datum konce projektu, vyplňte si na začátku projektu i v Planned Date sekci sloupec F (Target Date) a každý Sprint aktuální predikci v Planned Date sekci sloupec E (Projected Completion Date). Všechno ostatní se počítá a kreslí za Vás.

burndown-data

A následují grafy. První z nich sleduje plánovanou rychlost týmu a porovnává ji s aktuálními hodnotami, kterých tým byl schopen dosáhnout.

burndown-velocity-rychlost-graf

Další graf zobrazuje klasický burndown graf rozšířený o predikce kdy očekáváme, že bude projekt hotový. V jednoduchosti řečeno, pokud se pohybujete mezi tečkovanými čárami, běží vše podle očekávání.

burndown-graf

Poslední graf který v souboru najdete Vám ukazuje jak se v čase měnilo předpokládané ukončení projektu.

burndown-project-completion-date

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

  • Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
  • Lepítka na jednotlivé user story v backlogu.
  • Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
  • Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:
    • Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10
    • Odbory prosadily kratší pracovní týden – 5b
    • Je Den Železničářů, v poledne se jde do hospody – 4b
    • Včera pršelo, vypili jsme moc rumu – 3b

    Ale také třeba takto:

    • Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b
    • Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b
    • V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

  • Větší hodiny měřící délku Sprintu, my jsme zvolili:
    • 5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint
    • 5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

    Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

  • Zákazníka – toho budete pravděpodobně hrát Vy – který může:
    • Chtít vidět další města
    • Změnit svá přání

    Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

GoogleDocs, Backlog a Burndown Graf

O tom k čemu využít Burndown graf už jsme psala v minulém příspěvku. Template pro Microsoft Excel je k dispozici také. Nicméně takový Excel se špatně sdílí mezi distribuovanými týmy. Jednou z možností je použití nějakého komplexního online systému, ale to s sebou obvykle nese další výdaje na licence a často i omezení Vašeho procesu.

Dobrým řešením je použít GoogleDocs. Tady je jako public příklad, jak by mohl Burndown vypadat (http://spreadsheets.google.com/ccc?key=p8oML5C9M–uwofmhl1npew).

První list obsahuje Produkt Backlog. Každý Sprint se zaloguje kolik bodů se udělalo, a kolik ještě zbývá.

Tyto hodnoty je následně nutné přenést do oranžově orámované části. Zbytek už se dopočítá automaticky.

Velocity Graf je prvním ze série grafů. Červená oblast zobrazuje počet bodů, které by tým měl stihnout za jeden dané Sprinty. Modrá křivka odpovídá aktuálním výsledkům.

Dalším grafem je tradiční Burndown Graf, který modře zobrazuje, kolik bodů ještě zbývá, oranžově kolik se již dokončilo a červeně případné změny bodového hodnocení (viz řádky 10, 11 v Backlogu).

Poslední graf zobrazuje Burndown z pohledu očekávaného dokončení projektu. Modrá křivka zobrazuje aktuální počet bodů, co zbývá dokončit, červená je potom projekcí ukončení projektu. Obecně se dá říct, že pokud je modrá a červená křivka uvnitř oranžové a zelené oblasti, očekávaný konec projektu je stále v rámci projekt bufferu a vše je v pořádku.

Vyhodnocení Sprintu

Posledním krokem Sprint cyklu je vyhodnocení výsledků. Příslušný počet bodů za dokončené úlohy se odečte z produkt backlogu a ze zbývajícího počtu bodů a rychlosti týmu se upraví očekávaný konec projektu. V ideálním případě by tým měl dokončit všechny úlohy, které v rámci plánovacího meetingu naplánoval a které se zavázal splnit. To ovšem v reálu není vždy pravidlem a obzvláště na začátku, než tým dostatečně vstřebá hodnotu bodu a naučí se plánovat, se skutečnost bude od původního záměru odlišovat. Nezapomeňte, že hlavním cílem je naučit tým dobře plánovat a odhadovat svoji práci. Takže po každém Sprintu by měl tým dostatečně dobře vidět, nakolik se od plánu odlišuje, a uvědomit si proč to je. A při příštím plánováni se případných chyb vyvarovat.

Obecně je dobré udělat krátkou prezentaci, kde se porovná plánování a výsledky jednotlivých týmů za končící Sprint. Jednou z oblíbených Agile metod vizualizace jsou Burndown grafy (o tom více v dalším příspěvku). Současně je dobré ukázat progres celého projektu a jeho milestonů, aby týmy přímo viděli, jak se projekt posouvá jako celek a jestli je na tom dobře (Critical Chain úlohy, Concerto graf). Zhodnocení sprintu může pak přímo přejít do plánovacího meetingu, kde jednotlivé týmy připraví plán na další Sprint. Tyto dílčí plánovací meetingy je lepší mít odděleně pro jednotlivé týmy, výsledné plány na nový Sprint by ale týmy měly v rychlosti prezentovat zase veřejně, aby vzniklo povědomí o tom, co dělají jednotlivé skupiny, kolik bodů plánují a jak se jim následně daří plán plnit.

Proces plánování – Sprint pre-planning

Je načase trochu popsat jak probíhá podle Agile a SCRUM plánování. Produkt backlog už máme definovaný, Story či jednotlivé úlohy jsou ohodnoceny body. Před každým začátkem Sprintu sezvěte tzv. expert-tým složený z klíčových lidí. Obecně budete chtít sezvat zástupce jednotlivých týmů, někoho z managementu, hlavního architekta, zástupce zákazníka/zákazníků a to včetně interních zákazníků v rámci firmy. Interním zákazníkem je každá skupina závislá na Vašem výstupu (takže třeba nezávislá skupina zajišťující formální testování). Cílem je zastoupit všechny skupiny jakkoliv zainteresované na výsledku projektu. Ti by pak měli na pre-planning meetingu společně vybrat oblasti, na kterých budou po následující sprint týmy pracovat.

Není úkolem přidělovat jednotlivé úlohy ani konkrétním lidem ani týmům, ale předvybrat pro každý tým příslušné high-level Story. Na konci každého Sprintu se v Burndownu vyhodnotí výsledky a nedokončené úlohy se vrátí zpět to produkt Backlogu. Před začátkem nového Sprintu se svolá další pre-planning meeting a znovu určí priority pro jednotlivé týmy.

Hlavním úkolem pre-planningu je umožnit komunikaci jednotlivých zájmových skupin (zákazník, management, architekt, …), koordinovat a pokud možno uspokojit jejich rozdílné zájmy a nastavit priority práce pro týmy.

Krátké vývojové cykly – Sprinty

Podíváte-li se na software development projekty, dost část se Vám stane, že nejsou dostatečně dobře časově odhadnuty. Samozřejmě částečně je to dáno špatnými odhady vývojářů. Často je ale hlavním problémem nejasná specifikace na začátku, která se v průběhu stále upravuje a designe a architektura se pak neustále předělává. V tom úplně nejhorším případě na konci máte něco úplně jiného, než se zpočátku myslelo.

V této sekci se zaměřím na to jak včas odhalit, že vám vůbec hrozí problém nedokončení v daném termínu. Začneme kvalitním produkt backlogem. Ten zdaleka nemusí být rozpracován do detailů, ale musí obsahovat všechny aktivity – Story – které musí být hotovy, aby byl se projekt mohl odevzdat. Např. pro implementaci nějaké funkcionality asi musíte udělat návrh, designe testu, implementaci, integraci, otestování a napsat dokumentaci. Tyto highlevel Story ohodnotíte body a v průběhu projektu detailněji rozpracujete.

Tým nechte pracovat v pravidelných cyklech – Sprintech. Na konci každého Sprintu jednoduše odečtete body za již hotové úlohy z celkového backlogu. Porovnáním hodnoty s plánem velice rychle vidíte, jestli je vše v pořádku či ne. Použijete-li pro vizualizaci burndown graf, automaticky víte, jak jste na tom a to pravidelně každý sprint. Úkolem sprintu je naučit tým naplánovat to co opravdu zvládne a odevzdávat pravidelně stále stejný objem práce a tak zvýšit důvěryhodnost odhadů a spolehlivost data dokončení.

Sprint by měl být krátký, obecně by asi neměl být delší než měsíc. Při zavádění Agile a sprintů se nebojte na začátku změnit délku sprintu, když se ukáže pro váš projekt nevhodná. Nám se nakonec osvědčily 14 denní sprinty. Začínali jsme s týdnem, ale to se ukázala být moc krátká doba. Dobrá pomůcka je že musíte být za sprint schopni ukončit běžnou úlohu. Ale úlohy se dají vcelku neomezeně dělit, takže jde spíš o to si to vyzkoušet přímo ve Vašem prostředí.

Ohodnocení úloh body

Jedním z těžko uchopitelných praktik Agilu je ohodnocení body. Ze zkušeností vím, že pochopení toho ‘co to vlastně ten bod je‘ a jak můžu ohodnotit úlohu něčím, co vlastně nemá pevnou jednotku, patří k nejsložitějším úkolům při zavádění Agile.

Ale vezměme to popořádku. Na začátku projektu máte seznam oblastí (Story) na kterých budete pracovat v Backlogu. Vezměte tým složený z project managerů, architektů a technical leaderů a udělejte odhady náročnosti tak, jak jste byli zvyklí. Pak převeďte odhady na body: 1bod=1man/day. A teď to přijde. V tom to momentě zapomeňte rozměr bodu a pracujte už jen a pouze s bodem. Jeho hodnota bude v začátku projektu, zvlášť bude-li to první Agile projekt, jistě měnit svou hodnotu, obvykle devalvovat. My jsme měli po cca dvou prvních měsících hodnotu bodu 0.6man/day. Nicméně od té doby se drží stabilní a to i na dalších projektech.

Co chcete docílit:
  • Zlepšit/zpřesnit odhady lidí v týmu
  • Zvýšit důvěryhodnost plánu vzhledem k managementu
  • Aktivně zapojit tým do plánování
  • Motivovat lidi na výsledku a včasném ukončení projektu
  • Zapojit tým do hry

Ohodnocení body je jen jeden střípek do mozaiky, sám o sobě toho moc nezmůže, ale je to dobrý začátek pro zkvalitnění odhadů náročnosti jednotlivých úloh. Jestli jste někdy zkoušeli nechat vývojáře odhadnout kdy práce bude hotová, jistě se Vám často stalo, že při odhadu zapomněli na část aktivit, např. testování, nebo Vás přesvědčovali, že práce odhadnout nejde, protože nikdo neví, co se může ještě objevit za problém.

Prvním krokem pro učení ohodnocení jednotlivých členů týmu je ohodnotit Story zkušeným týmem a pak nechat tým jen jednotlivé Story rozpadnout na menší úlohy ohodnocené body v rámci původního odhadu. Ohodnocení body zbaví jednotlivé vývojáře přímé vazby na čas, nicméně časem vytvoří bodu jakýsi ‘rozměr složitosti‘ který tým vstřebá a naučí se automaticky používat.

Každou další novou úlohu či Story nechte ohodnotit už přímo tým, který na ní bude pracovat. Tím tým zapojíte do hry a budete-li správně prezentovat výsledky (Burndown), zajistíte si tím správnou motivaci.

Produkt Backlog a ohodnocení úloh

Na začátku každého projektu je nutné nějak formálně popsat požadavky na systém. Co se má vlastně udělat a jak. Přepsat uživatelské požadavky do trochu techničtějšího popisu, takže mu budou vývojáři rozumět. Agile v tomto kontextu pracuje s pojmem Backlog.

Jak by měl takový backlog vypadat a do jakých detailů by měly úlohy zacházet? Řekněme, že to záleží na fázi projektu. Na začátku je nutné identifikovat high-level oblasti – Story, přidat odhad ohodnocení a základ backlogu je hotov. V průběhu projektu, jak budete vědět více, se Story budou postupně rozpadat na jednotlivé konkrétnější úlohy ohodnocené v rámci původního odhadu a backlog získá více detailů. Samozřejmě se může stát, že některé Story se budou muset přidat a některé se ukážou nadbytečnými.

Takto nadefinovaný backlog tedy pokrývá veškeré aktivity na projektu, spolu s ohodnocením je základním vstupem pro odhady celkové náročnosti. Zároveň je to prvním kamínkem do mozaiky Burndownu, ale o tom až později.

V této podobě (tabulka v Excelu) se nám vyplatilo sledovat jen relativně high-level úlohy. Pro popis detailů jednotlivých úloh či jejich stavu je vhodné použít některý z online trackovacích systémů – jako je třeba Mantis. Pro větší názornost a zpětnou kontrolu odpracovaných bodů jsme posléze přidali pravou část tabulky znázorňující, v kterém sprintu se pracovalo na které úloze.