Realita se plánu nepřizpůsobí, proto tomu musí být naopak. [Kniberg]

Dnes budu psát o černé magii dělání odhadů pracnosti při tvorbě software. Protože jsem nikdy na vlastní oči neviděl, že by někdo tuto činnost vykonával úspěšně, budu se více než obvykle odvolávat na literaturu. Takže tento článek berte prosím jen jako teoretické plky, ne jako zkušenosti z praxe.

K čemu vlastně jsou odhady? Zlí jazykové tvrdí, že odhady se dělají hlavně proto, aby manažer věděl, jak dlouhé žížaly si má nakreslit do MS Projectu. To ovšem není celá pravda. Odhady se hodí třeba proto, abychom věděli, jak si na projektu stojíme. Jestli stíháme, kolik nám zbývá práce a tak podobně. Bez odhadů se v podstatě nedá softwarový projekt řídit.

Jeden ze dvou hlavních důvodů splašení projektů jsou špatné odhady [Glass]

Ono to dává smysl. Pokud uděláme špatné odhady a podle nich naplánujeme projekt, je jasné, že projekt bude mít problémy. Podle mého názoru tedy stojí za to věnovat odhadům dostatek péče.

Existují jenom dva druhy odhadů: Štastné a mizerné [Chaos2001]

Jaké jsou nejčastější chyby při dělání odhadů?

Většina softwarových odhadů je dělána na začátku životního cyklu. To dává smysl jen do té doby, než si uvědomíme, že odhady jsou získány před definicí požadavků a tedy před tím než pochopíme řešený problém. Odhadování se tedy obvykle děje ve špatný čas. [Glass]

Ano, je zaběhnutou praxí, že se odhady dělají na začátku projektu. Tedy v době, kdy ještě nikdo pořádně neví o čem projekt bude, jaké problémy bude řešit a jak se bude realizovat.

Většina softwarových odhadů je dělána buď vyšším managementem nebo marketingem, tedy ne lidmi, kteří budou software tvořit. Odhady jsou tedy dělány špatnými lidmi. [Glass]

Z mých chabých zkušeností mohu říci, že to není tak, že by odhady dělali manažeři. Ti jenom určí rámec, do kterého se odhady musí vejít. Víme tedy například, že projekt musí být zvládnutý za tři měsíce. Na programátorech je ponechán volnost, aby si udělali odhady podle svého nejlepšího vědomí. Jediné co musí splňovat je to, že v součtu nesmí přesahovat ty dané tři měsíce :-/.

Pro netechnické lidi je běžné předpokládat, že programátoři nafukují své odhady. Mají často „pravidlo“ podle kterého oseknou odhady které slyší o třetinu nebo polovinu a považují to za „skutečný“ termín. Často cítí, ať oprávněně nebo ne, že je inženýrský tým šidí, většinou proto, že je pro ně celý inženýrský proces záhadou. Tento nedostatek důvěry způsobuje, že inženýři automaticky nafukují své odhady, protože vědí, že by jinak nedostali dost času. A i když situace není takto zlá, ovzduší nedůvěry stále existuje v mnoha organizacích. [Stellman]

Pamatuji projekt, kdy se projekťák vydržel hodiny hádat s programátorem o odhadech. Programátor předkládal odhady a projekťák jim vůbec nevěřil. On jim ani věřit nemohl, protože mu neseděly do plánu. Nejhorší na tom je, že se často nakonec ukáže, že projekťák má pravdu. Činnost kterou programátor odhadl na měsíc je možné stihnou do čtrnácti dnů. Ovšem za cenu přesčasů, práce o víkendech a všeobecně nízké kvality.

Pokaždé když se toto stane, stoupne neopodstatněná důvěra manažera ve vlastní odhadovací schopnosti. Časem se tým stává rozčarovaným a zahořkým, pocit kamarádství vytvořený za dlouhých nocí a práce pod tlakem je pohřben vztekem a pocitem marnosti. [Stellman]

Abych nepůsobil tak negativisticky jak je mým zvykem, uvedu i dva postupy jak odhady vylepšit.

Aby se [lidé dělající odhady] vypořádali s neúplnou informací, musí dělat předpoklady ohledně práce, kterou je potřeba udělat. … Jedním vedlejším produktem sepsaných předpokladů je to, že tlačí na manažery, aby dovolili udělat odhady znovu, když se předpoklady změní. [Stellman]

Jednoduchý recept, když děláte odhad, napište k němu, za jakých předpokladů platí. Například můžete napsat, že implementace funkcionality XYZ bude trvat tři dny, pokud bude použita knihovna ABC a bude na tom pracovat člověk, který s ní má zkušenosti. Pokud tyto předpoklady nebudou splněny, nebude platit ani odhad. Takže až se bude manažer divit, že jste pozadu, tak mu můžete snadno vysvětlit proč tomu tak je.

Softwarové odhady jsou zřídka upřesňovány v průběhu projektu. Tudíž odhady udělané ve špatný čas špatnými lidmi nejsou obvykle opraveny. [Glass]

Je také dobré si vyjasnit co vlastně odhadujeme, jestli je to čistý čas potřebný na implementaci nebo jestli jsou v odhadu zahrnuty unit testy, konfigurace, instalace a nevím co ještě.

Druhá rada je také snadná. Dělejte odhady ve skupině. Protože mají manažeři sklon odhady podhodnocovat a inženýři je naopak nadhodnocovat je dobrá taktika nechat je dělat odhady dohromady. Tady je nutné zajistit, aby neměla žádná strana navrch. Ideální je takový stav, kdy se dospěje ke konsenzu. Pokud se na odhadování podílí celý realizační tým i za účasti zákazníka, přináší to i spoustu jiných výhod. Jednou z nich je, že si navzájem vysvětlí, co si pod funkcionalitou XYZ konkrétně představují a proč si která strana myslí, že práce bude trvat tak a tak dlouho. Navíc pokud se tým podílí na odhadech, bere je za své a má větší sklon je dodržovat.

Pokud pracujete ve formálnějším prostředí, doporučuji metodu Wideband Delphi [Stellman]. Její Agilnější a víc cool variantou je plánovací poker [Haugen]. Tyto metody vám poskytnou dobrý rámec pro odhadování ve skupině.

Zdroje:

• Stellman A., Green J. Applied Software Management, O’Reilly Media, Inc. (November 18, 2005)
• Glass R. Facts and Fallacies of Software Engineering, Addison-Wesley Professional; (October 28, 2002)
• Haugen N., Nils Haugen on Planning Poker,http://www.infoq.com/interviews/nils-haugen-planning-poker
• Kniberg H., Scrum and XP from the Trenches, http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
• Standish Group International, Extreme Chaos, http://www.vertexlogic.com/processOnline/processData/documents/pdf/extreme_chaos.pdf