v rámci naší řady odhadů softwaru jsme zkoumali důležitost správy očekávání jako součást jakéhokoli softwarového projektu. Tento článek se zaměří na kužel nejistoty, mocný nástroj pro zmírnění rizik spojených s rozsahem a odhadem. V jádru je to zobrazení nejistoty ohledně času potřebného k dokončení projektu na základě množství znalostí (nebo jejich nedostatku) na začátku projektu. To v konečném důsledku představuje pro riziko projektu foukání vzhledem k neznámé, a skutečnost, že čím dále do budoucnosti, můžete zkusit odhadnout, tím je pravděpodobnější, že bude špatné. Je to zajímavý paradox, kdy chceme předpovídat budoucnost přesně, ale nemůžeme být pravdivě přesní, protože je to pouze odhad.

V případě, že jste tak ještě neučinili, doporučuji, abyste se seznámili s předchozím experimentu jsme provedli tady na Codebots zjistit, jak můžeme nejlépe spravovat rizika v software. Motivací pro toto cvičení byl častý nadměrný optimismus našich softwarových týmů, pokud jde o provádění odhadů.

Poté, vybavená sebe s nejlepší postup, jak navrhnout experiment, jsme identifikovali problém v naší pevný rozsah odhady. Každá nabídka obsahovala minimálně 80% odchylku od provedené práce, bez ohledu na délku projektu. Protože jsme nepoužili kužel nejistoty, naše schopnost poskytovat našim zákazníkům realistické odhady a řídit jejich očekávání byla výrazně omezena.

Krok 1: Porozumět problému

Jak bylo uvedeno výše, jsme narazili na problém v našich odhadů, vyskytující se, když jsme se poskytnout pevný rozsah cena v citování fázi. (Pevný rozsah, což znamená poskytování přesných požadavků, ale na flexibilní dobu). Bez ohledu na délku projektu, vždy jsme přešli kvůli velkému množství variací.

hlavní příčina – neměli jsme kužel nejistoty. Nezohlednili jsme skutečnost, že čím dále do budoucnosti se pokusíte předpovědět, tím větší je nárůst časového rozptylu. To je způsobeno přítomností řady specifických rizik, přičemž nejzávažnějšími jsou nepřesné odhady, variace rozsahu a zapojení koncových uživatelů. Protože to všechno bylo odhadnuto na začátku, neexistovala možnost změnit odhad tak, aby zohledňoval tato zjištěná rizika. Místo toho, dopad tato rizika jsou prohlubována v průběhu trvání projektu, což znamená, čím delší je projekt, tím více se budete snažit předvídat, a proto více pravděpodobné, že jste se mýlil.

Krok 2: Vytvořit hypotézu

S stravitelné problému, dále jsme pracovali na rozvoji hypotézu otestovat, jak kužel nejistoty by mohlo být přesně aplikovat na náš pevný rozsah odhady.

z toho se předpokládalo, že vzorec by mohl být použit pro výpočet velikosti kužele nejistoty, vzhledem k délce projektu.

Krok 3: Naplánujte experiment

vybaveni naší hypotézou jsme přistoupili k plánování experimentu, abychom otestovali náš návrh kužele nejistoty. Za tímto účelem jsme vygenerovali kvadratickou funkci pro simulaci našeho kužele s parametrem představujícím počet předpovězených týdnů vývoje. Můžeme pak použít tento multiplikátor našich odhadů zohlednit časový rozptyl, na základě toho, jak daleko do budoucnosti, jsme se snažili předvídat.

Pokud použijeme pro odhad údajů z předchozích projektů, můžeme pak určit, zda pevný rozsah cena s variací by bylo přesnější.

Krok 4: Sbírat údaje

shromáždili Jsme data z různých projektů, včetně informací o čase, přidělených a přijatých, příběhy úspěšně absolvováno, čas do ukončení, včetně další poznámky k projektu a rizikům.

při odhadu jsme vypočítali hypotetickou hodnotu pevného rozsahu pro každý projekt pomocí kužele nejistoty. S použitím této informace jsme byly schopni posoudit, zda čas, který jsme vlastně vzal rozvíjet, dokončovací jak původní práce a další varianty, byla srovnatelná s novou odhad hodnoty generované pomocí kužel nejistoty. Ukázalo se, že vylepšený odhad a čas, který skutečně trvalo, byly velmi podobné!

Krok 5: Učinit rozhodnutí

nakonec, tato data ukázala, že pokud bychom použili Kužel Nejistoty na pevný rozsah, pomocí vzorce, který bere v úvahu délku projektu, bychom skončit s odhad, který by vzal v úvahu odchylku, která se vyskytuje v průběhu vývoje projektu.

nakonec doporučujeme, aby se vývojový tým místo toho, aby se snažil odhadnout celý projekt, zaměřil pouze na malé množství práce a odhadl je. To pomůže snížit dopad neznámých, a tím i velikost kužele nejistoty. To také znamená, že když tým pracuje na projektu, dozví se o něm více, a pokud jde o odhad dalšího kusu práce, mohou snížit nejistotu a provést přesnější odhady.