backlog | Zuzi's Blog o Agilu a Scrumu

Proč píšeme User Story?

Proč v agilních a Scrum týmech píšeme User Story a proč nestačí jen tasky s popisem co se má udělat? K čemu je, že se držíme formátu „Jako Uživatel, chci Funkcionalitu abych dostal Business Value“? Není to zbytečné pořád dokola opakovat slovíčka ‘Jako’, ‘chci’ a ‘abych’? Může se to tak zdát. Pojďme se na to ale podívat od začátku.

User Story vám říká nejen, co chcete dělat, ale i pro koho a hlavně proč. User Story má vytvářet obrázek, popisuje příběh. Lidský mozek vnímá obrázky a příběhy daleko snadněji než technický popis v bodech. Zkuste si teď porovnat jeden příklad z praxe:

1. US: „Kontaktní formulář“ (jaký jste si představili?)
2. US: „Jako administrátor chci kontaktní formulář, abych se včas dozvěděl o chybách systému“.

Jsem si téměř jistá, že když jste to četli, šlo o dvě různé věci. Myslíte si, že je to z kontextu firmy a produktu jasné? Ne vždy. Většinou je to jasné pouze Product Ownerům, ti mají v hlavách obrázky, jak přesně se má systém chovat a jak má vypadat. Ti jsou součástí příběhu zákazníka, ale v User Stories jde o to, aby ten obrázek, co mají v hlavě, sdělili ostatním tak, aby ho ani oni nikdy nezapomněli. A aby se i oni stali jeho součástí.

User Story by měla být jednoznačně popsatelná, vytvářet obrázek, nezávislá, přinášet hodnotu, a také malá. Je-li User Story příliš velká je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. A jak se pozná, že je User Story hotová? Od toho jsou tu akceptační kritéria.

User Story můžete samozřejmě dělit na menší User Story, pořád ale musí přinášet nějakou hodnotu. Nejsou to technologické aspekty problému. Díváme se na ní z pohledu businessu, z pohledu uživatelů. Techlologie přichází na řadu až při rozpadu User Stories na jednotlivé tásky.

A na závěr tu mám pár příkladů pro elektronickou půjčovnu domácích zvířat:

Jako rodič si chci půjčit zvíře aby moje děti věděli, jaké to je se o nějaké zvíře starat, než si ho koupíme.

Jako rodič si chci přečíst maximum informací o bezpečnosti a vhodnosti jednotlivých zvířat abych si mohl vybrat vhodné zvíře pro své dítě.

Jako příbuzný chci mít možnost koupit upomínkový předmět s fotkou půjčeného zvířete, abych měl pro děti dárek.

Jako dítě si chci vybrat z obrázků, které zvíře si půjčíme, aby se mi líbilo.

Jako dítě chci mít přístup k deníku svého zvířere, abych věděl co se s ním stalo když jsme ho vrátili.
A tak dál…

Jednotlivé User Stories mají různou hodnotu, různou náročnost. Ne všechny jsou kritické pro produkt, ne všechny se vyplatí implementovat. Ale o tom zase příště. Děkuji Daniele a Vojtovi za příklad 🙂

Proč firmy přechází na agilní metody a Scrum?

Co vede v současnosti firmy k zavádění agilních metod? Já jsem si vždycky myslela, že to bude efektivita, týmová spolupráce a větší zastupitelnost, že firmy nebudou se svým současným procesem spokojeni… Možná. Ale za poslední rok jsem narazila spíše na firmy, které říkaly, že jejich současné procesy jsou dobré, lidi práce baví, výsledek je kvalitní a efektivní jsou dost, i zákazník je s výsledkem spokojený.

Ptáte se, kde je tedy problém? Také mě to zajímalo a tak jsem se zeptala. A zjistila, že doposud jim jejich striktní těžké procesy vyhovovaly, ale teď se svět změnil. Všechno je rychlejší, dynamičtější, každý očekává všechno hned. Nikdo nechce čekat rok, rok a půl, než dostane funkcionalitu, kterou potřebuje. Ostatně podívejte se, jaký jsme měli před rokem mobilní telefon a jaký máte dneska. Můj super nový iPhone4 už je skoro zastaralý a to ho nemám ani půl roku. Trh zrychlil. A tak nemáte komfort toho vše si do detailu rozmyslet, předat, zaprotokolovat, udělat analýzu, popsat UML diagramy, rozmyslet třídy, rozkreslit chování, popsat GUI, nakódovat, otestovat, opravit, předat, upravit aby se to dalo používat, opravit … a mít čas si v klidu užít dobrý pocit ze skvěle odvedené práce.

Firmy se v podstatě dělí na dvě skupiny, jedna chce agilní metody protože jejich zákazníci chtějí funkcionalitu hned, ikdyž po menších kouscích, tak googlují a najdou Scrum. Druzí mají strach, že jejich konkurence bude po krizi, kdy nikdo moc do vývoje neinvestoval, rychlejší a tak zase googlují a najdou Scrum. Někeří jsou tak daleko, že Scrum s plánem releasu je moc svazuje a přijdou na to, že chtějí radši Kanban a že funkcionalitu nepotřebují plánovat dopředu ani na úrovni backlogu. Ale to už je jiná story.

Není to pěkné vidět konzervativní velké korporace z bankovního světa, pojišťovny, telekomunikační operátory, velké mezinárodní společnosti jak najednou říkají my chceme přejít na agilní metody? Na druhou stranu, tyto velké korporáty jsou většinou v přechodu na agilní metody a Scrum proces úspěšnější než malé firmičky. Nevzdají se tak snadno. Není to jejich první změna. A vědí, že žádná změna není snadná, a žádná změna není zadarmo. Že je bude stát spoustu úsilí firmu změnit.

Mám je ráda, je s nimi legrace, nutí mě to přemýšlet, ale hlavně, na konci je odměna ve formě fungujícího agilního týmu. Což je zdaleka nejlepší motivace, kterou agilní kouč může dostat.

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.

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.

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.

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í.

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

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.