Řízení rizik vám často řekne víc pravdy než chcete. [Mike Evans]

Dnes budu psát o další pěkné knize. Jmenuje se „Waltzing with Bears“ a jejími autory jsou Tom DeMarco a Timothy Lister. Kniha je o řízení rizik na softwarových projektech – risk managementu. Pro mě, který o tématu dosud nic netušil to je naprosto úžasná kniha, nicméně bych ji doporučil i zkušenějším projekťákům. Cítil bych se lépe, kdyby projekty na kterých pracuji, vedl člověk, který tuto knihu četl.

Nemá cenu pokoušet se tu popsat celou knihu, doporučuji vám přečíst si ji. Dostane se vám opravdu zevrubného úvodu do správy rizik. Vypíchnu jen pár částí, které mě opravdu zaujaly.

Velká část knihy se točí kolem diagramů rizika (risk diagrams). Vypadají takto

V tomto diagramu je na vodorovné ose vyobrazen čas a na svislé pravděpodobnost dodání hotového software. Tzn. termín dodání není pevné číslo, ale rozložení pravděpodobnosti. Prostě se nedá říci kdy bude software hotov, je možné to říci jenom s nějakou pravděpodobností. Na našem grafu je zajímavé datum 1. ledna – místo kde se pravděpodobnost dodání odlepuje od nuly. Co to je za datum? To je datum dané těmi úplně nejoptimističtějšími odhady. Často je to bohužel také datum, které je vybráno jako termín dodávky. Jaká je pravděpodobnost jeho splnění? Skoro nula. Proto ho také autoři označují jako N – nano-percent date. Co tahle 1. dubna, datum, kde je křivka na svém maximu? Protože má naše křivka těžký konec, pravděpodobnost dodání do 1. dubna se pohybuje kolem 33%. Nic moc. Pokud chceme mít alespoň padesátiprocentní šanci dodržení termínu, musíme ho určit na 1. května. Stoprocentní jistotu dodání budeme mít až 31. prosince! Samozřejmě záleží na tvaru a šířce té křivky. Pro IT se šířka onoho okna údajně pohybuje mezi 150% a 200% data N.

Dále mě zaujalo pět rizik, které se týkají každého softwarového projektu. Pokud s těmito riziky váš projekt nepočítá, je jisté, že o správu rizik ani nezavadil.

1. Chyba plánování – Chybný plán je často důvodem svého vlastního nedodržení. Obzvlášť postupuje-li se odzadu a plán se určuje podle předem daného termínu.
2. Nafukování požadavků – Jasné riziko, požadavky se mění a přidávají se což nepříznivě ovlivňuje pravděpodobnost splnění plánu.
3. Fluktulace – Zkušení zaměstnanci odcházejí, nezkušení přicházejí, k tomu asi není co dodat.
4. Zhroucení specifikace – Prostě a jednoduše najednou zjistíme, že se vůbec nedaří produkt naspecifikovat. Zákazník se nedokáže vyjádřit co vlasntě chce, jednotlivá oddělení mají protichůdné požadavky atp. Problém se pozná podle toho, že se specifikace problémových bodů odkládá až na později. Často do doby kdy se to všechno zhroutí.
5. Nedostatečná výkonnost – Věc kterou můžeme ovlivnit my vývojáři. Buď jsme výkonní nebo ne.

Co s riziky dělat se podrobně dočtete v knize, kterou vřele doporučuji. No a abych nebyl přehnaně pozitivní, něco bych jí přeci jen vytkl – je napsána složitější angličtinou, než na jakou jsme z odborné literatury zvyklí, takže si člověk pěkně prohloubí slovní zásobu. Rozloučím se citátem, který stojí za zamyšlení

Není-li v projektu riziko, nedělejte ho.

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

Dnes bych vás chtěl upozornit na článek „Extreme chaos“, který vydala Standish Group v roce 2001. Standish Group je organizace, která se živí výzkumem projektů a důvodů jejich úspěchů a pádů. Jde o komerční instituci, takže se o svá data nedělí často. Článek „Extreme chaos“ je jedním z mála volně dostupných materiálů od této organizace. Protože se článek opírá o nezveřejněné informace je potřeba brát údaje v něm publikované s rezervou, nicméně i tak jsou zajímavé.

Ale už dost úvodu, hned na první stránce článku uvidíme následující graf výsledků projektů

Vidíme, že

• 28% (z asi 300 000) projektů bylo úspěšných. Tzn. byly dokončeny včas a vešly se do rozpočtu.
• 49% projektů bylo „problematických“. Tzn. byly sice dokončeny, ale byly dražší, trvaly déle nebo obsahovaly méně funkcionality než se odhadovalo.
• 23% projektů selhalo. Tzn. byly zrušeny před dokončením.

Docela zajímavá čísla, co říkáte? Ještě zajímavější je ale další část, v které se dozvíme jak zařídit aby náš projekt byl úspěšný. Recept je jednoduchý. Stačí smíchat následující ingredience a úspěch je váš (číslo v závorce označuje důležitost):

1. Podpora vedení (18)
2. Zapojení uživatelů (16)
3. Zkušený projektový manager (14)
4. Jasné business cíle (12)
5. Minimalizovaný rozsah (10)
6. Standardní softwarová infrastruktura (8)
7. Ustálené základní požadavky (6)
8. Formální metodologie (6)
9. Věrohodné odhady (5)
10. Ostatní (5)

Úspěšný projekt samozřejmě nemusí obsahovat všechny uvedené ingredience. Ony jsou i tak dost provázané. Například je zřejmé, že šikovný projekťák si dohlédne na to, aby byly definovány jasné business cíle a rozsah byl co nejmenší.

Z pohledu programátora je zajímavé to, že moje schopnosti jsou schovány pod kolonkou „schopný personál“ v kategorii ostatní (důležitost menší než 5% bůůů). Když přemůžu tento šok, je pro mě zajímavý i bod 5. Uvádí se, že 70% kódu je infrastruktura. To jest kód, který neřeší business problémy, ale cosi, co zákazníka vůbec nezajímá. Tím, že pro tuto infrastrukturu použiji nějaký již hotový kód tedy mohu zvýšit šanci projektu na úspěch.

Proč to všechno píši? Vždyť jsou to data sedm let stará a navíc z daleké Ameriky? Myslím si, že neuškodí se nad uvedenými čísly zamyslet. Podívat se zpětně na úspěšné i méně úspěšné projekty a vzpomenout si, které z uvedených ingrediencí obsahovali a které ne.