Blog: Estimere? mig?

Sammenlignet med mange andre ting i verden, er det ikke svært at estimere software. Det handler blot om at bruge de rigtige teknikker og tilgange og på det punkt er IT industrien et u-land.

Udviklere har en indgroet mistillid til at estimere noget som helst. Jeg kan erindre mange samtaler, hvor jeg har spurgt om, hvor lang tid det ville tage at lave f.eks. en integration, og fået et blik tilbage, som om jeg spurgte efter forklaringen på mørkt stof eller beviset for Bose – Einstein kondensatet. Der er udviklet farverige metoder, såsom poker estimater eller T-shirt størrelser for at slippe for at sige, hvor lang tid noget tager. Eller man snakker om guestimate istedet for estimate, fordi man vil understrege usikkerheden (men ordet er blot en pleonasme for både guess og estimate betyder jo det samme). Der findes kort sagt en besynderlig modvilje mod at estimere.

For nyligt læste jeg en tråd på Quora om hvorfor det er så svært at estimere software udvikling. Her var der et svar som rummede et rigtigt godt billede på problematikken omkring estimering. Lad mig kort genfortælle den.

Estimering og lignelsen om vandreturen fra San Francisco til Los Angeles

Forfatteren beskriver i bedste bibelske stil en lignelse, som skal anskueliggøre problemerne med estimering. Det drejer sig ikke om en ørkenvandring, men dog en vandring. Forestil dig vi skal på en vandrertur fra San Francisco til Los Angeles for at besøge vores venner. Vi tager et kort frem og måler, hvor langt der er langs kysten for det er jo meget hyggeligere at gå her, end langs de tisporede motorveje. Vi får afstanden til 600 kilometer. Vi kan gå 6 kilometer i timen og 10 timer om dagen, så det burde tage ti dage.

Vi står tidligt op og starter vores tur, men pludselig opdager vi på kortet, at der er hundredevis af små krøller på ruten fordi kysten har fremspring og små bugte. Det betyder, at der ikke er nogen lige vej langs kysten, og derfor er afstanden meget længere.

Da vi kommer frem til kysten og skal starte vores tur opdager vi, at der også er store niveau forskelle og sand, som er svært at gå igennem. Det betyder at vi kun kan gå med 3 kilometer i timen. Altså halvdelen af den fart vi troede. Vi vil istedet gå 12 timer om dagen og ringe til vores venner og sige, at vi bliver lidt forsinkede.

Vi slår lejr, men sover over os næste morgen. Vi har sovet forfærdeligt så vi bliver nød til at gå efter 10 timer og så tage 14 i morgen. Pludselig kommer en tåge ind og vores ven får vabler. Den ene af os bliver nød til at gå 5 kilometer ind til nærmeste by for at købe plaster. Så har vi spildt endnu en halv dag.

Næste dag kommer vi op til tiden, men finder ud af at stien pludselig ender ud i det blå. Et jordskred har undermineret stien. Det kunne vi ikke se på kortet. Og så bliver min ven syg og vi må holde pause en dag….

Det går op for os at vi kun er nået 60 kilometer på 4 dage. Det betyder en gennemsnitshastighed på 15 kilometer om dagen istedet for de 60 vi troede. Det kommer altså til at tage 4 gange så lang tid som vi estimerede til at starte med.

Og fortolkningen af lignelsen viser…

159 mennesker på Quora syntes, at dette var et fantastisk svar, som virkelig beskriver virkeligheden for udviklere. Kommentarerne viser, at det virkelig har ramt en nerve. Det viser hvorfor det er umuligt for udviklere eller nogen andre at estimere, hvor lang tid noget tager.

Men er det nu det som lignelsen viser? Nu er jeg en af dem der sad med åben mund og polypper gennem hele B.S. Christiansens selvbiografi og jeg spørger altid mig selv, hver gang jeg bliver præsenteret for noget svært: “hvad ville B.S. have gjort?”.

• 1) han havde nok ikke glemt plaster og basal nødhjælps kit
• 2) han havde nok ikke lavet så overfladisk en planlægning at han ikke havde sat sig grundigt ind i terrænnet inden han gik i gang
• 3) han havde nok spurgt nogen som vidste noget om vandreture i kystnært terræn, hvad man kunne forvente og lagt ind i planen, at der kunne opstå situationer, hvor der var tåge, stier som var underminerede og lignende
• 4) han var nok ikke blevet overrasket over at nogen blev syg eller såret på turen
• alt dette havde han nok taget med ind i planlægningen
• 5) hvis han skulle nå frem til et sted bag fjendens linier til et bestemt tidspunkt, havde han nok ikke holdt pause eller sovet for længe.

Så jeg vil nok vende den om og sige, at hvis man virkelig synes, at det er et godt billede på, hvordan der estimeres, så viser den snarere hvor amatøragtigt og dilletantisk, man angriber den opgave ude i udviklingsafdelingerne i dag.

Lidt kontekst

Man kan også prøve at sætte IT udvikling ind i en kontekst: der er i sidste ende nogen, som betaler, og de vil nok gerne vide lidt om, hvad de betaler for. De betaler ikke med storypoints eller T-shirts, men i kroner som udregnes på baggrund af…ja, antal timer. Derfor er det vel helt i orden at blive afkrævet et bud på, hvor meget man tror det vil koste? Det er vel fair nok? Hvis du skulle engagere en håndværker til at bygge noget ville du så acceptere, at han sagde at det var umuligt at give et estimat? Ville du acceptere et tilbud udregnet i T-shirt størrelser eller smølfedollars?

Man kunne argumentere for at estimering er noget mere kompliceret, og at det derfor ikke er muligt. Men det argument holder heller ikke. IT udviklere har det ikke hårdt i forhold til kompleksitet og evne til at forudsige når man sammenligner med andre professioner. Hvis du f.eks. er aktieanalytiker eller børsmægler, så er du i en helt anden liga af kompleksitet end et e-commerce website eller en foto delings tjeneste. Argumentet svarer til at man i investeringsverdenen påstod, at det var værdiløst at prøve at lave kursmål og at bruge dem til noget fordi de alligevel aldrig holder. Selvfølgelig kan man give et bud, og det er ikke nogen skandale, hvis man ikke rammer.

Det ledelsesmæssige svigt
Det er her det grundlæggende problem viser sig. For problemet er ikke uvillige og kontrære udviklere, men et fundamentalt ledelsesmæssigt svigt i de fleste organisationer. Langt de fleste ledere opfatter estimering som en lageroptælling eller, endnu værre, et forhandlingsudspil, hvor man kan prøve at presse tiden ned. De har meget ringe forståelse for den kompleksitet og usikkerhed, der er involveret. Alt for sjældent bliver udviklere og projektlederes forbehold taget seriøst. Det optimistiske scenaries dead line bliver opfattet som en leveringsdato fra GLS. Man kritiserer udviklingsteamet, når de ikke når denne deadline, og antyder, at det er fordi, de er enten uduelige eller dovne. Dette har jeg aldrig set som primær årsag til forsinkelser. Tvært i mod er der få medarbejdergrupper der er villige til at give den så meget ekstra kul som udviklere.

Derimod er scope creep, upræcist formulerede krav, manglende prioritering fra opdragsgiveren blandt de helt centrale årsager. Men alle disse usikkerheder kan faktisk sagtens regnes med. Som sagt så kan andre og væsentligt sværere problemer sagtens estimeres med pæn præcision. Det handler bare om at finde metoderne.

Fem tip til estimering

Der findes nemlig nogle få tricks til at optimere estimeringen, så man kan få et relativt præcist billede af hvor lang tid noget tager. Jeg har selv været med til projekter i størrelsesorden 50 mandeår som ramte indenfor 10% af estimatet, så det er bestemt ikke muligt.

Man kan nemlig bruge samarbejde og Wisdom of Crowds tænkning til at booste præcisisonen af estimater. Det er ikke uden grund at bookmakere er de mest præcise indikatorer på vinderen af det amerikanske præsidentvalg. Det følgende er nogle få tips, man kan gøre brug af for allerede at starte optimeringen af estimering i dag.

Man skal:
* 1) fra ledelsens side helt fundamentalt anerkende specialisternes kompetence. Estimater må ALDRIG forhandles. Man forhandler jo heller ikke med vejrmanden. Man må gerne spørge ind i en åben dialog for at finde ud af hvor kompleksiteten ligger hvis noget, som opdragsgiveren troede var let, ser svært ud. Det kunne jo være man havde misforstået hinanden eller en ligegyldig detalje skabte en stor unødvendig kompleksitet.
* 2) gøre sig klart, hvad det er man estimerer. Hvis du spørger en udvikler hvor lang tid det tager at kode en funktion, så vil han typisk svare tilbage i effektiv kode tid. Men effektiv kode tid er en relativt lille del af den samlede tid det tager at udvikle. Der skal bruges tid til design af brugergrænseflade og arkitektur, projektmøder, unit test og test derudover bør der ligges en pulje til risiko og uforudsete hændelser. Bliv ikke overrasket hvis overhead på det estimat som kommer ud af udviklerens mund viser sig at være 100% eller mere af estimatet
* 3) få flere forskellige til at gøre det. Jo flere med relevant viden, der giver input jo bedre sandsynlighed er der, for at gennemsnittet ligger tæt på det reelle tidsforbrug. Det er det samme princip, som bruges med poker estimater i den agile verden. Her skal flere forskellige også give input til, hvor lang tid noget tager.
* 4) sørge for at de, som estimerer er uafhængige af hinanden i deres estimater. En stor fejlkilde er såkaldte information cascades eller det fænomen at folk kopierer/bliver påvirket af information fra andre istedet for information fra problemdomænet. Her følger de fleste efter den dominerende i en gruppe uanset om denne har kompetence indenfor området eller ej. Det er en dårlig ide.
* 5) sørge for diversitet i input. Når man estimerer er det vigtigt at få forskellige øjne på problemet, da forskellige specialister ser forskellige problemer.

Der er således ingen grund til, at man ikke skulle kunne estimere, og begynde at bruge det til at styre, hvad man vil udvikle. Det kræver dog en del overvindelse både fra ledelsens og specialisternes side.