als onderdeel van onze software estimation series, onderzochten we het belang van het beheren van verwachtingen als onderdeel van elk softwareproject. Dit artikel gaat zich richten op de cone of uncertainty, een krachtig instrument voor het beperken van de risico ‘ s die betrokken zijn bij het scoping-en schattingsproces. In de kern is het een weergave van de onzekerheid over de tijd die nodig is om een project te voltooien, gebaseerd op de hoeveelheid kennis (of het gebrek daaraan) aan het begin van een project. Het is uiteindelijk goed voor het risico dat het project uitblaast als gevolg van onbekenden, en het feit dat hoe verder in de toekomst je probeert in te schatten, hoe groter de kans dat je het mis hebt. Het is een interessante paradox waar we de toekomst nauwkeurig willen voorspellen, maar we kunnen niet echt nauwkeurig zijn omdat het slechts een schatting is.

in het geval dat u dat nog niet hebt gedaan, raad ik u aan vertrouwd te raken met een eerder experiment dat we hier bij Codebots hebben uitgevoerd om te ontdekken hoe we risico ‘ s in software het beste kunnen beheren. De motivatie voor die oefening was het frequente overoptimisme van onze software teams als het ging om het uitvoeren van schattingen.

nadat we de beste procedure hadden om een experiment voor te stellen, stelden we een probleem vast in onze vaste scope-schattingen. Elke offerte bevatte minimaal 80% variatie op het werk, ongeacht de lengte van het project. Omdat we geen cone van onzekerheid toepasten, werd ons vermogen om onze klanten te voorzien van realistische schattingen en hun verwachtingen te beheren aanzienlijk belemmerd.

Stap 1: Begrijp het probleem

zoals hierboven vermeld, ondervonden we een probleem in onze schattingen, die zich voordoen wanneer we een vaste Perimeter prijs in de citeerfase. (Vaste reikwijdte betekent het leveren van de exacte eisen gegeven, maar voor een flexibele lengte van de tijd). Ongeacht de lengte van het project, we gingen altijd over als gevolg van een grote hoeveelheid variatie.

de hoofdoorzaak-we hadden geen onzekerheidskegel. We hebben geen rekening gehouden met het feit dat hoe verder in de toekomst je probeert te voorspellen, hoe groter de toename in tijdvariantie. Dit is te wijten aan de aanwezigheid van een aantal specifieke risico ‘ s, met als ernstigste onnauwkeurige schattingen, variaties in de omvang en betrokkenheid van eindgebruikers. Omdat het allemaal in het begin werd geschat, was er geen gelegenheid om de schatting te wijzigen om rekening te houden met deze ontdekte risico ‘ s. In plaats daarvan worden de gevolgen van deze risico ‘ s verergerd over de levensduur van het project, wat betekent dat hoe langer het project, hoe meer je probeert te voorspellen, dus hoe groter de kans dat je het mis hebt.

Stap 2: Ontwikkel een hypothese

nadat we het probleem hadden verteerd, werkten we vervolgens aan de ontwikkeling van een hypothese om te testen hoe een onzekerheidsconus nauwkeurig kon worden toegepast op onze vaste scope schattingen.

hieruit werd verondersteld dat een formule kon worden gebruikt om de grootte van de Onzekerheidskegel te berekenen, gezien de lengte van een project.

Stap 3: Plan het experiment

uitgerust met onze hypothese, gingen we over tot het plannen van een experiment om onze stelling van de Onzekerheidsconus te testen. Om dit te doen, genereerden we een kwadratische functie om onze kegel te simuleren, met een parameter die het aantal voorspelde weken van ontwikkeling weergeeft. We kunnen dan deze multiplier toepassen op onze schattingen om rekening te houden met de variantie van de tijd, gebaseerd op hoe ver in de toekomst we probeerden te voorspellen.

als we dit toepassen op schattingsgegevens van eerdere projecten, konden we dan bepalen of een vaste perkamentprijs met de variatie nauwkeuriger zou zijn geweest.

Stap 4: Verzamel de gegevens

we hebben gegevens verzameld van verschillende projecten, waaronder informatie over toegewezen en genomen tijd, voltooide verhalen, tijd tot voltooiing, inclusief aanvullende opmerkingen over het project en ondervonden risico ‘ s.

aan de hand van de schattingen hebben we voor elk project een hypothetische vaste scope waarde berekend, met behulp van de onzekerheidsconus. Aan de hand van deze informatie konden we onderzoeken of de tijd die we nodig hadden om te ontwikkelen, zowel de initiële werkzaamheden als de aanvullende variaties af te ronden, vergelijkbaar was met de nieuwe schattingswaarden die werden gegenereerd met behulp van de onzekerheidsconus. Blijkt, de verbeterde schatting en de tijd eigenlijk genomen waren zeer vergelijkbaar!

Stap 5: Neem een beslissing

uiteindelijk toonden de gegevens aan dat als we de Onzekerheidsconus toepasten op een vaste scope, met behulp van een formule die rekening houdt met de lengte van een project, we zouden eindigen met een schatting die rekening zou houden met de variantie die optreedt tijdens de ontwikkeling van het project.

uiteindelijk raden we aan dat in plaats van te proberen het hele project in te schatten, een ontwikkelingsteam zich alleen richt op en een schatting maakt van een kleine hoeveelheid werk. Dit zal helpen verminderen de impact van de onbekenden, en dus de grootte van de kegel van onzekerheid. Dit betekent ook dat als het team werkt aan het project ze meer over te leren, en als het gaat om het schatten van de volgende brok van het werk, ze kunnen de onzekerheid te verminderen en meer accurate schattingen.