Odhadování práce v agilním prostředí: Story Points a další
V agilních projektech se plánování práce na nadcházející sprinty provádí prostřednictvím takzvaných „příběhů“ (user stories). Každý příběh představuje specifickou funkcionalitu, která je popsána a má definovaná kritéria akceptace.
Sprinty obvykle trvají dva až čtyři týdny. Během této doby musí tým zhodnotit svou kapacitu a stanovit, kolik práce je reálně schopen dokončit v daném časovém úseku.
V neagilních projektech se odhady práce často vyjadřují v „člověkodnech“, tedy počtu dní potřebných k dokončení úkolu s ohledem na počet zapojených pracovníků. Při takovém odhadování se primárně zaměřujete na čas a počet lidí.
V agilním prostředí se však používá jiný přístup. Pro stanovení odhadu se již nepracuje s dny ani počtem osob. Dokonce se doporučuje vyhnout se i odhadování úsilí pomocí „člověkodnů“. Místo toho tým pracuje s obecně uznávanou hodnotou, která reprezentuje celkovou náročnost příběhu.
Konkrétní volba této hodnoty není zásadní. Nejobvyklejším způsobem odhadování příběhů jsou „Story Points“. Ty se obvykle vyjadřují pomocí Fibonacciho posloupnosti, začínající 0, 1, 2, 3, 5, 8, 13, 21 atd., kde každé následující číslo je součtem dvou předchozích. Tento systém pomáhá rozlišit celkovou složitost příběhu, protože každé vyšší číslo značí výrazně větší obtížnost.
Nemusíte se však omezovat pouze na Story Points. Lze použít i odhady velikosti trička (XXS, XS, S, M, L, XL, XXL) nebo dokonce zvířecí symboly z ZOO, pokud si to tým přeje.
Důležité je, aby se celý tým shodl na hodnotě, která nejlépe reprezentuje celkovou komplexnost daného příběhu. Nejde o odhad času, ale o relativní náročnost. Cílem je, aby tým byl schopen dokončit všechny příběhy přijaté do sprintu v daném časovém rámci.
Faktory ovlivňující odhad Story Points
Odhad Story Points není jen o složitosti příběhu. Tým by měl zvážit několik aspektů, které se promítnou do konečného odhadu.
Výsledný odhad pak představuje kombinaci všech těchto faktorů, vyjádřenou jedinou hodnotou. Podívejme se, co vše by měl odhad zahrnovat:
1. Technická obtížnost
Technická náročnost příběhu je obvykle prvním aspektem, na který se vývojový tým zaměří. Tým technických odborníků má nejlepší předpoklady pro hodnocení této oblasti. Může zvážit následující:
- Jak je tento příběh technicky náročný ve srovnání s jinými již zpracovanými?
- Kolik souborů kódu bude nutné vytvořit nebo aktualizovat?
- Jaké další změny kódu vyvolá tento příběh v okolních procesech systému?
- Jak složitá bude implementace algoritmu nebo logiky?
2. Externí závislosti a rizika
Úspěšnost dokončení příběhu může záviset i na spolupráci s jinými týmy nebo jednotlivci mimo tým. Příběhy, které si tým může odpracovat samostatně, se odhadují snadněji. Problémy nastávají, když je potřeba externí pomoc. Pro externí subjekty nemusí být vaše požadavky prioritou, což je potřeba zohlednit v odhadu.
Dopad tohoto faktoru na celkový odhad závisí na zkušenostech týmu a stupni „externality“. Tým si obvykle časem vytvoří intuici, jak moc mohou externí závislosti zkomplikovat dokončení příběhu.
3. Faktor opětovného použití
Tým by měl také posoudit, kolik existujícího kódu nebo řešení lze znovu použít. Pokud jsou některé části již k dispozici, není nutné je programovat od začátku. Opětovné využití existujícího kódu může výrazně urychlit práci a snížit odhadovanou náročnost.
Znalost o možnosti opětovného použití může snížit celkový odhad, i když by jinak byl příběh na základě svého rozsahu složitější.
4. Znalost schopností vlastního týmu
Na rozdíl od odhadů v „člověkodnech“, agilní odhady zohledňují i znalosti a schopnosti členů týmu. Jak tým pracuje společně, členové se poznávají a uvědomují si, kdo v čem vyniká. Tuto znalost je možné zohlednit při odhadu.
Pokud příběh vyžaduje specifickou technickou dovednost, kterou tým má, jeho realizace nebude tak obtížná. Naopak, pokud potřebné dovednosti chybí, tým bude potřebovat více času na nastudování a to by se mělo promítnout do vyššího odhadu.
Samotný proces odhadování
Odhadování příběhu by mělo být týmovou aktivitou. Neměl by existovat jediný hlas, který by určoval složitost příběhu. Tým by měl diskutovat o odhadu, dokud se všichni členové neshodnou na jedné hodnotě.
Odhad se může provádět během diskuse o upřesnění sprintu nebo si na něj může tým vyhradit samostatný čas.
Příklad procesu odhadování
- Vyberte nástroj pro odhadování (např. Planning Poker, Miro board).
- Prezentujte příběh. Nechte tým diskutovat o detailech. Ujistěte se, že všichni rozumí příběhu.
- Spusťte odhad. Každý člen týmu vybere číslo z Fibonacciho stupnice.
- Projděte si výsledky a diskutujte. Často se týmy rozdělí mezi dvě až tři čísla. Nechte členy týmu, kteří vybrali nižší hodnoty, vysvětlit svůj názor. Potom nechte vyjádřit i ty, kteří volili vyšší čísla. Cílem je sjednotit chápání příběhu celým týmem.
- Po diskuzi nechte tým znovu odhadnout. Většinou se nyní týmy sjednotí na jednom, maximálně dvou číslech. Znovu diskutujte. Většinou se tým dohodne na finálním čísle, případně se může opakovat další kolo odhadování.
- Odhad je hotov, až když všichni členové týmu souhlasí s finálním odhadem. Jedná se o týmovou dohodu. Každý příběh může být přidělen komukoli v týmu, proto je důležité, aby všichni chápali jeho náročnost.
Závazek plánu sprintu
Tým má nyní odhady příběhů. V ideálním případě mají příběhy kromě odhadu i určenou prioritu, aby bylo zřejmé, které příběhy se budou realizovat v dalším sprintu.
Na plánovací schůzce tým vybere příběhy pro následující sprint. Výběr by měl vycházet z následujících kritérií:
✅ Příběhy s nejvyšší prioritou
✅ Zkušenost týmu o tom, kolik Story Points zvládne za sprint. Toto se získává časem a zkušenostmi týmu.
✅ Neberte v úvahu jen celkový počet bodů a priority. Zvažte i rozdělení dovedností mezi vybrané příběhy. Pokud má tým například jen dva front-end vývojáře, nevybírejte pouze front-endové příběhy. Tím přetížíte jen tyto dva, zatímco zbytek týmu nebude mít co dělat. Znalost týmu tedy jde ruku v ruce s efektivitou sprintu.
Rychlostní faktor
Důležitá je rychlost týmu pro nadcházející sprint. Toto číslo nesouvisí s celkovým počtem Story Points, ale vyjadřuje, kolik kapacity bude mít tým k dispozici.
Pro přesné naplánování obsahu sprintu se kombinují oba aspekty:
- Rychlost týmu – měřena v dnech. Jeden člen týmu je k dispozici jeden celý den, což se rovná 1 v rychlosti týmu. Například tým 10 lidí plně k dispozici pro 2-týdenní sprint má kapacitu 100.
- Obvyklý počet Story Points, které tým dokončí za sprint – odvozen z předchozích zkušeností a souvisí s rychlostí týmu.
Nalezení správné rovnováhy vyžaduje čas a praxi.
Výhody a časté chyby
Je překvapující, jak moc jsou týmy schopny zkomplikovat proces při přechodu na agilní způsob práce. Zdá se, jako by bylo nutné vše „pochopit“, než se do toho pustíte. Bohužel, tento první krok je i tím nejtěžším. Někdy to trvá i roky, zejména v konzervativním prostředí, kde je těžké změnit zvyklosti.
Nicméně, jakmile to tým „pochopí“:
- Není třeba počítat lidi ani dny pro odhad času dokončení.
- Tým vytváří příběhy, které se vejdou do sprintu. Složitější příběhy se automaticky dělí na menší.
- Tým má přesné odhady a ví, kdy má být práce dokončena.
- Zvýší se spolehlivost a předvídatelnost týmu.
- Všichni lidé v týmu začnou chápat věci stejně. Po nějaké době odhadování ani nebude třeba. Všichni vidí v hlavě stejné číslo a mohou se k příběhům zavázat bez explicitního odhadu.
A tohle se stává, když tým nerozumí procesu:
- Stále se drží starých způsobů odhadování, a vše přepočítávají na dny a zapojené osoby. Story Points jim vlastně říkají jen počet dní.
- Vedení porovnává týmy na základě počtu dodaných Story Points za sprint. To je špatný přístup. Každý tým odhaduje body jinak. Nemá smysl se snažit sjednotit dva týmy, aby odhadovali „stejným způsobem“.
- Pro jeden tým může příběh znamenat nakreslení kruhu, pro jiný nakreslení domu se čtyřmi okny a dvěma dveřmi. A to je v pořádku.
- Týmy mají tendenci odhadovat vše mezi dvěma až čtyřmi čísly. Bojí se, že když je číslo 123, bude se to vztahovat k počtu dní. Fibonacciho stupnice má však neomezené množství čísel. Nemusíme se omezovat na 3, 5, nebo 8. Můžeme to dělat, pokud vytváříme příběhy tak složité, ale není to nutné.
- Odhad řídí senioři, kteří předurčují očekávání. Nikdy bychom neměli dovolit, aby odhad byl ovlivněn jedním členem týmu. Každý má právo vyjádřit svůj názor.
Závěrem
Přechod na agilní odhady není jednoduchý a vyžaduje přizpůsobení. Musí to pochopit jak týmy, tak i vedení. Pokud jedna strana procesu nerozumí, bude to těžké a plné rozporů.
Ale jakmile se vše srovná, začnou se dít skvělé věci. Týmy budou moci lépe odhadovat a plánovat a vedení bude mít spolehlivé a předvídatelné plány.
Dále se můžete podívat na nezdravé procesy, které mohou zničit váš sprint.