Jak zabít Scrum

Najdete spousty článků jak být agilní, jak Scrum úspěšně nasadit… ale ve spoustě firem řeší naprosto opačný problém. Jak zabít Scrum. Dělám si trochu legraci, ale občas to tak vypadá.

Takže jak na to. A přidejte se s nápady a komentáři. Co dělat, aby to spolehlivě zabilo Scrum. Co napadne každého, je postavit silného šéfa co rozděluje práci a alokace a o všem musí rozhodnout. Najdete spoustu takových nápadů. Ty jsou zřejmé a jsou moc vidět navenek. Bijí do očí. Dá se proti nim bránit. Mám vypozorovnu lepší metodu jak nasadit Scrum bez toho, aniž bychom se museli bát, že se osvědčí. Je to snadné. Naučíte se pár pojmů. Scrum = to je náš nový proces, nebojte se, nic moc se tím nezmění. Sprint = to je jakési období, za které máme něco dokončit. Když to nestihneme, prodloužíme Sprint třeba na třičtvrtě roku. To by bylo, abychom to nestihli. Máme přeci komplexní produkt. Backlog = requirementy a usecasy. To máme, nemusíme tedy nic měnit. Business na nás stejně nemá čas. Nezajímá ho to. Tak se o Backlog stará armáda Business Analytiků. Mají toho moc, ale nakonec to rozmyslí dobře. Body = Divný. Mandays nám vyhovují, jsme na ně zvyklí, tak proč přeházet na body. Standup = to je taková pěkná praktika. Pojďme se každý den sejít a popovídat si. To se ve Scrumu dělá ne? Lidi alokujeme na plno projektů najednou, tak ať se jednou denně vidí. To bude stačit. Tým = skupina specialistů, co věří, že ostatní by v žádném případě nezvládli to, na čem oni pracují. Jsou přeci specialité – na danou oblast, nebo technologii, nebo oboje. Tak co bysme jako sdíleli a jak bysme si pomáhali, že..

Povědomé? Na zabití Scrumu stačí spolehlivě dvě věci. Začít používat názvy bez porozumění a obsahu. A podpořit to zdlouhavým pravidelným Stand-up meetingem bez závazku a bez týmové spolupráce. A věřte či ne, za pár týdnů ani největší optimista neuvěří že Scrum je pro vaši firmu vhodnou metodou.

Agile Riga Day

Rok se s rokem sešel, a tak jsem se zase objevila na Agile Riga Day, příjemné jednodenní konferenci v Lotyšsku. Letos se organizátorům podařilo zdvojnásobit počet účastníků, a rozrostli se na tři tracky. K tomu jsem ještě měla jednodenní workshop, “Starting Scrum“, takový den plný her, simulací a diskuzí. Bylo zajímavé, že slečny převládaly, ostatně i na konferenci den poté jich bylo výrazně více, než bývá v Evropě zvykem. Ale přeci jen méně než na Agile India. Překvapilo mě i to, jak rádi si analytici, kterých jsem na workshopy několik měla, hráli. U nás mám s analytiky spíše opačnou zkušenost.

Riga a vlastně i Lotyšsko má jedno další specifikum. Je hodně navázané na Skandinávii, takže mám pocit, že jsem byla jedním z mála lidí co nebyli z pobaltsko-skandinávské oblasti. Převládali Švédové, Norové, Estonci. O čem se hovořilo? O tom jak psát dobrý kód, jak dělat refactoring, jak naložit se starým legacy kódem, jestli dělat test driven development, nebo pair programming… výborný workshop na toto téma vedl Johannes Brodwall – Extreme Startup. Moc se mi to líbilo. Už dlouho jsem neviděla na konferenci pair programming v praxi. Bylo zajímavé to sledovat.

Hodně se diskutovaly odhady. Vlastně, začali jsme s tím tématem už den před konferencí v místním baru. K pochopení základního problému s odhady je nutné si uvědomit rozpor mez i tím, co odhady jsou – tedy nepřesná predikce budoucnosti – nijak exaktně přesná být z principu věci ani nemůže, od toho je to odhad. A jistá představa managerů některých firem, že odhad musí být naprosto přesný. A když k tomu dodáme nepříjemný pocit členů některých týmů, že jsou tlačeni do něčeho, co není možné dodat – tedy do stoprocentně přesného odhadu, máme tu problém, který se dá dlouho do noci vášnivě diskutovat. Obzvláště když jeden z diskutujících má ráno na dané téma keynote kde v podstatě říká, že odhady v bodech jsou stejně tak špatné, a nepřesné, že zrovna tak můžeme každý Sprint jen počítat dokončené a nedokončené User Story a odhady nedělat vůbec. Příště o tom třeba napíšu víc.

Dalším tématem, které mě zaujalo, byla myšlenka, že na to, abyste změnili svět, třeba na agilní, je třeba si uvědomit že “nemusíte systém řídit, stačí s ním umět tančit“. Možná že to je jedna z věcí, které musí umět každý Scrum Master, a asi nejen on. Nestačí vědět, jak okolní svět funguje, musíte vyvinout něco, co se bude chovat jako virus. A takový virus potom do okolního, neagilního, světa pustit.

Abych to shrnula, myslím, že všechny praktické sessions pro programátory a testery se osvědčili, a že mám zase pár dalších kontaktů a nápadů na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Několik důvodů proč rozdělit User Story

Důvodů proč rozdělit UserStory může být hned několik.
Ten nejčastější je, že je moc velká a nevejde se do Sprintu. A protože základem Scrum procesu je pravidlo že tým vybere co během Sprintu dokončí a to na konci prezentuje zákazníkovi na customer demu, takovým UserStory které by dokončit nešly se musíme vyvarovat. Jak UserStory dělit? Po menších funkcionalitách. Nikdo neříká že takto rozdělěnou UserStory si zákazník musí nutně chtít koupit, ale jen že mu musí přinášet hodnotu. A ta je třeba i v tom, že si představí, co vlastně od dané funkčnosti chce. Tedy např. pakliže chce fakturace, asi si nekoupí jen readonly seznam faktur, ale bude je chtít i vytvářet a tisknout a filtrovat… ale jako mezivýsledek po prvním Sprintu mu hodnotu přinese i jen obyčejný seznam.

Druhým důvodem je různá priorita jednotlivých funkčních celků. Ono je to jedno spojeno s druhým. Když je UserStory moc velká, tak se obvykle Product Owner ptá, co jí dělá tak náročnou a komplexní. A přijde se obvykle na to, že udělat seznam faktur je snadné, ale tým ještě nikdy nedělal print preview a daná komponenta ho neumí a tedy je to pro ně náročné. Ono ale obvykle ne všechno je nutné a ne všechno stojí za tu cenu, kterou to má. A může se stát, že možnost print preview pro zákazníka vlastně nemá takovou priorotu a že ji odloží, na čas, či úplně.

Scrum vám umožňuje funkcionalitu řídit. Tím že složité celky musíte rozpadnout na menší kusy aby je tým stihnul v rámci Sprintu vás nutí přemýšlet o tom, jestli opravdu všechny drobné funkcionality potřebujete a jestli estimate odpovídá ceně, kterou jsme ochotni za očekávanou business value dané funkcionality v UserStory zaplatit.

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.

Jak nejlépe sledovat aktuální stav úloh

V minulém příspěvku jsem doporučovala Excel pro vizualizaci výsledků Sprintu a zobrazení Burndown grafu, jako jednoduchou, levnou a efektivní metodu. Podobně se můžeme postavit k trackování statusu jednotlivých úloh, plánování na sprinty a sledování úloh v backlogu. Systémy navržené na Scrum proces Vám samozřejmě dají všechny informace o aktuálním stavu, plánu, atd. nicméně často je to velmi komplexní řešení, jehož filozofii musíte přizpůsobit svůj Scrum proces, alespoň do jisté míry. Každý produkt má své pro a proti, těžko vybrat ideální.

Mantis - úvodní stránka

Jedním z možných řešení, které je zdarma, a je poněkud lepší než uchovávat backlog úloh a jejich status v Microsoft Excelu, je Mantis (bug tracking system). Originálně je to systém na trackování chyb, ale poměrně jednoduše jde použít na sledování statusu jednotlivých úloh, přiřazení úloh konkrétním lidem, plán. Mantis umožňuje posílat automatické notifikace emailem, nastavit různá práva, automaticky zobrazuje historii změn. Vzhledem k velmi dobrému filtrování si každý může přednastavit takové zobrazení, které vyhovuje jeho roli (vlastní úlohy, naplánované úlohy, backlog pro danou story, …).

Mantis - detail úlohy

Co je třeba udělat navíc. Pomocí Custom Fields si velice jednoduše přidáte nové položky – pro Scrum proces to bude Points (Body). V ideálním případě, bude-li se Vám chtít, jde pod seznam úloh přidat součet bodů, to už je ale nutné naprogramovat přímo ve zdrojovém kódu. Nic složitého. Nicméně i bez toho je funkcionalita dostatečná. Pro každý projekt dáte do seznamu kategorií (Categories) Sprinty. Mantis neobsahuje ve své originální podobě datum, tedy délku Sprintu si určujete sami. Asi by nebyl problém to doprogramovat, ale nám to vlastně nikdy moc nechybělo. Stavy jednotlivých úloh je zase ve zdrojáku velice snadno možné přejmenovat, aby více odpovídaly vašim zvyklostem. A můžete začít. Naplníte backlog úlohami, tým naplánuje Sprint, přiřadí úlohy jednotlivým lidem, a pak už jen každý den sledujete co se děje.

Mantis - celkový přehled úloh

Bohužel, verze Mantisu se hodně liší, takže výše popisované změny ve zdrojovém kódu nejsou jednoduše popsatelné tak, aby se daly rovnou použít. My máme skoro na každý projekt jinou verzi Mantisu a změny děláme projektu vždy znovu na míru. A není to nijak zvlášť časově náročná aktivita.

Co se týče spojení s Burndown grafem, každý konec sprintu se udělá rychlá synchronizace. Přepíšeme, kolik bodů se z které úlohy dokončilo, které úlohy vznikly, a graf je hotový. Je to jistá část manuální práce, ale zabere pár minut. Komplexní Scrum systém to udělá za vás, ale zase třeba nebude tak jednoduchý a obecný.

Burndown graf template

Jak na Burndown? Možností je několik. Můžete začít provozovat jeden z mnoha systémů na Scrum proces a Burndown graf se vám bude zobrazovat víceméně sám od sebe, v jedné z mnoha podob. Systémy jsou komplexní, většinou placené a ne vždy plně odpovídají Scrum procesu tak, jak by se vám hodil. Flexibilita je relativně nízká, obvykle se musíte přizpůsobit vy. Za ty nejznámější vybírám ScrumWorks, ScrumDesk, Rally, Version One. Detailně se jim budu věnovat příště.

Druhou možností je, že si napíšete vlastní Burndown v Microsoft Excelu.

Já osobně tuto možnost preferuji. Za prvé, je to transparentní, přesně víte, co zobrazujete a jak, máte to pod kontrolou. Přikládám pro inspiraci svůj XLS Burndown template. Nic složitého. První sheet obsahuje kopii produkt backlogu s vyhodnocením bodů přes jednotlivé sprinty. Druhý sheet obsahuje výpočty pro grafy. Každý sprint se do něj přenesou dvě hodnoty z sheetu Backlog – Points Remaining a Velocity (Actual Points Complete). Zbytek se počítá sám. Na začátek projektu ještě musíte naplánovat rychlost týmu a buffer do kolonek – Planned Velocity a Planned New Points (Buffer). Další dvě záložky už zobrazují grafy: Project Velocity Plan a Burndown.

Burndown graf

Burndown graf je výborným pomocníkem při vizualizaci výsledků. Na internetu najdete spoustu odkazů jak takový burndown může vypadat, spousta aplikací pro Scrum proces vám je budou přímo generovat. Nicméně obyčejný Microsoft Excel vám udělá stejně dobrou a možná i lepší službu. Výhodou je že se data zpracujete a zobrazíte sami, tedy máte výstup plně pod kontrolou. V tom úplně nejjednodušším případě kdy máte backlog definovaný v Excelu spolu s výsledky jednotlivých Sprintů (třeba takto) je již vcelku snadné data zobrazit.

Důležité jsou v podstatě dva grafy. Jedním je tzv. Velocity plan, tedy plán jak rychle bude tým postupovat. Obvykle vezmete v úvahu, že na začátku se tým učí a pak už pracuje konstantní rychlostí. Je dobré zahrnout do plánu i masivní dovolené (např. Vánoce) a plán tomu pro daný Sprint uzpůsobit.

velocity plan

Druhým grafem je Projekt Burndown graf, který kombinuje aktuální stav s odhady a vizualizuje předpokládaný konec projektu.

Vytiskněte každý sprint tyto dva grafy a vystavte je na veřejné místo, ať všichni na první pohled vidí jak se projektu a týmům daří.

Podívejte se na příklad toho, jak by takový burndown mohl vypadat.