som en del av vår mjukvaruuppskattningsserie undersökte vi vikten av att hantera förväntningar som en del av något mjukvaruprojekt. Denna artikel kommer att fokusera på cone of uncertainty, ett kraftfullt verktyg för att mildra riskerna i scoping och uppskattningsprocessen. Kärnan är en skildring av osäkerheten om den tid som krävs för att slutföra ett projekt, baserat på mängden kunskap (eller brist på det) i början av ett projekt. Det står slutligen för risken för att projektet blåser ut på grund av okända, och det faktum att ju längre in i framtiden du försöker uppskatta, desto mer sannolikt är det att du har fel. Det är en intressant paradox där vi vill förutsäga framtiden exakt, men vi kan inte riktigt vara korrekta eftersom det bara är en uppskattning.

om du inte redan har gjort det rekommenderar jag att du bekantar dig med ett tidigare experiment som vi genomförde här på Codebots för att upptäcka hur vi bäst kan hantera risker i programvara. Motivationen för den övningen var den frekventa överoptimismen från våra mjukvaruteam när det gällde att göra uppskattningar.

Efter att ha utrustat oss med det bästa förfarandet för att föreslå ett experiment identifierade vi ett problem i våra uppskattningar av fast omfattning. Varje offert innehöll minst 80% variation till det utförda arbetet, oavsett projektets längd. Eftersom vi inte tillämpade en kon av osäkerhet hindrades vår förmåga att ge våra kunder realistiska uppskattningar och hantera deras förväntningar avsevärt.

Steg 1: Förstå problemet

Som nämnts ovan stötte vi på ett problem i våra uppskattningar, som uppstod när vi tillhandahåller ett fast omfångspris vid offertstadiet. (Fast räckvidd betyder att leverera de exakta kraven, men under en flexibel tid). Oavsett projektets längd gick vi alltid över på grund av att vi hade en stor variation.

grundorsaken-vi hade inte en kon av osäkerhet. Vi tog inte hänsyn till det faktum att ju längre in i framtiden du försöker förutsäga, desto större är ökningen av tidsvariansen. Detta beror på förekomsten av ett antal specifika risker, varav de allvarligaste är felaktiga uppskattningar, omfattningsvariationer och slutanvändarnas engagemang. Eftersom allt uppskattades i början fanns det ingen möjlighet att ändra uppskattningen för att ta hänsyn till dessa upptäckta risker. Istället förvärras effekterna av dessa risker under projektets livstid, vilket betyder att ju längre projektet är, desto mer försöker du förutsäga, desto mer sannolikt är det att du har fel.

steg 2: Utveckla en hypotes

Efter att ha smält problemet arbetade vi nästa gång med att utveckla en hypotes för att testa hur en osäkerhetskon kan tillämpas exakt på våra uppskattningar av fast omfattning.

från detta antogs att en formel kunde användas för att beräkna storleken på Osäkerhetskonen, med tanke på längden på ett projekt.

steg 3: Planera experimentet

utrustad med Vår hypotes fortsatte vi att planera ett experiment för att testa vårt förslag om Osäkerhetskonen. För att göra detta genererade vi en kvadratisk funktion för att simulera vår kon, med en parameter som representerar antalet förutsagda utvecklingsveckor. Vi kunde då tillämpa denna multiplikator på våra uppskattningar för att ta hänsyn till tidsvariationen, baserat på hur långt in i framtiden vi försökte förutsäga.

om vi tillämpar detta på uppskattningsdata från tidigare projekt kan vi sedan avgöra om ett fast omfång med variationen skulle ha varit mer exakt.

steg 4: Samla in data

Vi samlade in data från en mängd olika projekt, inklusive information om tid som tilldelats och tagits, berättelser slutförda, tid fram till slutförandet, inklusive ytterligare anteckningar om projektet och risker som uppstått.

med uppskattningarna beräknade vi ett hypotetiskt fast scope-värde för varje projekt med hjälp av osäkerhetskonen. Med hjälp av denna information kunde vi undersöka om den tid som vi faktiskt tog att utveckla, avslutade både det ursprungliga arbetet och de ytterligare variationerna, var jämförbar med de nya uppskattningsvärdena som genererades med hjälp av osäkerhetskonen. Visar sig, den förbättrade uppskattningen och den tid som faktiskt togs var mycket lika!

Steg 5: Fatta ett beslut

i slutändan visade data att om vi tillämpade Osäkerhetskonen på ett fast omfång, med hjälp av en formel som tar hänsyn till projektets längd, skulle vi sluta med en uppskattning som skulle ta hänsyn till variansen som uppstår över projektets utveckling.

i slutändan rekommenderar vi att snarare än att försöka uppskatta hela projektet, fokuserar ett utvecklingsteam bara på och uppskattar en liten mängd arbete. Detta kommer att bidra till att minska effekterna av de okända, och därmed storleken på osäkerhetskonen. Detta innebär också att när teamet arbetar med projektet lär de sig mer om det, och när det gäller att uppskatta nästa del av arbetet kan de minska osäkerheten och göra mer exakta uppskattningar.