Pravidelně se setkávám s názorem, že odhadování při vývoji je zbytečné, nepřesné. Že manažeři zneužívají toho, že z odhadu dělají závazek. Že jsou vývojáři nuceni do snižování odhadů, kterým pak sami nevěří, ale manažeři je k těmto cílům zavazují.

Nejsmutnější na tom je fakt, že všechno tohle je částečně pravda.

Odhady se neberou jako odhady, ale závazky. Zákazníci i manažeři ignorují to, že odhadovat je od slova hádat.

Sledování burndown chartů ve firmách bývá smutné tak ve 80 % případů.

Lidé odhadují špatně. Odhady často dělá 1 člověk pro ostatní. Používají se různé bezpečnostní polštáře, bulharské konstanty.

Cílí se velocity jako závazek na přesný počet bodů, přitom i v hodně stabilizovaných implementacích Scrumu bývá pravděpodobnost dosažení průměrné velocity kolem 50 %, závazek by měl být nižší o tolik, abyste se dostali na vysokou úroveň jistoty (třeba > 90 %, což bývá velocity nižší o těch asi 10–15 %, hodně záleží, jak je u vás vývoj stabilizovaný).

Někdy týmy konstantně nestíhají sprinty a celé měsíce s tím nic nedělají a velocity nesníží. Všechno tohle vede k myšlence, že odhadování je špatně, stejně nevyjde, sprint se stejně nestihne a my na tom planningu sedíme ty hodiny úplně k ničemu.

I velmi dobří vývojáři, kterých si vážím, si myslí, že je lepší neodhadovat.

Jenže tohle naráží na několik zásadních problémů.

  1. Každý manažer, kterému řeknete, že u úkolů nehodláte sledovat progres, se vám vysměje.
  2. Každý zákazník, kterému řeknete, že mu neřeknete, kolik ho implementace úkolu bude stát, se vám vysměje.
  3. Projekt, který nikdo neměří, nemůže uspět. Za ty spousty let, co vyvíjím, jsem nezažil projekt, kde by se nemuselo občas ořezávat zadání, zjednodušovat. Když nevíte, co je zhruba jak složité, jste slepí při sekání.

Pokud se tým rozhodne, že nechce estimovat, musí tyto problémy kompenzovat, jinak není konkurenceschopný.

V každém projektu musíte být schopni sledovat progres. V každém projektu musíte být schopni říct zákazníkovi, kolik ho bude vývoj vlastnosti stát. V každém projektu musíte dát zákazníkovi možnost srazit budget tím, že něco zjednoduší a dát mu dost informací k tomu, aby tohoto byl schopen.

V posledních 2 informačním systémech, který jsme pro zákazníky vyvíjeli, stejně jako v aplikaci, kterou vyvíjíme pro zákazníka teď, jsme zkusili odhady nedělat. Nutné říct, že úspěšně. Za celou dobu nebyl ohodnocen ani jeden úkol.

Věc jsme ale vyřešili tím, že jsme User Stories rozbili na tak malé, jak je to jen možné. Pořád se jednalo o úplné User Story s kompletní logikou, ale byly až triviálně malé. Vývojář pak stihl doručit několik US za jeden den.

V tu chvíli přestaly být měřítkem body nebo hodiny přiřazené úkolům. Měřítkem začaly být úkoly samotné. Jakmile zákazník přišel s větším úkolem, rozbil jsem s ním úkoly na tak maličké, že bylo jasné, že když je z toho 10 nových úkolů, potrvá pár dní takovou věc vyvinout.

V tu chvíli může zákazník sledovat progres – jen už nesleduje body, ale celé úkoly. Může si spočítat, kolik ho to bude stát. Ví totiž, kolik stojí 1 úkol a ví, že se stíhá určitý počet úkolů za iteraci. Když potřebuje ušetřit, může obětovat nějaké User Story a je to.

Tento přístup nemusí být vhodný pro všechny. Tvrdit, že neodhadování úkolů je vhodné pro všechny, mi přijde naivní. Kupříkladu u vývoje hardware se na tak malé US nikdy nedostanete. Tam zákazníkům odhadování doporučuji a s určitou znalostí statistiky, sledováním velocity a se správými procesy můžou odhady být velmi užitečné a až esenciální k úspěchu u zákazníka.