Agile estimeringsteknikker

Abstract

Evalueringen af arbejdsindsatsen i agile projekter er fundamentalt forskellig fra traditionelle metoder til estimering. Den traditionelle tilgang er at estimere ved hjælp af en “bottom-up”-teknik: udførligt beskrive alle krav og estimere hver enkelt opgave til at opfylde disse krav i timer/dage, og derefter bruge disse data til at udvikle projektets tidsplan. Agile projekter anvender derimod en “top-down”-tilgang, hvor der anvendes estimationsmetoder på bruttoniveau for funktionssæt, hvorefter der anvendes progressiv uddybning og rullende bølgeplanlægningsmetoder til at bore ned til opgaveniveauet på et just-in-time-grundlag, idet der iterativt afdækkes flere og flere detaljer for hvert niveau nedad. Denne artikel vil uddybe to almindelige teknikker til agil estimering (planlægningspoker og affinitetsgruppering), samt berøre, hvordan resultaterne af disse øvelser giver input til prognose af tidsplan og budget.

Top-down vs. Bottom-up

Den traditionelle metode til estimering af projekter er at bruge flere uger eller måneder i begyndelsen af et projekt på at definere de detaljerede krav til det produkt, der skal bygges. Når alle de kendte krav er blevet afdækket og dokumenteret, kan der udarbejdes et Gantt-diagram, der viser alle de opgaver, der er nødvendige for at opfylde kravene, sammen med et estimat for hver enkelt opgave. Ressourcerne kan derefter tildeles opgaverne, og handlinger som f.eks. indlæsning og nivellering er med til at fastlægge den endelige leveringsdato og det endelige budget. Denne proces er kendt som en bottom-up-metode, da alle detaljer vedrørende produktet skal defineres, før projektets tidsplan og omkostninger kan estimeres.

I softwareindustrien har brugen af bottom-up-metoden alvorlige ulemper på grund af den hastighed, hvormed forandringerne sker i dag. Forandringshastighed betyder, at hastigheden af nye udviklingsværktøjer og hastigheden af adgangen til ny viden er så stor, at enhver forsinkelse i leveringen gør en åben over for konkurrerende alternativer og i fare for at levere et forældet produkt (Sliger, 2010).

Top-down-metoden løser dette vigtige problem ved at bruge de oplysninger, der er tilgængelige på nuværende tidspunkt, til at give estimater på bruttoniveau. Derefter anvendes rullende bølgeplanlægning til at indarbejde nye oplysninger, efterhånden som de bliver kendt, hvorved estimaterne forfines yderligere og iterativt udarbejdes med flere detaljer, efterhånden som projektet skrider frem. Denne metode, hvor man lærer lige nok til at komme i gang med en plan for at indarbejde mere viden, efterhånden som arbejdsresultaterne udvikler sig, gør det muligt for projektteamet at reagere hurtigt på modgang og skiftende markedsefterspørgsel.

Vurderingsteknikker

Gross-level estimation techniques are in use by teams using agile approaches such as Scrum and Extreme Programming, and this paper will cover two of the most popular techniques: Planning Poker og Affinity Grouping. De anvendte estimeringsenheder vil også blive undersøgt, da disse enheder bør være af en sådan art, at de ikke kan forveksles med tid.

Planlægningspoker

Den mest populære teknik til estimering på bruttoniveau er Planning Poker, eller brugen af Fibonacci-sekvensen til at tildele en pointværdi til en funktion eller et element (Grenning, 2002). Fibonacci-sekvensen er en matematisk talrække, der blev introduceret i det 13. århundrede og brugt til at forklare visse formative aspekter af naturen, f.eks. træernes forgrening. Serien genereres ved at lægge de to foregående tal sammen for at få den næste værdi i sekvensen: 0, 1, 1, 1, 2, 3, 5, 8, 13, 21 og så videre. Med henblik på agil estimering er nogle af tallene blevet ændret, hvilket resulterer i følgende serie: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Disse tal er repræsenteret i et sæt spillekort (se bilag 1). Holdmedlemmerne spiller “planlægningspoker” (bilag 2) for at give et skøn i form af en pointværdi for hvert element. Her er trinene:

• Hvert teammedlem får et sæt kort.
• Forretningsejeren (som IKKE får lov til at estimere) præsenterer det punkt, der skal estimeres.
• Punktet diskuteres.
• Hvert teammedlem vælger privat et kort, der repræsenterer hans/hendes estimat.
• Når alle er klar, afsløres alle udvalgte kort på samme tid.
• Hvis alle teammedlemmer har valgt det samme kort, er den pågældende pointværdi estimatet.
• Hvis kortene ikke er ens, diskuterer teamet estimatet med vægt på de yderlige værdier:
  • Det medlem, der har valgt den laveste værdi, forklarer, hvorfor han/hun har valgt værdien.
  • Det medlem, der har valgt den højeste værdi, forklarer, hvorfor han/hun har valgt værdien.
• Vælg igen, indtil estimaterne konvergerer.
• Hvis der opstår langvarige eller “i-nu-hviske”-samtaler, kan teammedlemmerne bruge en timer på to minutter til at timeboxe diskussionen og vælge igen, hver gang timeren løber ud, indtil der sker en konvertering.
• Gentag det samme for hvert punkt (Cohn, 2006, s. 56-57).

Der er flere grunde til, at Fibonacci-tallene bruges, og at de bruges i dette format. Den første er forestillingen om, at når først teams eliminerer tid som estimatgrundlag, er de mindre tilbøjelige til at kræve flere detaljer og fylde estimater op. Disse tal repræsenterer i stedet den relative størrelse, ikke tiden. Som følge heraf går estimationsøvelsen ret hurtigt. Holdene bruger generelt ca. to minutter på hvert punkt, hvilket betyder, at en backlog på 30 punkter kan estimeres på en time. Det faktum, at holdene kun har 9 valgmuligheder (dvs. pointværdier eller kort), er også med til at fremskynde processen.

Sekvensen giver også det rette detaljeringsniveau for mindre og bedre forståede funktioner, samtidig med at man undgår en falsk følelse af nøjagtighed for højere estimater. F.eks. betyder et element med et højt estimat (20 eller højere), at elementet er stort og endnu ikke godt forstået. Det ville være spild af tid at diskutere, om elementet var en 20, 19 eller 22, da der simpelthen ikke er nok data til rådighed. Når punktet kommer tættere på den iteration, hvor der skal arbejdes med punktet, kan det opdeles i mindre stykker og estimeres i mere granulære tal (1-13). Elementer med punktestimater fra 1-13 kan generelt gennemføres inden for en enkelt iteration (1-4 uger).

Det er vigtigt at bemærke, at point ikke har samme betydning på tværs af teams; f.eks. er et teams “fem” ikke lig med et andet teams “fem”. Derfor bør teamets hastighed, som er afledt af point, ikke bruges til at sammenligne produktivitet på tværs af teams.

Affinitetsgruppering

En endnu hurtigere måde at estimere på, og en måde, der bruges, når antallet af elementer, der skal estimeres, er affinitetsgruppering. Teammedlemmer grupperer simpelthen emner af samme størrelse sammen, hvilket resulterer i en konfiguration, der ligner den i figur 3. Metoden er enkel og hurtig:

• Den første genstand læses op for holdmedlemmerne og placeres på væggen.
• Den anden genstand læses op, og holdet bliver spurgt, om den er mindre eller større end den første genstand; placeringen på væggen svarer til holdets svar (større er til højre, mindre er til venstre).
• Den tredje genstand læses op, og holdet spørges, om den er mindre eller større end den første og/eller anden genstand; genstanden placeres tilsvarende på væggen.
• Kontrollen overdrages derefter til holdet, som skal afslutte affinitetsgrupperingen for resten af genstandene.

Holdene kan vælge at fortsætte på samme måde og placere en genstand ad gangen på væggen efter gruppediskussionen. En hurtigere måde er dog at lade hvert holdmedlem vælge et emne og placere det ud fra deres egen bedste forståelse. Dette gøres med alle holdmedlemmer, der arbejder parallelt, indtil alle elementer er blevet vurderet og placeret på væggen. Flere hundrede elementer kan vurderes på relativt kort tid. Når alle elementer er anbragt på væggen, gennemgår teamet grupperingerne. Genstande, som et teammedlem mener er i den forkerte gruppe, diskuteres og flyttes om nødvendigt.

Når affinitetsgrupperingen er afsluttet, kan der tildeles værdier for estimeringsenheder, f.eks. point. I bilag 3 vil det første sæt yderst til venstre blive mærket med en værdi på 1 point, det andet sæt vil få en værdi på 2 point, det tredje sæt 3 point, det fjerde sæt 5 point og det sidste sæt 8 point.

Affinitetsgruppering kan også foretages for andre estimeringsenheder, f.eks. T-shirtstørrelser. Bilag 4 viser et eksempel på affinitetsgrupperede elementer, der er mærket med T-shirt-størrelser i stedet for point.

Stimeringsenheder

Brugen af T-shirt-størrelser (ekstra lille , lille , mellem , stor , ekstra stor ) er en anden måde at tænke på relative størrelser af funktioner på. Dette er en endnu større afvigelse fra det numeriske system, og som alle gode skønsenheder på bruttoniveau kan de på ingen måde forbindes med en bestemt tidslængde.

Andre vilkårlige måleenheder omfatter gummibamser, NUTS (Nebulous Units of Time) og foot-pounds. Teams kan skabe deres egne estimeringsenheder, og som du kan se, har de ofte lidt sjov ved at gøre det.

Dette dokument dækker ikke brugen af tidsbaserede enheder som f.eks. ideelle udviklingsdage og/eller timer. Disse er allerede almindelige og velforståede, så deres forklaringer blev ikke medtaget. Det er dog værd at bemærke, at skøn på bruttoniveau har potentiale til at være mere vellykket, når de er afkoblet fra tidsbegrebet. Da tidsestimater ofte bliver omsat til forpligtelser af ledelsen og forretningen, føler teammedlemmerne et større pres for at være så nøjagtige som muligt. Som følge heraf anmoder de om flere og flere detaljer om det emne, der skal estimeres. Dette forvandler estimater på bruttoniveau til mere tidskrævende estimater på detaljeniveau og ødelægger den oprindelige hensigt og det oprindelige formål.

Forecasting Schedule and Budget

Når estimater på bruttoniveau og teamets hastighed er fastlagt, kan tidsplan og budget forudsiges. Teams bestemmer deres hastighed ved at lægge det samlede antal point sammen for alle de elementer, de har afsluttet i en iteration. Et team kan f.eks. have udvalgt fem elementer med en samlet pointværdi på 23 point (se bilag 5). Ved slutningen af deres to ugers iteration var de kun i stand til at færdiggøre fire af de fem punkter. Deres hastighed er 15, eller summen af pointværdierne for punkterne 1-4. Hold får ikke “delvis kredit” for at fuldføre dele af et punkt, så selv hvis de var begyndt på punkt 5, ville det ikke tælle, da det ikke blev fuldført.

Bestemmelse af tidsplanen

Et holds gennemsnitlige hastighed bruges til at forudsige en langsigtet tidsplan. Gennemsnitshastigheden beregnes ved at summere hastighedsmålingerne fra holdets sidste tre iterationer og dividere den samlede hastighed med tre. Så hvis et hold gennemførte 15 point i sin første iteration og 20 point i hver af de to efterfølgende iterationer, er holdets gennemsnitshastighed 18 (15+20+20+20 / 3). Hvis et team i gennemsnit kan udføre 18 punkter i en iteration, og der er 144 punkter, som skal udføres i projektet, vil det tage teamet otte iterationer at udføre arbejdet (144 / 18). Hvis hver iteration varer to uger, er den forventede færdiggørelse 16 uger. Denne metode giver os mulighed for at besvare spørgsmålet: “Hvornår er vi færdige med alt dette arbejde?”

Hvis teamet har en track record af hastighedsdata, er det muligt at bestemme den mest optimistiske færdiggørelsesdato, den mest pessimistiske og den mest sandsynlige. Holdets gennemsnitlige hastighedstal bruges til at beregne det mest sandsynlige scenarie, mens hastighedstallene fra holdets dårligst præsterende iterationer bruges til at beregne den mest pessimistiske forventede færdiggørelsesdato. Ved at bruge hastigheden fra iterationer, hvor teamet var i stand til at færdiggøre mere end forventet, fås den mest optimistiske prognose.

Vi kan også bruge disse tal til at besvare spørgsmålet: “Vi skal levere noget inden denne dato – hvor mange af disse funktioner vil vi have færdiggjort til den tid?” Se bilag 6 for et eksempel på den mest sandsynlige mængde, der forventes at blive færdiggjort, den pessimistiske prognose og den optimistiske prognose. Eksemplet er for et team, hvis gennemsnitlige hastighed er 20, og som har en hastighed med den dårligste præstation på 12 og en hastighed med den bedste præstation på 25. I betragtning af dette og kun seks uger (tre iterationer), hvor meget kan der så færdiggøres? Den pessimistiske prognose er, at kun punkterne 1-8 vil blive udført på seks uger. Den optimistiske prognose er, at punkterne 1-18 vil blive gennemført. Og den mest sandsynlige prognose, baseret på holdets gennemsnitlige hastighed på 20, er, at punkterne 1-13 vil blive afsluttet på seks uger.

Hvis holdene anvender ikke-numeriske estimeringsenheder som f.eks. t-shirtstørrelser, vil algoritmerne til prognoser være mere komplekse. Det anbefales, at størrelserne konverteres til et numerisk system for lettere at generere lignende data. F.eks. kan en Small konverteres til en NUT på 3, en Medium til en NUT på 5 osv. De kan også konverteres til tidsintervaller (en Small kan f.eks. være 1-3 dage), men dette er i sig selv risikabelt på grund af de problemer, der allerede er nævnt i afsnittet om skønsenheder.

Bestemmelse af budget

I dette afsnit ser vi på svaret på: “Vi har kun så mange penge – hvor længe vil de holde, og hvor meget vil vi have lavet, før vi løber tør?” Først bruges en simpel formel til at bestemme omkostningerne pr. point:

Σ (loaded teamets lønninger for periode n) / point afsluttet i periode n

Tag summen af teamets lønninger (loaded) for en periode, f.eks. tre to ugers iterationer, og divider den med antallet af point, som teamet har afsluttet i samme tidsramme. Så et hold, hvis samlede lønninger (loaded) er 240.000 dollars over seks uger, og som har udført 60 punkter arbejde i disse tre iterationer, vil have en omkostning pr. punkt på 4.000 dollars. Brug nu følgende formel til at bestemme budgettet:

(Omkostninger pr. point x den samlede pointværdi af de punkter, der skal færdiggøres) + andre udgifter = forventet budget

Som oftest er ikke alle funktioner til et produkt defineret i starten af et projekt, hvilket er som forventet for agile projekter. Så budgetoverslagene er baseret på det, vi ved i dag, plus en prognosealgoritme, der er baseret på historiske data eller ekspertvejledning. Lad os f.eks. sige, at der indtil videre kun er opført 20 funktioner, men at virksomheden ikke vil være i stand til at komme med yderligere anmodninger om funktioner eller forbedringer, før vi har set, hvordan den første version modtages af kunden. Budgettet for projektet, som er planlagt til tre udgivelser, vil kun have prognosedata til rådighed for den første udgivelse og ikke for hele projektet. Teamet kan bruge algoritmen ovenfor til at forudsige budgettet for den første udgivelse og derefter antage yderligere 20 % for den anden udgivelse og yderligere 5 % for den sidste udgivelse baseret på tidligere erfaringer.

Ligevel som hastighed revideres budget- og tidsplanprognoser ved hver iteration. Dette er en del af den rullende bølgeplanlægningsproces, som agile projekter tilslutter sig.

Slutord

Den manglende strukturerede estimeringsteknik, der anvendes i lean-tilgange som Kanban, er ikke dækket i denne artikel. I stedet for at bruge (spild) tid på at estimere elementer, beregnes de gennemsnitlige cyklus- og gennemsnitstider på grundlag af teamets faktiske gennemløbsrater. Kanban anvender det matematiske teorem Little’s Law som grundlag for deres formler. Ved hjælp af beregninger af gennemløbstider, der er afledt af kumulative flowdiagrammer, kan teams forudsige projekttidsplaner uden at bruge tid på forhånd på at udarbejde overslag. Læseren opfordres til at foretage selvstændig forskning om dette emne, som kunne udgøre en separat artikel i sig selv.

Agile projekter har til formål at levere et produkt eller produktinkrementer tidligt og ofte for at kunne indarbejde kundefeedback og andre erfaringer i den næste udgave. Ved at bruge mere tid på at eksperimentere, udføre og lære og mindre tid på spekulationer reduceres leveringscyklustiden. Agile teams er bedre i stand til at konkurrere på markedet og holde trit med den stadigt stigende hastighed af forandringer.