Steve McConnell – Odhadování softwarových projektů

Tak po té spoustě let, kdy se snažím co nejlépe odhadnout kolik práce by který projekt mohl být a jak to nacenit zákazníkovi jsem se konečně dostal ke knížce, která by mě to měla naučit. A po pravdě řečeno nevím, zda jsem ji úplně pochopil.

Pravdou je, že většina mých projektů asi nikdy nespadala do správných škatulek a i v knize se neustále opakuje, že opravdu velké projekty se odhadují ještě jinak. Hned na začátku je napsáno, že odhady podle počtu řádků kódů nejsou úplně to pravé, ale celou knihou se nese dělení projektů právě podle řádků. Takže vím, že existuje chyba velikosti a nárůst práce není rovnoměrný.

Pak je důležité rozlišovat mezi odhadem (kolik to asi bude práce), cílem (co je naším cílem) a závazkem (a k čemu jsme se zavázali). Nelze měnit odhady bez změny vstupních parametrů, mohou se měnit závazky. Naprosto neskutečný byl hned test na odhady, deset nesmyslných otázek a člověk je měl odhadnout s 90% pravděpodobností a podle výsledků prý většina lidí použije tak malé rozsahy odhadů, že se trefí přibližně ve 30%. Jinak odhady by se vždy měly dávat jako rozsah, nikdy jako jedno číslo (co by zákazníci na takové nabídky říkali?).

Spousta různých metodik a návodů jak to odhadovat (spoustu z nich jsem nepochytil nebo by je člověk díky množství parametrů musel používat každý den) a ty by se prý měly při odhadování kombinovat, respektive odhadnout každou věc několika metodikami, porovnat a z toho vyjde nejpřesnější výsledek.

Pokud je něco možné spočítat tak to máte spočítat, pak případně kalkulovat (to je když vycházíte z historických dat) a nakonec usuzovat (poměr k něčemu například). Historická data jsou hrozně důležitá, měli byste je sbírat u každého projektu a všude je sbírat stejně, abyste nemíchali hrušky s jabkama.

Úsudky expertů, dekompozice, analogie, zástupci, softwarové nástroje (třeba zdarma Construx Estimate), funkční celky, Jonesova metoda,  jsou dalšími možnými přístupy k odhadování.

Nejvíce se mi ale líbila metoda triček pro diskutování se zákazníkem. Dodavatel každou vlastnost ohodnotí „velikostí“ (S, M, L) podle množství práce a zákazník zase podle důležitosti. Pak se to srovná, ty, které jsou velikostně OK jsou v pohodě, o těch dalších se diskutuje tím víc, čím větší je rozdíl. Fakt super nápad.

Nakonec pár čísel (která jsem úplně nepochopil, protože se objevovaly postupně v dalších a dalších tabulkách a nikdy mi nedaly dohromady 100%) – návrh architektury by měl činit 10 – 20% projektu, vývoj 40 – 70%, systémové testování 20 – 40%, navýšení na dodělky 5 – 10%, projektové vedení 10 – 20% a specifikace požadavků 4 – 8%.

Poměr vývojáři – testeři se pohybuje od 20:1 (často bez testerů úplně) až po 1:10 (pokud navrhujete raketoplán pro NASA). S tím, že běžné interní obchodní systémy jsou těch 20:1 po 3:1.

Největší procento chyb se odstraní vysokokapacitním beta testováním (více jak 1000 testerů), použitím prototypů (aneb RAD se vyplatí), formální inspekcí kódu, osobní kontrolou kódu a pak to klesá a asi nejméně zachytí regresivní testování (fakt netuším, co to spojení znamená).

Berte v úvahu 1% – 4% nárůst požadavků za měsíc, při přechodu z vývoje v jedné firmě na vývoj ve více firmách přidejte 25% práce a při přechodu z jedné firmy na mezinárodní outsourcing až 40% práce navíc. 20% – 40% také přidává vývoj v novém jazyku či s novými nástroji nebo v novém prostředí (myšleno obchodním, tedy typ aplikace). Administrativa spotřebuje 5% – 10%.

Ve finále je kapitola jak prezentovat odhady a když jsem si ji přečetl tak jsem získal pocit, že je tam napsáno takové alibi (všichni budou pracovat na 100%, nebudou nemocní, nebudou dodatečné úpravy, …), že v podstatě za nic neručím a uvidí se co dodáme. Mám pocit, že by mě vynesli v zubech.

Komunikace mezi manažery a techniky nikdy nemůžeme v tomhle úplně fungovat – manažeři jsou zvyklí smlouvat a snižovat odhady, technici to moc nechápou a neumí hlavně vyjednávat, takže vždycky mají pocit, že je pěkně okrouhli. Takže musíte říct, že odhad se nezmění dokud nezmění vstupní podmínky, že jste ochotni diskutovat o závazcích a pak to prý manažeři mohou pochopit. Zaměřte se na zájmy toho druhého, nehajte jen svou pozici. Ptejte se, proč to ten druhý potřebuje dřív/levněji a přemýšlejte, jak mu s tím pomoci, netrvejte na svém později/dráže.

K tomu všemu spousta tipů v bublinách, určitě to bylo zajímavé na zamyšlení. Pokud chcete, tak si počtěte taky buď v češtině nebo angličtině (snad je to ona).