Odhady pro mobilní projekty — co to je, metody hodnocení úkolů

Co je to odhad?

Odhad (z angličtiny estimate — hodnocení) — předpovídání množství času nebo úsilí potřebného k provedení úkolu. V mobilním vývoji se odhady vyjadřují v hodinách, dnech, story bodech nebo peněžním ekvivalentu. Cílem odhadu není přesná předpověď, ale snížení nejistoty pro rozhodování.

Čím se odhad liší od závazku

Odhad — předpověď s tolerancí chyby. Závazek (commitment) — slib splnit úkol k určitému datu. Rozdíl je zásadní: odhad říká „pravděpodobně 5 dní„, závazek — „uděláme za 5 dní„. Manažeři si tyto pojmy často pletou a mění odhad v termín bez práva na chybu.

Odhad jako komunikační nástroj

Proces odhadování je stejně důležitý jako jeho výsledek. Když tým diskutuje o hodnocení úkolu, odhalují se skryté požadavky, závislosti a rizika. I když je konečné číslo nepřesné, diskuze poskytuje všem účastníkům porozumění úkolu. Proto jsou kolektivní metody hodnocení (Planning Poker) účinnější než individuální.

Metody odhadu ve vývoji

Existuje několik metod odhadu, každá vhodná pro různé fáze projektu a úrovně detailů. Výběr metody závisí na dostupných datech a požadované přesnosti.

Planning Poker

Planning Poker — nejoblíbenější metoda hodnocení v Agile. Každý vývojář dostane balíček karet s Fibonacciho čísly (1, 2, 3, 5, 8, 13, 21). Po prodiskutování úkolu všichni současně ukážou kartu. Pokud se odhady liší — vývojáři s minimálním a maximálním odhadem vysvětlí svou logiku, poté následuje opakované hlasování. Metoda eliminuje vliv autorit a poskytuje přesnější odhad.

T-Shirt sizing

T-Shirt sizing — hrubý odhad podle velikosti trička: XS, S, M, L, XL, XXL. Metoda se používá pro rychlý odhad velkých úkolů (epiků) v raných fázích, kdy detaily nejsou známy. Později je každý takový úkol dekomponován a odhadnut v Planning Poker. T-Shirt sizing trvá 5-10 minut na úkol, ale poskytuje pouze řádovou velikost.

Three-point estimation (PERT)

PERT používá tři odhady: optimistický (O), pesimistický (P) a nejpravděpodobnější (M). Konečný odhad se vypočítá podle vzorce: (O + 4M + P) / 6. Metoda zohledňuje nejistotu a poskytuje realističtější výsledek než jediný odhad. PERT je zvláště užitečný pro úkoly s vysokými riziky nebo novými technologiemi.

Přesnost odhadu: očekávání vs realita

Přesnost odhadu závisí na fázi projektu a množství známých informací. Čím dříve se hodnocení provádí, tím větší je tolerance chyby — to je normální a mělo by být zohledněno v plánování.

Kužel nejistoty

Kužel nejistoty (Cone of Uncertainty) — model popisující, jak se tolerance chyby odhadu snižuje s postupem projektu. Ve fázi koncepce činí tolerance chyby 400% (úkol může trvat 1 až 4 měsíce). V okamžiku sprintu — 20% (1-1.2 měsíce). Vědomí tohoto modelu pomáhá nevyžadovat přesné odhady v raných fázích.

Faktory ovlivňující přesnost

• Složitost úkolu — nová technologie nebo známá? Neznámé zvyšuje chybu 2-3krát.
• Velikost úkolu — malé úkoly (do 2 dnů) se odhadují přesněji než velké. Dekompozice zlepšuje přesnost.
• Zkušenosti týmu — tým pracující společně 6+ měsíců odhaduje o 30-50% přesněji než nový.
• Historická data — existence metrik velocity a cyklometrie zvyšuje přesnost předpovědí.

Relativní vs absolutní odhad

Relativní odhad (ve story bodech) je přesnější než absolutní (v hodinách), protože lidé lépe porovnávají úkoly, než odhadují čas. „Tento úkol je dvakrát složitější než tamten„ — spolehlivější úsudek než „tento úkol zabere 8 hodin„. Relativní odhady nezávisí na konkrétním vývojáři a zachovávají přesnost při změně vykonavatele.

Jak zlepšit přesnost hodnocení: nejlepší postupy

Přesnost odhadu lze zvýšit systematickým přístupem, kolektivní diskusí a analýzou minulých chyb. Existuje několik osvědčených postupů.

Dekompozice na 1-2 dny

Každý úkol odhadnutý na více než 2 dny by měl být dekomponován na podúkoly. Princip: pokud nelze úkol odhadnout s přesností 50%, je příliš velký. Rozdělte jej na kroky, které jsou srozumitelné a odhadnutelné. Po dekompozici je celkový odhad často 1.5-2krát větší než původní.

Historická data a metriky

Veďte historii odhadů a porovnávejte se skutečnými náklady. Například: „úkoly odhadnuté na 3 story body trvají v průměru 4 dny, ne 2„. Použijte velocity týmu k předpovídání: pokud tým uzavře 20 story bodů za sprint, neplánujte 30. Analýza přesnosti předchozích odhadů je nejlepší trénink dovednosti odhadování.

Kotvení a kalibrace

Kotvení — psychologický efekt, kdy první vyslovený odhad ovlivňuje všechny účastníky. Aby se předešlo kotvení, v Planning Poker všichni ukazují karty současně, ne postupně. Kalibrace — pravidelné porovnávání odhadů se skutečností: po 10-20 sprintech se tým díky zpětné vazbě učí odhadovat přesněji.

Zohlednění rizik v odhadu

Každý úkol obsahuje skrytá rizika: nemoc vývojáře, problém s API, změna požadavků. Přidejte do odhadu faktor upravený o riziko: pro úkoly s vysokým rizikem — násobitel 1.5-2, s nízkým — 1.1-1.2. Transparentně ukažte klientovi, jaká rizika byla zohledněna a jak ovlivňují termíny.

Typické chyby při odhadování

Chyby při odhadování se opakují ve většině týmů bez ohledu na jejich vyspělost. Znalost těchto chyb je prvním krokem k jejich nápravě.

Optimistický odhad

Nejčastější chyba — odhad podle nejlepšího scénáře: „když vše půjde perfektně, uděláme to za 3 dny„. Ve skutečnosti nic nejde perfektně: chyby, otázky ohledně požadavků, závislé úkoly. Řešení: odhadujte podle nejpravděpodobnějšího scénáře, ne optimistického. Použijte PERT k zohlednění variability.

Odhad pod tlakem

Když manažer řekne „potřebujeme to do pátku„, vývojář podvědomě přizpůsobí odhad tomuto termínu. Odhad pod tlakem je vždy podhodnocený a vede ke zpoždění. Řešení: odhad by měl předcházet termínu, ne naopak. Nejprve tým odhadne, poté strany dohodnou termíny.

Záměna složitosti a času

Složitost úkolu (kolik přemýšlet) a čas (kolik dělat) — různé metriky. Úkol může být jednoduchý, ale časově náročný (nakódovat 10 obrazovek). Nebo složitý, ale rychlý (najít chybu v legacy). Ve story bodech se obvykle odhaduje složitost a čas se odvozuje z velocity týmu.

Ignorování přepínání kontextu

Vývojář nepracuje 8 hodin nepřetržitě na jednom úkolu: schůzky, code review, pomoc kolegům, administrativa zabírají 30-50% pracovní doby. Přepínání kontextu by mělo být zohledněno v odhadu: reálně vývojář píše kód 3-4 hodiny denně.