Děláme odhady

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:

11 thoughts on “Děláme odhady

  1. Wu

    Z vlastní zkušenosti vidím jako nejdůležitější nezapomenout, že jen málokdo se může danému projektu věnovat 100% času – takže odhad se musí korigovat “koeficientem vytíženosti” :).

  2. Lukáš Křečan Post author

    To kolik procent času mohu věnovat projektu bych zohledňoval až při plánování, na při odhadech. U odhadů se doporučuje udávat čas v “ideálních člověkodnech”.

  3. Wu

    Jistě. Ovšem v praxi se s ideálními člověkodny běžně pracuje jako s člověkodny normálními :(.

  4. Dagi

    Z vlastni zkusenosti mohu rict, ze vetsina odhadu trpi temi citovanymi neduhy. Podle meho nazoru je lepsi mit hruby odhad a iterativnim zpusobem se k nemu po malych kruccich (rekneme tyden) blizit. Pak v kazdou chvili presne vime kde jsme a kam se mame dostat. Pokud uz delat dlouhodobejsi odhady, pak se mi libi ta myslenka pridani invariant, za kterych ten odhad plati.

  5. filemon

    Delat odhady ve skupine je skutecne rada nad zlato a X krat se mi vyplatila. Muzete si ji opeprit nekterou planovaci hrou – treba planning pokerem.

  6. Marek

    to Lukas a idealni clovekoden – co delat v situaci, kdy odhad = planovani? :-))

  7. Honza

    Pekny clanek, nakonec se tam i cosi z praxe naslo. Myslim ze by bylo dobre zpomenout zakladni pravdila sofwaroveho inzenyrstvi:

    80/20 = 80% casu nam zabere napsani 20% funkcionality

    Kazdy projekt bude trvat dele nez se odhadovalo a to dokonce i ten ve kterem se s timto pravidlem pocita. Uspesne projekty jsou ty ktere konverguji.

  8. finn

    co se tyce skupinoveho odhadovani casu – hezky to ma zarizeny SCRUM, kdy se na jak na zacatku projektu tak i na zacatku jednotlivych iteraci na casovem odhadu podili cely tym, kdy kazdy ucini svuj soukromy a nezavisly odhad a nasledne se nad temito cisly v tymu diskutuje (nekdo udela optimistictejsi odhad, protoze na neco zapomene ci podceni, nekdo je zase pesimistictejsi a v kazde veci vidi potencionalni problem)…

    jina, videl jsem uz i par vzorecku, ktere pocitaji jakysi vazeny prumer, ktery by mel vyjadrovat nejpravdepodobnejsi dobu trvani tasku:

    (3*o + 2*p)/5

    nebo

    (o + 4*n + p)/6

    kde
    o = optimisticky odhad – za predpokladu, ze vse pujde jak po masle
    p = pesimisticky odhad – za predpokladu, ze vsecho se bude *** jak muze
    n = normalni odhad – cislo, ktere se na zaklade nejakych zkusenosti zda byt jako nejpravdepodobnejsi

  9. Petr Jůza

    Uplne souhlasim s tim, ze idealni clovekoden a normalni clovekoden jsou celkem rozdilne. Snad jsme jeste nemeli projekt, kde by naklady byly nad odhadovanymi naklady, ale mame problemy s terminy, prave z duvodu rozdilu mezi idealnim a normalnim dnem.

    My jsme z duvodu ulehceni odhadovani v nasi firme dali dohromady konstantu (nyni priblizne 2.2, kterou na zaklade zkusenosti upresnujeme), kterou nasobime odhad na cisty vyvoj a tim dostaneme odhad na cely projekt. Jinak receno odhadneme cisty vyvoj a vynasobime konstantou 2.2, ktera v sobe zahrnuje tu potrebnou vatu okolo – testovani, analyza, navrh, dokumentace, skoleni, nasazeni.

    Toto je samozrejme vhodne jen pro hrube odhady nakladu na projekty a ze zkusenosti mohu rici, ze to tak priblizne sedi. Pro vytvoreni harmonogramu projektu je uz pak potreba se tim zabyvat podrobneji.

    PETR

  10. Indrik

    Já vidim dobré plánování jako takové, které počítá s tim, že odhad je špatný, proto si vytváří rezervy, které využije, pokud se něco nebude dařit podle plánu (velmi pravděpodobné). Pak už je to jenom u nastavení té vaty (o které se tu už taky mluvilo). Metodologie, která toto uvažuje je Critical Chain Project Management.

    Těm, co na tom pracují by se však měly říkat optimisticky odhadunuté časy, protože když se jim řekne, že na to maj 2×víc času, tak to zaručeně neudělaj rychleji, i kdyby mohli. = Studentův syndrom a Parkinsonův zákon jede…

    Jenom by mě zajímalo, jestli někdo na těchto CCPM opravdu jede, a jakej k tomu používá SW.. Vim o nějakejch pluginech akorát. Dělat to všechno růčo je hc..

  11. Petr Macek

    Reaguji na Petra: také máme podobnou konstantu (říkáme ji bulharská konstanta) a má hodnotu přibližně 3. Programátoři mají tendenci většinou odhad podceňovat, zvlášť v českých podmínkách. Proto doporučuji konstantu použít u všech projektů, které nejedou dle agilních metodik.

Comments are closed.