Bezručova 9, 680 01 Boskovice +420 608 464 341

Plánování řízené kapacitou

Vytvořeno 28.04.20 od Administrator

Jaké role potřebujeme v rámci schůzky

Plánování iterace řízené kapacitou se účastní Product Owner (vlastník produktu) a všichni členové vývojového týmu. Scrum Master nebo Agilní Kouč jsou přítomni především z důvodu moderování diskuze, pokud přítomní lidé nemají kompetenci moderování v rámci své maturity. Product Owner schůzku organizuje a má pro ni připraven produktový backlog (seznam nevyřízených položek) setřízený od nejvyšší priority a domlouvá se s týmem, které položky produktového backlogu se zaplánují do následující iterace (Sprintu).

Výběr položek z produktového backlogu

Členové týmu si z produktového backlogu přenesou první položku do backlogu následující iterace (ve Scrum jde o Sprintový backlog). Tým si vybírá od nejdůležitější položky, pokud se nenarazí na to, že tato položka má příliš mnoho nejasností, či závislosti, které je potřeba vyřešit. V ideálním případě by však i tyto překážky neměly bránit položku zaplánovat, pokud je možno tyto záležitosti vyřešit v rámci iterace a dokončit ji včas. Pokud jsou tyto překážky natolik zásadní, nebo že by jejich řešení bylo příliš zdlouhavé, tak je možno takovou položku při plánování přeskočit a nejdříve tyto překážky odstranit, než ji znovu zařadíme do některého z následujících plánování.

Tuto aktivitu děláme s každou další položkou v pořadí, tak jak jsou setřízené v produktovém backlogu, dokud tým neřekne, že je plán pro další iteraci naplněn a více položek již není vhodné přidat.

Umět se rozhodnout je klíčové

Poté, co se členové týmu pobavili o položce, kterou chce Product Owner přidat do vývojové iterace a v kostce identifikovali, co vše bude potřeba udělat, by se měli rozhodnout, zda požadovanou položku můžeme přidat do iterace, či nikoliv. Tým si položí otázku: "Je skutečně reálné položku v souvislosti s ostatními již zaplánovanými aktivitami položku dodělat včas v rámci iterace?"

Pokud si tým tuto otázku neklade, měl by moderátor položit otázku: "Skutečně je reálné tuto položku dokončit včas?" Tým by měl být schopen udělat rozhodnutí, že je vysoce pravděpodobné, že to s aktuálními informacemi je reálné. Tento odhad nedělá realizační tým pro moderátora, ale především pro sebe. Tým by měl tato rozhodnutí brát velmi zodpovědně a považovat ho za jistý druh závazku především vůči sobě a své důvěryhodnosti vůči zákazníkovi.

Pozor nejedná se o závazek vůči managementu, který často považuje plán vývojové iterace za závazek vytesaný do kamene. Samozřejmě, že je nutné, aby v případě, že již plán nejsme schopni splnit, aby tento fakt byl včas a srozumitelně komunikovaný všem zainteresovaným stranám. Zde je potřeba, aby Scrum Master nebo Agilní Kouč zajistili, že management velmi dobře rozumí, jakým způsobem se plánuje a co pro tým takový plán znamená!

Scrum Master, či Agilní Kouč nejsou "šéfové" týmu, přestože by to tak mohlo být vnímáno, protože je přece "Master". A proto by se lidé v této roli neměli nechat natlačit do pozice, který tlačí na tým, že se zavázal v rámci plánování vše dokončit bez ohledu na to, aby byly zohledněny všechny souvislosti, které měly na dodržení plánu vliv.

Pokud se moderátor na konci plánování zeptá: "Je reálné, že naplánované položky do vývojové iterace jsme schopni doručit?" Mělo by se z týmu jednohlasně ozvat: "Ano, je to reálné!" Pokud má kdokoliv pochybnosti, měl by být vyslechnut a tým by měl rozhodnout, zda jeho pochybnosti zásadním způsobem ovlivňují plán, či nikoliv. Tímto způsobem bychom měli vytvářet silnější závazek věci dokončit a nebrali plánování jako formalitu.

Dejme si pozor, pokud místo "my můžeme" budeme slyšet "já můžu". Je pravděpodobné, že tento člověk nezohledňuje, zda je možné plán naplnit jako celek, ale přemýšlí jen nad svými úkoly, které jej čekají v následující iteraci. Vyplývá z toho, že je nutné se soustředit na to, že členové týmu chtějí naplánované věci skutečně dokončit v rámci následující iterace, tj. vytváří si každý jednotlivec závazek, že chce, aby tým byl na konci iterace úspěšný. Nejde o postoj, "toto jsou moje úkoly" a "toto jsou vaše úkoly", ale o "toto jsou naše úkoly".

Jak zohlednit odhady velikosti jednotlivých položek (např. Story Pointy)

Všimli jste si, že jsem se dosud nezmínil o tom, jak souvisí v rámci tohoto typu plánování odhady, či rychlost týmu (velocita)? I když jsem o odhadech velikosti jednotlivých plánovaných položek nemluvil, tak velmi doporučuji, abyste znali velikost plánovaných položek, kterou si můžete vyjadřovat např. pomocí Story Pointů, přestože při kapacitním plánování nemají příliš velký vliv na množství naplánované práce. Čeho se vyvarujte, tak počítání kapacity kompetencí jednolivých rolí. Nevytvářejte jednotlivé kapacity na vývoj, test, analýzu, dokumentaci apod. Tento přístup s největší pravděpodobností bude vytvářet pocit, že je nutné naplnit kapacity těchto kompetencí, místo toho, abychom se zamýšleli, jak vytvářet optimální vytížení týmu, které je nutné k doručení hodnoty pro zákazníka. Za tuto činnost je plně zodpovědný vývojový tým a měli bychom tuto schopnost v týmu naopak budovat, pokud ji neumí.

Závěrečné ověření plánu

Jakmile máme naplánováno je možné plán ověřit vůči průměru velikosti položek doručených na konci iterace. Moderátor sečte hodnoty jednotlivých položek a porovná je vůči průměrnému množství a tyto hodnoty v týmu nasdílí.

Za předpokladu, že tým má průběrné množství odbavených položek na úrovni 20 bodů a nyní naplánoval položky za 19 bodů aniž by znal tým svou průměrnou rychlost. Můžeme předpokládat, že tento plán bude reálný a není potřeba to více rozebírat. Pokud by týmu moderátor sdělil, že má rychlost 19 bodů, je vysoce pravděpodobné, že tým naplánuje jen do výše 19 bodů, protože se tak bude cítit pohodlně.

Co dělat, když tým naplánuje 11 bodů, což je výrazně méně než je jeho průměrná rychlost? Je potřeba se doptat na to, co tým bude brzdit v další iteraci, abychom ověřili, že plán je skutečně v pořádku. Je docela možné, že tým bude vytížený aktivitami, které si vezmou část kapacity plánované iterace. Důvodem může být očekávané vytížení týmu náročným zveřejněním novového produktu na trh.

Podobně by měl moderátor reagovat v případě, že jsme zaplánovali 35 bodů. Opravdu jsme na něco nezapomněli nebo tým má příliš velké oči. Na druhou stranu je možné, že do realizačního týmu jsme nabrali skvělého člověka, který tímto způsobem ovlivňuje množství doručené hodnoty pro zákazníka.

Z toho všeho nám vyplývá, že v průběhu kapacitního plánování nehraje rychlost týmu a velikost položek významnou roli. Avšak do závěrečného ověření, zda je plán v pořádku, bychom měli jak rychlost, tak celkovou velikost naplánovaných položek zahrnout.

Plán není záruka

Plány jsou od toho, aby se měnili. Je nutné reagovat včas na změnu a tím i tuto změnu reflektovat do nášeho plánu a přizpůsobovat ho nově vzniklým situacím. Pokud někdo chce záruku, ať si koupí toustovač!

Tým se svým plánem zavazuje, že udělá to nejlepší, co umí a čas, který má na realizaci zaplánovaných věci, využije maximálně efektivně. Pokud začneme závazek týmu prezentovat jako záruku, budeme tímto přístupem nastavovat postoj odmítnutí k jakémukoliv závazku, protože se nejedná o závazek manažerovi, ale o vnitřní závazek jednotlivce vůči týmu.

Pokud chceme, aby tým byl maximálně úspěšný v rámci svého plánu, je potřeba, po celou dobu tým podporovat a pomáhat mu odstraňovat překážky, které ho budou zpomalovat.


Nové příspěvky blogu

Definition of Done aneb tým má hotovo
Definition of Done aneb tým má hotovo

17.08.20 od Administrator

Máme už hotovo? Na tuto otázku je těžké...

Scrum Master je nejlepší sekretářka na světě

28.05.20 od Administrator

Často narážím na to, že role Scrum Mastera...

Plánování řízené rychlostí týmu

12.05.20 od Administrator

Co je rychlost týmu? Je to průměrné...

Zobrazit všechny příspěvky blogu →