Som en del av vår software estimation-serie, utforsket vi viktigheten av å håndtere forventninger som en del av ethvert programvareprosjekt. Denne artikkelen skal fokusere på usikkerhetskeglen, et kraftig verktøy for å redusere risikoen som er involvert i scoping og estimeringsprosessen. Kjernen er en skildring av usikkerheten om tiden som kreves for å fullføre et prosjekt, basert på mengden kunnskap (eller mangel på det) i begynnelsen av et prosjekt. Det står til slutt for risikoen for at prosjektet blåser ut på grunn av ukjente, og det faktum at jo lenger inn i fremtiden du prøver å estimere, desto mer sannsynlig er det at du tar feil. Det er et interessant paradoks hvor vi ønsker å forutsi fremtiden nøyaktig, men vi kan ikke være nøyaktig fordi det bare er en estimering.

Hvis du ikke allerede har gjort det, anbefaler jeg at du gjør deg kjent med et tidligere eksperiment vi gjennomførte her på Codebots for å finne ut hvordan vi best kan håndtere risiko i programvare. Motivasjonen for den øvelsen var den hyppige overoptimismen fra våre programvareteam når det gjaldt å gjennomføre estimater.Etter å ha utstyrt oss med den beste prosedyren for å foreslå et eksperiment, identifiserte vi et problem i våre faste omfang estimater. Hvert sitat inneholdt minst 80% variasjon i arbeidet, uansett prosjektets lengde. Siden vi ikke brukte en kjegle av usikkerhet, ble vår evne til å gi våre kunder realistiske estimater og håndtere forventningene deres betydelig hemmet.

Trinn 1: Forstå problemet

Som nevnt ovenfor møtte vi et problem i våre estimater, som oppstår når vi gir en fast omfangspris på siteringsstadiet. (Fast omfang betyr å levere de nøyaktige kravene gitt, men for en fleksibel tidsperiode). Uansett lengden på prosjektet, vi gikk alltid over på grunn av å ha en stor mengde variasjon.

grunnårsaken-vi hadde ikke en kjegle av usikkerhet. Vi gjorde ikke rede for det faktum at jo lenger inn i fremtiden du prøver å forutsi, jo større økning i tidsavvik. Dette skyldes tilstedeværelsen av en rekke spesifikke risikoer, med de alvorligste som unøyaktige estimater, omfangsvariasjoner og sluttbrukerengasjement. Fordi det hele ble estimert i begynnelsen, var det ingen mulighet til å endre estimeringen for å ta hensyn til disse oppdagede risikoene. I stedet blir virkningen av disse risikoene forsterket over prosjektets levetid, noe som betyr at jo lengre prosjektet er, jo mer du prøver å forutsi, derfor jo mer sannsynlig er det at du tar feil.

Trinn 2: Utvikle en hypotese

Etter å ha fordøyd problemet, jobbet vi med å utvikle en hypotese for å teste hvordan en kjegle av usikkerhet kunne brukes nøyaktig på våre faste omfang estimater.fra dette ble det antatt at en formel kunne brukes til å beregne Størrelsen på Usikkerhetskeglen, gitt lengden på et prosjekt.

Trinn 3: Planlegg eksperimentet

Utstyrt med vår hypotese, fortsatte vi å planlegge et eksperiment for å teste vårt forslag om Usikkerhetskeglen. For å gjøre dette genererte vi en kvadratisk funksjon for å simulere vår kjegle, med en parameter som representerer antall forventede uker med utvikling. Vi kunne da bruke denne multiplikatoren til våre estimater for å ta hensyn til tidsavviket, basert på hvor langt inn i fremtiden vi prøvde å forutsi.

hvis vi bruker dette til estimeringsdata fra tidligere prosjekter, kan vi da avgjøre om en fast omfangspris med variasjonen ville vært mer nøyaktig.

Trinn 4: Samle inn data

vi samlet inn data fra en rekke prosjekter, inkludert informasjon om tid tildelt og tatt, historier fullført, tid til ferdigstillelse, inkludert tilleggsnotater om prosjektet og risikoer som oppstår.

Ved å ta estimatene, beregnet vi en hypotetisk fast omfangsverdi for hvert prosjekt, ved hjelp av usikkerhetskeglen. Ved hjelp av denne informasjonen kunne vi undersøke om tiden vi faktisk tok for å utvikle, fullføre både det første arbeidet og de ekstra variasjonene, var sammenlignbar med de nye estimeringsverdiene generert ved hjelp av usikkerhetskeglen. Det viser seg at den forbedrede estimeringen og tiden som faktisk ble tatt, var veldig lik!

Trinn 5: Ta en beslutning

til slutt viste dataene at hvis Vi brukte Usikkerhetskeglen til et fast omfang, ved hjelp av en formel som tar hensyn til lengden på et prosjekt, ville vi ende opp med en estimering som ville ta hensyn til variansen som oppstår over utviklingen av prosjektet.til Slutt anbefaler vi at i stedet for å prøve å estimere hele prosjektet, fokuserer et utviklingsteam bare på og anslår en liten mengde arbeid. Dette vil bidra til å redusere virkningen av de ukjente, og dermed størrelsen på kjeglen av usikkerhet. Dette betyr også at når teamet jobber med prosjektet, lærer de mer om det, og når det gjelder å estimere neste del av arbeidet, kan de redusere usikkerheten og gjøre mer nøyaktige estimater.