Žádný plán nepřežije střet s nepřítelem. [polní maršál Helmut Graf von Moltke]

Včera jsem dočetl knihu Agile Estimating and Planning od Mika Cohna. Je to kniha docela zajímavá, zvlášť pro mě, který o daném tématu neví skoro nic.

Dozvěděl jsem se v ní proč je dobré plánovat, proč je to tak těžké a hlavně jak to dělat správně agilně. Konečně jsem také pochopil co je to story point (bod příběhu ??).

V agilních procesech by mělo odhadování mělo probíhat ve dvou fázích. V první fázi určíme takzvané uživatelské příběhy (story). Tzn. sepíšeme si, co vlastně budou jednotliví uživatelé se systémem dělat. Je to podobné jako klasické případy užití (use case), jenom mnohem stručnější. Příběh může vypadat například takto: „Jako uživatel mohu uložit dokument“. Poté celý tým odhaduje relativní velikost jednotlivých příběhu. Přiřazuje jim body, které nemají žádný reálný základ. Odrážejí jenom relativní velikost jednotlivých příběhů mezi sebou. Takže uložení dokumentu může mít velikost 5 bodů, načtení třeba 3. Sečtením bodů všech příběhů získáme odhad velikosti celého projektu (releasu).

Poté nastává druhá fáze, kdy se snažíme převést bezrozměrné body na čas. Zde nám začíná hrát roli rychlost (velocity). Pokud už agilně vyvíjíme, víme kolik bodů zvládne daný tým udělat za iteraci. Tomuto číslu budeme říkat rychlost. Poté už můžeme přibližně odhadnout, kolik iterací zabere současný projekt. Jednoduše vynásobíme rychlost počtem bodů. Pokud rychlost neznáme, můžeme ji odhadnout tak, že si zkusíme odhadnout trvání pár příběhů v hodinách a z tohoto odhadu odhadnout rychlost. Nicméně pravá rychlost týmu se projeví až (už) po prvních pár iteracích.

V čem je tento přístup výhodný? Je snadný. Je snadné říci, jestli je implementace jednoho uživatelského příběhu dvakrát těžší než implementace druhého. Je snadné říci, že jiné dva příběhy jsou přibližně stejně obtížné. Při odhadování velikosti opravdu jenom porovnávám jednotlivé příběhy mezi sebou.

Čas se počítá až v druhé fázi a to více méně automaticky. Rychlost je dána, tu známe z předchozích iterací. Takže jenom vynásobíme velikost projektu rychlostí a máme odhad trvání projektu. Je hodně těžké švindlovat a lhát si do kapsy. Těžko se hájí to, že začneme tvrdit, že se rychlost z čista jasna zvýší na dvojnásobek. Naopak, když se nám kvůli nějakým problémům rychlost sníží, projekt se automaticky přeplánuje. Okamžitě uvidíme, jak dlouho bude projekt trvat pokud budeme mít tuto rychlost i v dalších iteracích.

Kniha se samozřejmě věnuje i jiným tématům než odhadování a plánování celého projektu. Věnuje se i plánování jednotlivých iterací, monitorování, komunikaci a jiným tématům. Hodně pěkná je i kapitola o určování toho, které příběhy implementovat a které ne, ale o tom snad napíši někdy jindy.

Poznámka: Snažil jsem se termíny překládat do češtiny. Uvědomuji si, že některé termíny znějí trochu kostrbatě. Pokud máte lepší překlad, napište mi ho prosím.