úterý 6. dubna 2010

Odhady pracnosti

O odhadech pracnosti při tvorbě softwaru už byla napsána řada knih a já ani nemám ambici přinést tímto článkem něco nového. Přesto… povědomí vývojářů, konzultantů, projekt manažerů (a všech ostatních ;)) o zkušenostech, které softwarový průmysl nasbíral za desítky let své existence, je mimořádně nízké, takže trocha opakování snad neuškodí. V tomto článku chci ukázat, jak dělám odhady programátorských prací já osobně a upozornit na některé časté chyby. Můj osobní přístup nelze samozřejmě považovat za univerzálně platný. Pro další postupy, lepší vysvětlení, teoretické podklady, statistiky atd. musíte zapátrat v odborné literatuře. V češtině nelze než doporučit Odhadování softwarových projektů (možná znáte originální název Software Estimation: Demystifying the Black Art). Cíl odhadu Nejprve je třeba si ujasnit, k čemu má odhad sloužit. Z toho pak plyne, v jaké fázi projektu odhad potřebujeme, s jakou přesností atd. Někdy stačí velmi vágní odhady (projekty typu až to bude, tak to dodáme) jindy je třeba dělit práci do iterací, volit variantu, která se stihne do fixního data atd. Odhad by měl poskytnout data dostatečná pro plánování a řízení projektu, nemůže poskytnout přesné číslo, jak dlouho bude práce trvat (tuším McConnell to nazývá „předpovídání budoucnosti“). Přesto je nalezení tohoto magického čísla cílem odhadů na mnoha projektech – a asi nepřekvapí, že v předpovídání budoucnosti lidstvo velký pokrok neudělalo. :-) Jednou z nejčastějších chyb je přímá kalkulace ceny projektu z odhadu (odhad v hodinách × hodinová sazba). To je také zřejmě důvodem, proč jsou tak často požadovány „předpovědi budoucnosti“. Krom negativních dopadů na konstrukci ceny má tento přístup také dopad na tvorbu odhadu – místo aby se udělal co nejpřesnější odhad a cena se stanovila nezávisle, vytváří se tlak na změnu odhadu. Problém je v tom, že takto modifikovaný odhad (ať už kterýmkoli směrem) může být těžko použit pro plánování projektu. Byl jsem dokonce svědkem snah přenést zodpovědnost za dodržení „odhadu“ na vývojáře. Nutným důsledkem by pak bylo dohadování mezi vývojářem (snažícím se nadsadit odhad tak, aby se do něj vždy vešel) a projekt managerem (snažícím se stlačit termín). Skutečný odhad by v takovém procesu figuroval jen zcela okrajově. Kdy odhadovat Projekt lze odhadovat v kteroukoli fázi, ale dosažitelná přesnost je limitována množstvím informací, které jsou k dispozici. Například pokud odhadujete pracnost na základě pouhého uživatelského požadavku, nemá podle mého názoru smysl větší přesnost než Malá/Střední/Velká náročnost (a i tak se to často nepodaří trefit). Pokud chcete získat (relativně) přesný odhad, potřebujete znát všechny funkční požadavky i způsob implementace. Protože v Dynamics AX většinou zasahujete do existujícího kódu, je nutné vědět, jaké části již existují a bude je možné využít a jaké je třeba nově naimplementovat. Někdy je také vhodné vytvořit prototypy nejasných částí ještě před odhadem pracnosti. To všechno si pochopitelně vyžádá určitý čas, se kterým musí být počítáno v projektovém plánu. Jak odhadovat První a nejdůležitější částí odhadu je dekompozice na menší části. Tyto části je nutné nejprve vůbec identifikovat (do té doby jen tušíte, co všechno bude asi tak třeba udělat), ověřit, zda pokrývají všechny požadavky, a nakonec je postupně odhadnout. Často nejsou všechny potřebné informace k dispozici, ale je možné odhadnout alespoň některé části a ke zbylým se vrátit později. Já projekt člením po (relativně) samostatně funkčních blocích realizovatelných v řádu hodin čí dnů (dnů v případech, kdy je v odhadu příliš mnoho nejistoty). Odhady rozepisované podle jednotlivých objektů (tedy ne podle funkcí) považuji za hůře členitelné a nerespektující skutečný postup práce při vývoji. Ke každému funkčnímu bloku zapisuji vše, co je třeba udělat, ale tyto detaily neodhaduji samostatně. Seznam pak používám i v průběhu vývoje ke kontrole, zda je vše naimplementováno, a k vykazování stavu implementace. V mém případě vypadá popis bloku nějak takto: Parametrizační tabulka (EDTs, help texty, tabulka, formulář, menu item, do menu) Členění na menší části má ještě několik dalších výhod. Zejména je jasné, co je vlastně do odhadu zahrnuto, a v případě změn lze snadno přidat/odebrat určité bloky, popř. zpětně vysledovat, jaká práce chyběla v odhadu a přesto se musela udělat. Když už víte, co všechno se bude programovat, zbývá jen udělat odhad. Na většině projektů (alespoň co mohu soudit z mé zkušenosti) je odhad číslo popisující za jak dlouho by se práce mohla stihnout. Pak se pár věcí zkomplikuje a výsledek se oproti odhadu liší i o stovky procent. Odpovědí na tento problém (a nejen na něj) je definice odhadu jako rozsahu, do kterého výsledná pracnost s vysokou pravděpodobností padne. Když jsem o tomto přístupu poprvé četl (v praxi jsem ho nikdy neviděl), nedovedl jsem si to moc představit. V praxi se ale ukázalo, že je to postup velmi přirozený a rychle se na něj zvyká. Prostě odhadnete optimistickou variantu (to je to výše zmíněné za jak dlouho se to dá stihnout) a naopak pesimistickou. Odhad pak daleko lépe popisuje, jaké situace mohou nastat a zabraňuje zaměňování odhadu za termín, kdy bude práce určitě hotova. U jednočíselných odhadů se také často projevuje tlak na jejich snížení – zde to nepředstavuje problém, protože optimistická varianta je zahrnuta, ale zároveň je zřejmé, že to skutečná pracnost bude pravděpodobně větší. Na závěr Doufám, že jsem něco málo z problematiky odhadování odhalil a ne zamlžil. Vědomě jsem pominul celou řadu důležitých věcí, třeba využívání dřívějších odhadů (a jejich úspěšnosti), ale domnívám se, že začít je třeba výše uvedeným. A pak už jen zlepšovat…

Žádné komentáře:

Okomentovat