Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Det er kun rimeligt, at en ledelse har brug for data, når der skal træffes beslutninger.
Et kvalificeret gæt er absolut at foretrække fremfor et mindre kvalificeret, ligesom et knap så kvalificeret gæt trods alt er bedre end at kaste med en terning.
Min erfaring fra mange år som softwareudvikler er dog, at estimering rummer et uudtømmeligt potentiale for konflikter og dårlig karma - men hvorfor det?
Hvad er det, estimering gør ved et softwareprojekt - hvornår hjælper det og hvornår er det decideret spild af tid? Hvad er det for en adfærd, et sæt estimater på features driver i en virksomhed?
Før vi giver os i kast med at finde svar på disse spørgsmål, så er det væsentligt at se på, hvor konflikterne opstår.
Fordi emnet er så ladet med følelser og alle mener en masse om det, så giver en hurtig søgning på Google denne artikel, hvor forfatteren ridser følgende fem læresætninger op:
- Estimering er spild af tid.
- Estimater kan ikke overføres.
- Estimater er forkerte.
- Estimater er midlertidige.
- Estimater er nødvendige.
Der skal nok slibes nogle kanter her
Der er naturligvis nuancer - men hovedparten af softwareudviklere med mere end fem års erfaring fra forskellige softwareprojekter vil være enige med artiklens forfatter i, at estimering sjældent giver værdi, ofte bliver misbrugt og altid er et emne, hvor der skal slibes nogle kanter, både internt i et team såvel som i forhold til forretningen.
Lad os for sjovs skyld se på læresætningerne igen, nu med andre øjne.
Lad os tage for eksempel en mellemleder i en virksomhed med 200 ansatte.
Vedkommende - lad os kalde ham Lars - har masser af erfaring med projektledelse fra byggebranchen, men har ikke flair for eller interesse i softwareudvikling som fag.
Til gengæld har Lars et stort budget, er blevet spottet som et ledelses-talent af direktøren og er nu produktejer på implementeringen af virksomhedens nye CRM-system.
Lars laver en backlog til projektet, og nu skal den prioriteres og estimeres.
Ind kommer det team af fastansatte og konsulenter til fire-cifrede timepriser, der er hyret ind til opgaven.
De siger hudløst ærligt det, de tror på er sandheden - og som de har lært på sidste uges teambuilding, så er forudsætningen for et succesfuldt samarbejde, at alle er hudløst ærlige undervejs i projektet. Teamet siger til Lars: “Estimering er spild af tid”
Hvordan så planlægge?
Lars’ reaktion er forudsigelig og hans modsvar er ligeså: “Hvordan skal jeg planlægge noget som helst, hvis I ikke vil sige, hvor lang tid, hver feature tager at lave?”
Teamet følger efter noget diskussion om time-estimater vs. relative storypoints op med udsagnet: “Estimater kan ikke overføres”.
Lars siger: “Det ved jeg ikke, hvad betyder”.
Teamet forklarer, at estimater kun giver mening i kontekst, dvs. hvis man ændrer på teamet sammensætning, på projektets milepæle, økonomi, målsætninger eller noget fjerde, så vil det kræve re-estimering af resterende opgaver.
Lars er målløs - sådan fungerer tingene nemlig ikke helt i byggebranchen, her kan man godt flytte håndværkere rundt på forskellige byggepladser, uden det af den grund tager fire gange så lang tid at mure en væg.
Teamet sætter ham nu til vægs med udsagnet “Estimater er forkerte”.
Lars har svært ved at forstå, hvordan han så kan bruge sit team til noget som helst, når de åbent erkender, at deres input til forretningen er forkerte.
Hvordan skal Lars så kunne gå op til den øverste ledelse og aflægge rapport, hvis alle forudsigelser er baseret på noget, udviklerne siger er forkert? Kække bemærkninger om, at det er svært at spå, især om fremtiden, falder ikke i god jord.
“Estimater er forresten midlertidige”, siger teamet efter den fælles frokost, hvor der mest blev snakket fodbold.
Nu er han ved at blive træt
Lars er på godt jysk træt af det hele og føler sig presset, fordi hvis en feature ville tage X timer for tre måneder siden, hvor estimatet blev afgivet, hvordan kan det så tage X + 200 timer nu, hvor vi skal i gang?
Det skal her siges, at teamet har for at komme Lars lidt i møde tidligere aftalt at estimere i timer, ikke story points - de valgte at udskyde den diskussion til en anden gang.
“Estimater er nødvendige”... hvis Lars ikke har forladt mødelokalet forinden for at trække noget frisk luft, så kan de formentlig blive enige på lige præcis dét punkt.
Det er et tænkt scenarie, men scenen ovenfor kan en hel del udviklere nikke genkendende til - jeg har studeret og reflekteret over situationer og møder, som måske ikke var så karikerede som ovenfor, men hvor jeg havde en fornemmelse af, at der var en grundlæggende problemstilling, der skulle løses først, inden vi kunne mødes og blive enige om det videre forløb.
Hvordan opfatter vi verden?
Efter mange tanker og snakke med kollegaer og andre mener jeg at have forstået følgende: Årsagen til den konflikt, Lars og teamet gennemlever er, at Lars og teamet ikke har samme grundlæggende opfattelse af den verden, de befinder sig i.
De spiller ikke efter samme regelsæt. Lars’ verden er konkret og forudsigelig, det er teamets ikke. Den er uforudsigelig, tilfældig og kaotisk.
Softwareudvikling er nemlig speciel ved, at der ingen fysiske love findes i kode. Alt er til forhandling - der er ingen tyngdelove i softwareudvikling, du er nødt til at indrette dig efter, så snart du har forladt hardware-laget i din infrastruktur.
Der er ingen regler, der begrænser, hvordan du implementerer en feature i et software, som der er i den virkelige verden, når du skal mure en væg på en byggeplads.
Dette er en meget væsentlig erkendelse for softwareudvikleren såvel som projektleder-Lars, fordi når der ingen regler eller ramme er, så bliver variansen uendelig stor. Antallet af løsninger er uendeligt stort - du kan omvendt beregne dig ret nøjagtigt frem til, hvornår en væg vælter, hvis du bygger den skævt.
Antallet af mulige implementeringer er uendeligt store for en given feature i et stykke software og derfor er estimater midlertidige og så afhængige af kontekst, at det nogen gange bliver spild af tid og ren cargo-cult at lave estimering, fordi alting alligevel ændrer sig undervejs pga. indbyggede ubekendte faktorer i den 500.000 kodeliniers monolit, man skal lave endnu en udvidelse til.
Det forstår en softwareudvikler og kan navigere i, fordi det er den verden, vi lever i og med hver dag - men det kan vi egentlig ikke forvente, at folk uden erfaring med at producere kode kan sætte sig ind i.
Det gør vi desværre ofte og så bliver Lars frustreret, for vi har ikke forklaret ham, at hans grundlæggende antagelser om, hvordan software bliver skabt, ikke nødvendigvis holder stik.
Vi har ikke forklaret Lars reglerne for softwareudvikling og hvilken konsekvens det har for vores adfærd og måde at angribe problemstillinger på.
Agil udvikling bygger på en erkendelse af, at risiko og usikkerhed er den eneste konstant - alt andet er noget, vi finder ud af, efterhånden som vi arbejder os igennem de enkelte features. Den slags er sort snak for en, der er skolet til at kunne regne sig frem til et facit uden brug af empiri.
Heri ligger den indbyggede konflikt i estimering - når estimering går galt, så er den underlæggende konflikt, at spillets regler ikke er blevet snakket igennem på forhånd.
Forretningen har brug for data til at kunne planlægge og prioritere, derfor er estimering nødvendig, men alle parter skylder os selv at tage en snak om, hvad et estimat er og hvad vi vil bruge resultatet af en estimering til, før dén øvelse bliver en succes for alle parter.
Den snak er en, som kun en softwareudvikler og en softwareudviklingsorganisation kan starte, for vi er dem, der forstår helheden og dermed også ansvarlige for at tage resten af organisationen i hånden og fortælle dem regel #1: Der er ingen regler.
Hvordan kommer vi hinanden i møde?
Hvordan gør man så det - kommer forretningen og rockwool-laget af mellemledere uden kode-erfaring i møde?.
Ser man på verden fra chefgangen og har erkendt regel nummer 1 fra før, så vil man også indse, at et veldokumenteret standardsystem købt på licens altid den rigtige vej, medmindre du har et forretningsmæssigt strategisk behov for at have fuld kontrol over udvikling og drift af en given applikation.
Du har en veldokumenteret varians i din software, når du køber hyldevarer til at styre CRM, regnskab osv.
Det er fuldstændig tåbeligt at lave den slags systemer selv og har været det i en del år efterhånden.
Der, hvor du skal passe på er, når din forretning begynder at udvide standardsystemer med ekstra funktioner, bygge ovenpå og integrere systemer med hinanden - variansen og risikoen for fejl stiger for hver eneste ekstra kodelinie, du putter ovenpå et standardsystem.
Det ønsker du derfor kun at gøre i tilfælde, hvor du ikke kan undgå det.
En dyr licens til eksempelvis at integrere flere Microsoft-produkter ind i hinanden kan hurtigt vise sig at være investeringen værd.
Du kan måske godt blive fristet af udvikleren, der har en ide til at overføre data fra A til B og “godt lige kan prøve at lege med de der API’ere, engang i aften”...
Lyt ikke til sirenerne, luk diskussionen, for du ender med en dårlig, ikke-skalerbar løsning, ingen kan vedligeholde, men som til gengæld er forretningskritisk i kraft af, at alle forretningskritiske data fremover vil flyde igennem en dims, der blev undfanget som et side-kick af en enkelt udvikler hen over nogle mørke vintermåneder.
Køb licenser og supportaftaler
Brug de samme penge på at handle licenser og en supportaftale hjem, så det er en andens hovedpine, hvis noget holder op med at virke.
Din fornemste opgave som øverste leder er at minimere risikoen for varians i et softwareprojekt mere end noget andet og det gør du bedst og billigst ved at kigge efter standardløsninger og standard plugins, inden du så meget som overvejer at kaste ressourcer efter at bygge tingene selv.
En anden tilgang, der er tiltænkt udvikleren på gulvet: Helt lavpraktisk kan du åbne en diskussion om, hvorvidt estimering overhovedet giver mening i jeres projekt eller i jeres team. Hvad bruges estimater til?
Hvad har I lært af jeres estimater de sidste tre måneder i jeres team?
Her er fokus ikke så meget minimering af risici, men at minimere spild og maksimere den tid, der bliver brugt på design og implementering af features.
Jeg mener, at estimering giver mest værdi, når du skal prioritere en backlog for at få de vigtigste ting skubbet øverst.
Hvis du for eksempel godt ved, hvad der skal laves og det, der skal laves, skal laves uanset hvad - hvorfor så spilde tid på estimering?
Jeg ville da bare gå i gang og bruge timerne på at få opgaven løst.
Estimering kan uden god mødedisciplin og fokus på teamets tidsforbrug hurtigt blive en meget dyr affære - fem programmører, en projektleder og en produktejer i et rum i to timer er potentielt 10 spildte udviklingstimer + moms, der kunne være blevet brugt på at implementere den næste feature i backloggen.
Regn på det og vis, hvad I bruger af tid på estimering - X møder á Y minutter over de sidste Z dage… hvad fik vi ud af det? Kan det svare sig?
Til projektlederen: Måske skal du droppe estimering i en periode og bruge krudtet på en god proces, der håndterer risici og afhængigheder løbende.
Du kan bare måle på f.eks lukkede userstories eller lukkede tasks, hvis du har brug for et burndown-chart, det behøver du ikke tidskrævende estimering og opfølgende timeregistrering til.
Hvis du glemmer alt det og i stedet laver en løbende risikovurdering af ting, der kan gå galt, så nedbringer du automatisk også variansen, for risici i et projekt udspringer af, at der er noget, du ikke kan forudse og/eller ikke ved nok om.
Brug tiden, I ellers sammen ville have brugt på estimering, til at lade teamet indsamle mere viden, lad det være uddannelse, tests, proof of concepts, interviews med brugere eller noget andet.
Bring så den viden i spil, når den næste beslutning skal træffes - du vil opleve, at backloggen automatisk vil blive løbende prioriteret undervejs i processen helt uden, at dig og dit team har brugt tid og energi i et mødelokale på at diskutere timer vs. storypoints vs. hvorvidt estimering overhovedet giver mening.
Når jeg en dag går på pension, så er jeg sikker på, man stadig vil diskutere estimering og estimeringsteknikker, for den grundlæggende konflikt bliver aldrig løst.
Der vil altid være et hul i forståelsen, men det er ingen grund til at give op og lade stå til.
Kampen er stadig værd at kæmpe, for det er voldsomt tilfredsstillende at arbejde på et projekt, hvor de grundlæggende principper og regelsæt er i harmoni på tværs af alle involverede.
Det kan absolut lade sig gøre at søsætte en sund diskussion om estimering i selv de tungeste virksomheder med sort bælte i PRINCE II og vandfaldsmodel, men første skridt er, at vi udviklere tager opgaven på vores skuldre - ingen andre kommer og gør det for os.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.