Estimering – en spildt kunst?

Estimering af opgaver i softwareudvikling ses af mange som et nødvendigt onde. Men er det nødvendigt? Er vi overhovedet dygtige nok til at estimere til at denne øvelse giver værdi?

Yderpunkterne i denne diskussion er defineret af to lejre.

Lejren som mener at der aldrig må blive udført uestimeret arbejde. Hvordan ved vi ellers at arbejdets værdi overstiger omkostningen? Og hvis ikke det er forretningsværdi-brillerne som der bliver set igennem, kan det i stedet være de organisatoriske: Hvordan ved vi hvad vi kan nå at lave indenfor deadlinen og hvor mange folk vi skal smide efter opgaven, hvis ikke vi har estimater at læne os op af?

I den anden lejr kan man finde dem som mener at estimering er en tidskrævende, værdiløs aktivitet. Estimeringen gør intet for det endelige produkt og da vi altid arbejder så hurtigt vi kan med en fast vision af det færdige produkt, så hjælper estimater ingen steder, men spilder bare værdifuld arbejdstid. Estimater er alligevel ubrugelige – hvornår holder de overhovedet? Måske er estimater direkte skadelige? Laver vi bare estimaterne for estimaternes skyld?

Begge lejre har gode argumenter på deres side, som man som professionel softwareudvikler bør kende lidt til. De fleste organisationer placerer sig et sted på skalaen mellem de to yderpunkter.

Forecasting er en typisk forretnings-aktivitet. Her bruges typisk historiske data, viden om organisationen, estimering af arbejdet og risici til at forudsige tidshorisont, omfang og pris på en eller flere arbejdsopgaver. Forecasting bruges f.eks. til at svare på om det overhovedet kan betale sig at give os i kast med arbejdet, om vi har nok folk til at påtage os opgaven og om vi når vores deadline. For nogen er disse ting skrevet i sten allerede, hvilket gør forecasting til en mindre værdifuld aktivitet. Det er f.eks. når teamet der skal udføre opgaven er en statisk størrelse, når forretningen allerede har bestemt at arbejdet skal udføres uanset hvad og når vi ikke har en deadline at forholde os til og ikke har tænkt os at sætte en.

For at sige det på en anden måde: Forecasting skal bruges til at drive handling, hvad enten det er at forventningsafstemme, ændre bemandingen, ændre deadlinen, ændre scopet eller måske endda droppe arbejdsopgaven. Hvis ikke forecasting driver handling eller bekræfter os i vores antagelser, så er det en værdiløs aktivitet. Hvis vi rent faktisk får justeret skibet i tide på grund af estimering, så giver det værdi – vi skal dog bare huske at estimater er gæt (ikke løfter) og måske justerer vi færgens kurs på for tyndt et grundlag.

Typiske problemstillinger i estimering

Hvis du har tænkt dig at estimere er der både noget du bliver opfordret til at huske på og noget du skal forsøge at undgå.

Estimer i point og ikke i tid. Der findes forskning som siger at vi er bedre til at estimere relativt (en klump arbejde sammenlignet med en anden) end til at estimere i absolutte timetal. Desuden giver story point mulighed for at diskutere en opgaves omfang uden først at skulle fastlægge hvem der skal lave opgaven (hvis man mener at timetallet afhænger af det). Dette er ikke et ukontroversielt punkt.

Softwareudviklere er optimister. Vi estimerer ofte ud fra best case (og kun happy path) og glemmer besværlige omstændigheder. For at få en opgave lavet er der ofte andet end kodetimer involveret. Det kan f.eks. være yderligere afklaring af krav, afhængigheder til andre teams eller dele af organisationen som f.eks. skal levere data til opgaven, tests af forskellig art, møder i forbindelse med overlevering af en opgave og andet nødvendig kommunikation til aftageren af opgaven. Derudover glemmer vi også at der gemt i hjørnet af vores kode stadig er noget legacy code, teknisk gæld eller finurligheder som der også lige skal tages hensyn til, når opgaven skal laves. Softwareudviklere er notoriske optimister omkring egne evner til at få en opgave ud af døren og ser ofte kun kodetiden og ikke alt det udenom, hvilket giver et alt for lavt estimat. Ofte nævnes løsningen “gang med π”. Hvis man får et estimat i timer/dage og ikke i story points, så er det en gammel læresætning at man skal gange estimatet med π for at opveje optimismen. Til det vil jeg sige at man skal være opmærksom på hvor mange led estimatet har været igennem og om hver af leddene har ganget med π.

Så vigtigt er et nøjagtigt estimat ikke. Vi regner med at tjene ind på gyngerne hvad vi har mistet på karrusellen. Nøjagtighed tager tid og lang tids forundersøgelse. Oftest kan det ikke betale sig at gå for meget i detaljen, da unøjagtigheder kan gå begge veje og hvad vi sparer i tid på en opgave kan vi så bruge på den opgave som vi undervurderede. Vi er nemlig ikke gode til at estimere – selv når vi laver lange forundersøgelser.

“Det er svært at spå – især om fremtiden” ~ukendt.

Der findes mange estimeringsskalaer. Jeg har ikke præference for nogen bestemt estimeringsskala bare skalaen kan indeholde både det mindste og det største estimat som vi har brug for og ikke er for finkornet. Finkornede skalaer giver for lange diskussioner om ting vi har stor usikkerhed omkring til at vi kan komme med et godt svar. Nogle bruger t-shirt-størrelser, mange bruger planning-poker-skalaen. Andre igen bruger Fibonacci-tal.

Jo tættere vi er på at skulle i gang med opgaven, jo bedre overblik har vi og jo mere information har vi. Der er fornuft i at reestimere et tidligere estimat, når vi kommer tættere på at opgaven skal udføres. Ofte kan vi så også bryde opgaven ned i mindre bidder – dog ikke altid uafhængige bidder.

Hvor ofte skal vi (re-)estimere? Vi bliver hele tiden klogere, så vi kan bruge lang tid på at re-estimere opgaver. Det er en balancegang mellem tiden vi bruger på det og nytten vi får ud af det. XKCD illustrerer det så godt.

Vi bruger også estimering som en måde at være sikre på at alle forstår opgaven til bunds. Når to personer efter at have hørt en opgave beskrevet giver vidt forskellige estimater, så er det typisk fordi vi skal have defineret opgaven bedre. Samtalen om hvorfor vi estimerer som vi gør aka hvad vi lægger i opgaven, giver en værdi, som for nogen er den primære grund til at estimere.

Undgå at slå folk i hovedet med estimater. Estimater er som regel forkerte. Det er sjældent at en opgave tager præcist det antal timer og minutter som vi forventede. Når vi har været lidt for optimistiske, så står en opgave ufærdig til deadlinen, og hvad gør vi så? Det vigtigste: Lad være med at hænge nogen op på det oprindelig estimat. Sørg for at lære af situationen i stedet for at pege fingre. Hvordan kunne vi have håndteret dette bedre? Skulle vi have kommunikeret anderledes eller måske før vi gjorde? Ville det have været værd at bruge mere tid på at få et bedre estimat? Skal der bruges tid på at fjerne nogle sten på vejen som forhindrede os i at nå deadlinen? Hvis du i stedet lader et forkert estimat få negative konsekvenser for estimat-giveren, så risikerer du at få en CYA-kultur, hvor alle går med livrem og seler og vægrer sig ved overhovedet at komme med et estimat. Softwareudviklere får jo ikke en særlig glæde ud af at misse deadlines. Vi gør vores bedste og når en deadline misses, så er det på trods af hårdt arbejde og med meget frustration.

Parkinsons lov. En måde estimater kan være skadelige på, er ved at fastsætte en forventning til hvor lang tid opgaven skal tage at løse. Parkinsons lov siger at det er sandsynligt at opgaven strækker sig til det allokerede tidsforbrug. Altså kunne vi til tider have afsluttet en opgave tidligere, hvis ikke estimatet var sat. Om tiden så bruges på finpudsning, kaffedrikning, møder eller lignende er ikke pointen.

Estimering som kontrol. Estimater bruges også til at kontrollere at vi leverer til tiden, hvis vi følger op på dem. Her kan del-estimater bruges til at finde ud af om et større projekt skrider fra sin oprindelige deadline. Dette er meget brugbart, hvis denne deadline er sat i sten og der f.eks. til denne deadline hører en entusiastisk marketingskampagne for det færdige produkt. Trist at stå med kampagnen uden produktet. Vi ser dog også projekter som bruger lang tid på estimater, som intet har hængende på en arbitrær intern deadline og som ville have udført projektet uanset omkostningen, og dermed ikke får værdi ud af at følge op på estimaterne. Disse projekter estimerer for estimatets skyld.

Estimater som prioriterings-hjælp. Hvad giver mest værdi at arbejde på først? Begrebet “cost of delay” kan hjælpe os med at synliggøre dette. Der kan være gode argumenter for at få nogle værdifulde mindre opgaver færdiggjort først og f.eks. metoder som Scaled Agile Framework anbefaler en prioriterings-rækkefølge med “Weighted Shortest Job First”.

Estimater og planlægning. Vi estimerer ofte i god tid, hvis estimatet f.eks. skal bruges til at finde ud af om det kan betale sig at lave et projekt. Desværre er estimat-aktiviteten i den situation fuld af incitamenter til at undervurdere en opgave og i den tidlige fase af et projekt ved vi mindst muligt om den reelle aktivitet, der er nødvendig for at løse opgaven. Dertil kommer at når vi har brugt tid på at komme med et estimat på delelementer af en plan, så er vi endnu mere investeret i at holde os til planen. På den anden side bruges estimater i den agile verden netop til at ændre planer og håndtere scope creep ved at “bytte” en arbejdsklump ud med en anden – altså når man tilføjer en opgave til backloggen, så tager man en estimeret samme størrelse opgave(r) ud.

Hav formålet i fokus

Estimater er som du kan se et kæmpe-stort og kompliceret emne, som afhænger meget af organisationers og menneskers natur. Selv de mest ekstreme tilhængere af #noestimates-trenden vil næppe foreslå at vi helt skal forbyde estimater. Estimater kan være en hjælp, de kan gøre skade, og når man arbejder med dem, så er det vigtigste man kan gøre at vide hvorfor. Hvorfor estimerer vi i denne konkrete situation? Hvad bruges estimaterne til og tilfører de den ønskede værdi ud fra det arbejde der lægges i estimatet? Hvilken detaljegrad skal vi investere i vores estimater?

Det er desværre ikke simpelt. Hvad synes du er vigtigt at huske, når man estimerer (eller lader være)?

Share Button
The following two tabs change content below.
Profile photo of Therese Hansen

Therese Hansen

Programmør af Monzoom
Therese er tidligere Scrum Master hos LEGO, medstifter af IT-firmaet Monzoom, lejlighedsvis digital nomade og har en baggrund som datalog. Hun blogger om softwareudvikling, sociale udviklere, agile metoder og startups. Arbejder i øjeblikket på Linkstacks.
Profile photo of Therese Hansen

Nyeste indlæg af Therese Hansen (se alle)

Flattr this!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *