som en del af vores programestimeringsserie undersøgte vi vigtigheden af at styre forventningerne som en del af ethvert programprojekt. Denne artikel vil fokusere på usikkerhedskeglen, et kraftfuldt værktøj til at afbøde de risici, der er involveret i scoping-og estimeringsprocessen. Kernen er en skildring af usikkerheden om den tid, der kræves for at gennemføre et projekt, baseret på mængden af viden (eller mangel på samme) i starten af et projekt. Det tegner sig i sidste ende for risikoen for, at projektet blæser ud på grund af ukendte, og det faktum, at jo længere ind i fremtiden du prøver at estimere, jo mere sandsynligt er det, at du tager fejl. Det er et interessant paradoks, hvor vi ønsker at forudsige fremtiden nøjagtigt, men vi kan ikke virkelig være nøjagtige, fordi det kun er et skøn.

Hvis du ikke allerede har gjort det, vil jeg anbefale, at du gør dig bekendt med et tidligere eksperiment, vi udførte her på Codebots for at finde ud af, hvordan vi bedst kunne styre risici i programmer. Motivationen for denne øvelse var den hyppige overoptimisme fra vores programmelhold, når det gjaldt at foretage estimater.

efter at have udstyret os med den bedste procedure til at foreslå et eksperiment, identificerede vi et problem i vores estimater af fast omfang. Hvert tilbud indeholdt mindst 80% variation i det udførte arbejde, uanset projektets længde. Da vi ikke anvendte en kegle af usikkerhed, blev vores evne til at give vores kunder realistiske skøn og styre deres forventninger betydeligt hæmmet.

Trin 1: Forstå problemet

Som nævnt ovenfor stødte vi på et problem i vores estimater, der opstod, når vi leverer en fast omfangspris på citeringsfasen. (Fast anvendelsesområde betyder at levere de nøjagtige krav, men i en fleksibel periode). Uanset projektets længde gik vi altid over på grund af at have en stor variation.

grundårsagen-vi havde ikke en kegle af usikkerhed. Vi redegjorde ikke for det faktum, at jo længere ind i fremtiden du prøver at forudsige, jo større er stigningen i tidsvarians. Dette skyldes tilstedeværelsen af en række specifikke risici, hvor de mest alvorlige er unøjagtige skøn, omfangsvariationer og slutbrugerengagement. Fordi det hele blev estimeret i begyndelsen, var der ingen mulighed for at ændre estimeringen for at tage højde for disse opdagede risici. I stedet forstærkes virkningen af disse risici i løbet af projektets levetid, hvilket betyder, at jo længere projektet er, jo mere prøver du at forudsige, jo mere sandsynligt er det, at du tager fejl.

Trin 2: Udvikle en hypotese

efter at have fordøjet problemet arbejdede vi næste gang med at udvikle en hypotese for at teste, hvordan en kegle af usikkerhed kunne anvendes nøjagtigt på vores estimater af fast omfang.

ud fra dette blev det antaget, at en formel kunne bruges til at beregne størrelsen på Usikkerhedskeglen i betragtning af længden af et projekt.

Trin 3: Planlæg eksperimentet

udstyret med vores hypotese fortsatte vi med at planlægge et eksperiment for at teste vores forslag om Usikkerhedskeglen. For at gøre dette genererede vi en kvadratisk funktion til at simulere vores kegle med en parameter, der repræsenterer antallet af forudsagte ugers udvikling. Vi kunne derefter anvende denne multiplikator på vores estimater for at tage højde for tidsvariansen, baseret på hvor langt ind i fremtiden Vi forsøgte at forudsige.

Hvis vi anvender dette på estimeringsdata fra tidligere projekter, kunne vi derefter afgøre, om en fast omfangspris med variationen ville have været mere nøjagtig.

Trin 4: Indsamle data

Vi indsamlede data fra en række projekter, herunder oplysninger om tid tildelt og taget, historier afsluttet, tid indtil færdiggørelse, herunder yderligere noter om projektet og risici.

under estimaterne beregnede vi en hypotetisk fast omfangsværdi for hvert projekt ved hjælp af usikkerhedskeglen. Ved hjælp af disse oplysninger var vi i stand til at undersøge, om den tid, vi faktisk tog at udvikle, afslutte både det indledende arbejde og de yderligere variationer, var sammenlignelig med de nye estimeringsværdier, der blev genereret ved hjælp af usikkerhedskeglen. Viser sig, den forbedrede estimering og den tid, der faktisk blev taget, var meget ens!

Trin 5: Tag en beslutning

i sidste ende viste dataene, at hvis vi anvendte Usikkerhedskeglen på et fast omfang ved hjælp af en formel, der tager højde for længden af et projekt, ville vi ende med et estimat, der ville tage højde for variansen, der opstår over projektets udvikling.

i sidste ende anbefaler vi, at et udviklingsteam i stedet for at forsøge at estimere hele projektet kun fokuserer på og estimerer en lille mængde arbejde. Dette vil medvirke til at reducere virkningen af de ukendte, og derfor størrelsen af usikkerhedens kegle. Dette betyder også, at når teamet arbejder på projektet, lærer de mere om det, og når det kommer til at estimere den næste del af arbejdet, kan de reducere usikkerheden og foretage mere nøjagtige skøn.