•  

V agile existuje více přístupů, jak pochopit body, které se používají k vyjádření náročnosti úkolu. Dnes si tady jednotlivé přístupy sepíšeme a srovnáme.

Idealizované člověkohodiny

V tomto přístupu se tým sejde a odhaduje, kolik času by teoreticky bylo potřeba, pokud by se lidé výhradně soustředili jen na práci. Tento přístup používá eXtreme Programming.

Pokud je v týmu více lidí různých odborností, je možné sčítat jejich odhady, popř. je i držet odděleně.

Výhody tohoto přístupu:

  • idealizovaná člověkohodina se dá snadno přetavit v reálný čas, snáze se tedy zahajuje první iterace (sprint pokud používáte Scrum)
  • přístup dobře zvládá členy týmu různých odborností
  • nový člověk v týmu snadno uchopí body a začne brzo odhadovat

Nevýhody tohoto přístupu:

  • hodiny jsou jen pomůcka do začátku, když ale jsou zpočátku hodiny použity na kalibraci, později může být pro někoho těžší se od nich oprostit
  • lidé můžou cítit frustraci, když zjistí, že dodávají třeba jen 2 idealizované člověkohodiny denně
  • vynořuje se otázka: čí je vlastně ta „idealizovaná člověkohodina“? Tedy mám odhadovat, jak dlouho by to trvalo mě, nebo team leaderovi, virtuálnímu průměrnému vývojáři? Odpověď: běžnému členovi v situaci, kdy má všechny informace.

Porovnávání úkolů

V tomto přístupu vezmete nejmenší netriviální úkol v backlogu a z něj uděláte 1 bod, pak vezmete největší úkol, který jste ochotni přijmout do iterace (sprintu pokud používáte Scrum) a z něj uděláte 8 bodů. Na zvolené škále (nejčastěji 0, 1, 2, 3, 5, 8 nebo 0, 1, 2, 4, 8) pak volíte, jak se vám úkol zdá v porovnání mezi těmito dvěmi.

Výhody tohoto přístupu:

  • časem se chcete oprostit od hodin a tento přístup k tomu napomáhá
  • nevadí větší nepřesnost, celý přístup je od začátku jen vyjádřením porovnání složitosti

Nevýhody jsou:

  • je těžší odhadování v okamžiku, kdy máte v týmu více odborností a musíte buď hledat celkové úsilí za všechny odbornosti (jak může tester vědět, kolik úsilí bude potřebovat databázista?)
  • úkoly časem zastarají, lidé v týmu se vymění, architektura se změní, je potřeba najít jiné srovnávací úkoly
  • je těžké určit, kolik bodů se stihne v prvních iteracích (sprintech pokud používáte Scrum)

Konečný cíl je ale stejně vždy jen schopnost vyjádřit, jak náročný úkol je, kolik bude vyžadovat úsilí a ať už zvolíte první přístup, nebo ten druhý, platí, že konečným cílem je zapomenout na nějaké idealizované člověkohodiny, benchmarky, ale mít podvědomé povědomí o tom, co bod znamená. Pak už bodujete podle intuice a zkušenosti. Oba přístupy jsou jen pomůcka k tomuto cíli.


Zajímá vás, jak probíhá implementace Scrumu a zda Scrum opravdu pomáhá.

Přečtěte si case study (PDF, 100 kB).

Pokud vás case study zaujala, neváhejte mě kontaktovat.


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.


Vývoj software jako podhoubí agile má svá specifika, která se podepsala jak na agilních metodikách, tak i na agilních technikách. Firmy, které se rozhodují, zda adoptovat Agile i mimo vývoj software (tedy např. do vývoje Hardware). Já jsem už v několika firmách, které dělají Harware, agilní vývoj nasazoval.

S čím sem se setkal:

  • vyšší náklady – vyvíjet software je drahé. Vyvíjet hardware je ale mnohem dražší. Potřebujete více lidí různých odborností. Vyvinout něco, co bude pro zákazníka užitečné představuje řadu odborností. Subjektivně mám i pocit, že ve vývoji hardware jsou lidé méně produktivní. V praxi pak firma má víc co ztratit, když se něco nepovede.
  • vývoj testovacích desek – ve vývoji sw je běžné, že má každý vývojář svou vlastní kopii celé aplikace a na ní si pracuje. U hardware může být zdlouhavé a drahé udělat pro každého vývojáře jeho testovací desku s kompletním zapojením a ještě vývoj na desce synchronizovat mezi sebou. V praxi se pak více lidí střídá na 1 rozpracované vě­ci.
  • složité Continuous Integration – hardware musí být synchronizovaný s firmwarem. Co je v železe, je i v „mozku“ toho železa. Ale pak většinou ještě existuje nějaký obslužný software psaný ve vysokoúrovňovém jazyce, které zařízení na dálku ovládá, monitoruje. Vývoj takového softwaru se velmi těžko synchronizuje s vývojem hardware, obvykle se úkoly v SW dají rozbít do menších celků, které se dají vyvíjet průběžně – většinu času ale není HW k dispozici. A nebo se čeká, až je HW+FW hotov, jenže to všechno protáhne a zdrží. Takže v praxi běží vývoj HW+FW a SW přibližně paralelně a jednou za čas se setkají, ale neustále integrované části řešení nejsou. U jednoho zákazníka teď usilujeme, aby byl HW i SW synchronizovaný co 2 týdny.
  • nemožnost Continuous Delivery – to si takhle u AŽD školím a povídám, ať dělají časté releasy, ať se průběžně učí a získávají zpětnou vazbu. To bylo poprvé, co jsem na problém vývoje HW narazil. Dostala mě odzbrojící otázka: „To máme do těch kolejí každé 2 týdny znovu položit desítky kilometrů kabelů?“. Samozřejmě, že ne. V praxi to pak znamená, že doba, než půjdete s něčím ven je protažená do doby, kdy bude produkt řádově stabilnější. Znamená to, že budete víc testovat. Že budete usilovat o to, aby hardware byl udělaný správně a vše se dalo případně hasit pomocí upgrade firmware a software.
  • zadávání práce bez User Stories – napsat User Story tak, abyste se ve světě hardware dostali na potřebnou úroveň granularity, bývá často nemožné (a to rozpadat úkoly na menší opravdu umím). Situace, kdy: „Uživatel zapne mobilní telefon“ se ve výsledku může rozpadnout na dobrou stovku podúkolů. Ty nejsou businessové. Produkťák těžko věc zkontroluje, dlouho úkoly zůstávají čistě v kontrole vývojářů. To zvyšuje riziko, že se neudělá něco businessově správně.

Nechci tím ale říci, že agile se nehodí do vývoje hardware. Pořád má řadu věcí, které se použít dají.

Ve zkratce to je třeba PDCA (Plan-Do-Check-Act) přístup při vývoji a ověřování produktu. Technologická dema, kdy zákazníkům na testovací desce můžete předvádět produkty, budování multidiscipli­nárních týmů.

Výsledkem pak je, že je vývoj hardware rychlejší, pružnější, tým se rychleji učí a to jak ze směru businessu, tak ze směru technologie. Agilní vývoj se výborně doplňuje se štíhlou výrobou (nebo i agilní výrobou, která existuje už 20 let, ale k rozšíření agilní výroby na srovnatelnou úroveň s tou štíhlou nedošlo).


Při vývoji software se těžko odhaduje a těžko měří nějaká produktivita. Čím víc je práce předvidatelná, tím je věc lehčí. Čím víc se blíží výzkumu, tím je jakýkoliv odhad složitější.

Přesto je občas nutné zadat a trackovat do backlogu úkol, který je extrémně nejistý. Případně ani není jasné, k jakým krokům má dojít.

V tu chvíli přichází na řadu úkol typu research.

Úkol typu research je samostatný typ, měl by ho tedy ovládat i software, který na Scrum používáte.

O research platí, že:

  • zadání nemusí dodržovat strukturu User Story (kdo, co, proč)
  • je možné úkol ohodnotit body, ale s velkou mírou nejistoty
  • je určeno, jaký bude výstup (odpověď jde to/nejde to; odhad; analýza s popisem, jak daný úkol udělat)
  • je možný timebox, tedy určení, kolik času se smí úkolem nejvíc strávit

Potom, když takový úkol vkládáte do sprintu, očekáváte, že výstup vám umožní naplánovat, zanalyzovat, realizovat nějaký další úkol v dalším sprintu. To za předpokladu, že implementace může počkat do dalšího sprintu.

V okamžiku, kdy potřebujete daný úkol zrealizovat už v daném sprintu, ale je velmi nejistý, spojíte vlastnosti Research tasku s User Story.

Pak platí, že:

  • se dodržuje struktura User Story
  • dává se odhad v bodech
  • je určeno, že výstupem bude buď story, nebo odpověď, že se to nedá zrealizovat/stih­nout
  • je možné dát timebox, tedy určit, kolik času smí úkol nejdéle trvat, pak se musí jít za Product Ownerem a dohodnout se, jestli se má pokračovat (poznámka: mezi timeboxem a body by měla existovat relace, např. mnohabodový úkol těžko můžete timeboxovat na 1 hodinu)

Úkoly typu research se vyskytují přirozeně i v prostředí, kde součástí týmu je Business Analytik. Takové úkoly lze ale chápat spíš jako User Story a tak se i zadávají (je otázkou, zda dodržet daný formát, ale typ úkolu to bude US). Research úkoly jsou pro situace, kdy vám chybí netypická informace a cílem je informaci získat.