Při práci na agilním projektu tým plánuje práci pro nadcházející sprinty vytvářením příběhů. Příběh definuje jednu funkcionalitu zapouzdřenou aktivitu s popisem a kritérii přijetí.
Sprinty obvykle trvají dva až čtyři týdny. Během této doby musí tým pochopit, kolik obsahu může vzít do jednoho sprintu, aby jej stále stihl v daném sprintu.
Na neagilním projektu byste práci odhadli obvykle na člověkodny. To znamená, kolik zaměstnanců na plný úvazek potřebujete k dokončení této činnosti? V takovém případě vždy při vytváření odhadů myslíte na dny a počet lidí.
Na agilním projektu jsou věci jinak. Pro výpočet konečného odhadu již nepočítáte dny ani lidi. Ve skutečnosti zakážeme i počítání úsilí v něčem jako mužské dny. Místo toho necháte tým převést na jednu obecně přijímanou hodnotu pro příběh, která bude představovat celkový odhad.
Nyní o tom, jaká přesně je hodnota, na tom opravdu nezáleží. Pravda, nejběžnějším zástupcem odhadů příběhu jsou Story Points. To jsou v podstatě Fibonacciho čísla začínající od 0, 1, 2, 3, 5, 8, 13, 21 atd. Další hodnota je součtem předchozích dvou čísel. To pomůže odlišit celkovou složitost příběhu, protože každé další vyšší číslo je výrazně vyšší než to předchozí.
Ale nemusíte se držet příběhových bodů. Může se jednat o odhady velikosti trička (XXS, XS, S, M, L, XL, XXL). Pokud byste chtěli být opravdu kreativní, můžete ZOO zvířátka představit a využít je pro odhad velikosti.
Ať tak či onak, nyní jde mnohem více o pocit celého týmu, které číslo (nebo zvíře) nejlépe reprezentuje celkovou složitost tohoto konkrétního příběhu. Rozhodně to není o reprezentaci času. Na konci by tým měl dokončit každý příběh, který byl v tomto sprintu přijat. Čas je tedy daný již na začátku a je konstantním číslem.
Table of Contents
Součásti odhadu bodů příběhu
Odhad pointy příběhu rozhodně není jen o tom, jak složitý/obtížný konkrétní příběh je. Při odhadu příběhu by měl tým zvážit několik aspektů a promítnout je do konečné hodnoty odhadu.
Konečným odhadem je pak hodnota, která představuje kombinaci všech aspektů zformovaných do jediného čísla. Zde je uvedeno, co takový odhad zahrnuje.
#1. Technická obtížnost
Za předpokladu, že odhadujeme příběhy pro vývojový tým, bude technická obtížnost příběhu jednou z prvních oblastí, na kterou se tým bude standardně soustředit.
A to je v každém případě správný přístup. Tým plný technických expertů by měl nejlépe vědět, jak takovou oblast příběhu zhodnotit. Zde může tým zvážit různé přístupy nebo rady, například:
- Jak je tento příběh ve srovnání s jinými již přednesenými z hlediska technické složitosti?
- Kolik souborů kódu bude muset tým vytvořit/aktualizovat, aby dokončil příběh?
- Kolik dalších změn kódu tento příběh vygeneruje pro okolní systémové procesy?
- Jak složitá bude implementace algoritmu nebo logiky procesu?
#2. Externí závislosti a rizika
Člověk by se divil, ale úspěšnost příběhů uvnitř týmového sprintu je častěji závislá na příspěvcích jiných týmů nebo osob mimo tým samotný.
Příběhy, kde vše, co tým zvládne sám, se nejsnáze odhadne. Věci se komplikují, pokud tým potřebuje externí pomoc pro své příběhy. Pro lidi mimo tým nebude tato činnost samozřejmě prioritou. Tým prostě musí s tímto faktorem počítat a zohlednit ho v rámci odhadu.
Jak moc tento faktor zvýší celkový odhad, bude záviset především na předchozích zkušenostech týmu a „úrovni externality“. V některých sprintech si tým obvykle vytvoří přirozený jednotný pocit, jak moc by tato závislost na vnějších lidech mohla zkomplikovat úspěšné dokončení příběhu.
#3. Faktor opětovné použitelnosti
Další oblastí, kterou je třeba zvážit, je, kolik ze stávajícího obsahu může tým znovu použít k dokončení příběhu. Je zřejmé, že pokud jsou některé části již nějakým způsobem přítomny, není nutné je stavět od začátku. Spíše může tým znovu použít již jednou vytvořené řešení k vytvoření nového mnohem rychleji.
Tímto způsobem může tato znalost snížit celkový odhad, i když normálně (bez této znovupoužitelnosti) by byl příběh na základě definovaného obsahu složitější.
#4. Pochopení vlastního týmu
Jedním pozoruhodným faktorem, který žádný odhad založený na člověko-dnech nemůže vzít v úvahu, je sebepoznání seniority a schopností týmu.
Jak tým spolupracuje a provádí několik sprintů, lidé uvnitř se navzájem poznají. Začnou chápat, kdo ví co a jak dobrý v tom je. A jakmile všichni zná zbytek týmu, mohou to společně jako tým zvážit při odhadu.
Pokud je příběh náročný na nějakou konkrétní technickou dovednost a tato dovednost je velmi silně přítomná uvnitř týmu, pak jasná realizace příběhu nebude tak obtížná. Nebo naopak, pokud chybí potřebné dovednosti v celém týmu, pak tým bude potřebovat podstatně více času, aby se do tématu dostal, a to promítne do odhadu.
Odhadování příběhu
Každý odhad příběhu by měl být týmovým úsilím. Žádný jednotlivý hlas by neměl předdefinovat složitost příběhu. Konečným cílem by mělo být nechat tým diskutovat o odhadu, dokud se všichni členové neshodnou na jedné jediné hodnotě, která bude představovat konečný odhad.
Tým může provést odhad přímo během diskuse o upřesnění sprintu (schůzka, kde se příběhy prodiskutují a vyjasní mezi týmem), nebo si na to může vyhradit vyhrazený čas.
Příklad procesu odhadu
Závazek plánu sprintu
Tým má nyní nevyřízené věci s příběhy, které již prošly odhadem. V ideálním případě je příběhům přiřazena (kromě konečné hodnoty odhadu) také priorita, aby tým věděl, které příběhy budou následovat v dalším sprintu.
Zde přichází plánovací sezení, kde si tým vybere některé příběhy pro další sprint. Rozhodnutí, které příběhy vybrat, by mělo být založeno na následujícím:
✅ Příběhy s nejvyššími prioritami, které tým považuje za první.
✅ Zkušenost týmu o tom, kolik příběhových bodů jsou schopni dokončit během sprintu. Tyto znalosti přicházejí pouze s časem a zkušenostmi týmu. K vyladění a správnému pochopení této schopnosti potřebujete několik sprintů.
✅ Neměli byste brát v úvahu pouze celkový počet bodů příběhu a prioritu. Dalším hlediskem je, jak se dovednosti uvnitř týmu rozloží ve vybraných příbězích. Pokud má tým například pouze dva front-endové vývojáře, nemusí si vybrat pouze příběhy obsahující pouze front-endový vývoj. To by vedlo k přetížení obou kluků, zatímco zbytek týmu už tolik ne. Znalosti týmu tedy jdou ruku v ruce s efektivitou tvorby obsahu sprintu.
Rychlostní faktor
Především stojí rychlost týmu (pro nadcházející sprint). Toto číslo nijak nesouvisí s celkovým počtem příběhových bodů. Udává však, jak moc bude tým k dispozici pro práci pro nadcházející sprint.
Abychom mohli přesně naplánovat obsah sprintu, spojili jsme oba aspekty dohromady:
Najít sladkou tečku chce čas a cvik.
Výhody a časté chyby
Je až s podivem, jak moc jsou týmy ochotné samy sobě zkomplikovat proces na cestě transformace na agilní tým. Doslova to vypadá, jako byste to potřebovali „získat“, než začnete pracovat v tomto režimu.
Tento první krok je bohužel také tím nejtěžším. V některých případech to trvá i roky, zvláště v přísně konzervativních korporátních prostředích, kde se jen čas zasekává v čase.
Každopádně toto se stane, jakmile to tým „dostane“:
- Už nemusíte počítat lidi nebo dny, abyste věděli, kdy lze něco dokončit.
- Tým se naučí vytvářet příběhy pouze tak složité, aby se vešly do sprintu. Pokud je příběh složitější, automaticky se rozdělí na více příběhů.
- Tým má dobré odhady pro každou práci, a jakmile ji naplánuje na sprint, přesně víte, kdy je splatná.
- Zvýší spolehlivost a předvídatelnost týmu.
- Všichni lidé v týmu budou „na stejné frekvenci“. Podívají se na příběh a pochopí podobné věci. Možná se po nějaké době ani nenamáhají odhadovat. Vidí číslo ve své hlavě, a protože všichni vidí stejné číslo, mohou se zavázat k příběhům ve sprintu i bez tohoto explicitního odhadu.
A to se obvykle stane, pokud tým stále není schopen pochopit proces nebo způsob práce:
- Nějak se stále drží starých módních odhadů. Vše převádějí na dny nebo zúčastněné osoby. Body příběhu nebo Fibonacciho čísla znamenají počet dní, ať už přímo nebo nepřímo, prostřednictvím různých transformací.
- Vedení porovnává týmy na základě počtu příběhových bodů dodaných v každém sprintu. To je tak špatné, jak jen to může být. Pak není pochopena podstatná skutečnost: Každý tým odhaduje body příběhu jinak. Není absolutně žádný důvod snažit se synchronizovat dva týmy, aby odhadovaly jejich příběhy „stejným způsobem“.
- Zatímco příběh jednoho týmu znamená nakreslení kruhu, pro jiný tým to může znamenat nakreslení domu s plochou střechou, čtyřmi okny a dvěma dveřmi. A je to úplně v pohodě.
- Někdy mají týmy tendenci odhadovat téměř vše mezi dvěma až čtyřmi různými čísly. Možná protože se bojí, že příběh má číslo 123, někdo si bude myslet, že to má něco společného s počtem dní. Faktem ale je, že Fibonacciho stupnice má nekonečné množství čísel. Nemusíme se omezovat jen na odhady 3, 5 nebo 8. Určitě můžeme (a možná už příběhy vytváříme s tím účelem, aby byly tak složité, v tom případě je to v pořádku), ale rozhodně netřeba.
- Odhad je řízen seniory, kteří předdefinují očekávání celé skupiny. Nikdy bychom neměli dovolit ovlivňování odhadu jedním členem týmu. Každý má stejné právo vyjádřit svůj názor a být vyslechnut.
Závěrečná slova
Přechod na agilní odhady z tradičnějších přístupů není vždy snadný a vyžaduje přizpůsobení – jak pro týmy, tak i pro vedení výše. Aby to fungovalo, musí obě strany pochopit proces. Pokud jeden z nich nerozumí, přechodné období je obtížná cesta plná protichůdných očekávání.
Ale jakmile se vše změní, začnou se dít nějaké magické věci. Týmy budou moci lépe odhadovat a plánovat svou práci a vedení bude mít předvídatelnější verze a plány, na které se bude moci spolehnout.
Dále se podívejte na nezdravé procesy, které mohou zničit váš sprint.