Estimater? Vi har ikke brug for nogen estimater!
Den 10. December 2012, klokken 17:53 udsendte Woody Zuill et tweet, med ordlyden:
#NoEstimates—I’ve added a litte more fuel to the fire
Hans tweet linkede til et blogindlæg, hvori han beskriver en nærmest kættersk tilgang til softwareudvikling — en der helt udelader estimering af tid og ressourcer.
Zuill er en softwaremanager for et Sydcalifornisk firma, der laver vandingsanlæg til haver og sportsbaner. Hans valg af hashtag var ikke mere velovervejet end den måde han stavede ’little’ på. Med sin bløde, afmålte stemme, grå skæg og det tavse smil, som velbevandrede optimister bærer, virker han ikke umiddelbart som prototypen på en revolutionær ildsjæl.
Alligevel blev hans #NoEstimates-hashtag som en magnet for utilfredse kodehoveder overalt, og inden længe var det blevet en slags banner for dem. Ligesindede programmører og ledere fra mange lande flokkedes til den diskussion, der udspillede sig på Twitter, mens traditionelle programmører rynkede på næsen over de argumenter, der blev fremført.
Zuill og hans #NoEstimates-allierede ville benytte udtrykket som en slags invitation til samtale. Vasco Duarte, en anden fortaler for #NoEstimates, havde tweetet lignende idéer under hashtagget #EstWaste, men Zuills hashtag — med sin Marianne-på-barrikaderne (Marianne er et symbol på frihed i den franske nationalisme, red.), ”De skal ikke komme igennem!,” frihed-eller-død stemning — udgjorde et bedre slogan. Derfor tog først Duarte og derefter andre det til sig, hvilket blev startskuddet til hvad ’extreme-programming’ (en tilgang til softwareudvikling, der vil højne kvaliteten af det endelige produkt bl.a. ved hjælp af programmering i par og en hurtig udgivelsescyklus, red.) pionér Ron Jeffries navngav ”NoEstimates bevægelsen.”
Få en eller anden form for førstehugs-software i hænderne på kunden så hurtigt som muligt, og tag den derfra.
Da jeg første gang så nogen bruge #NoEstimates, sprang et billede af et konferencelokale, hvor programmører nidstirrede en mand i jakkesæt, frem på min nethinde. Med armene over kors erklærer de trodsigt: Vi giver dig ikke det, du vil have!
Det sker selvfølgelig stort set aldrig. Det er ikke en gang det, #NoEstimates fortalerne siger, er deres mål. De taler mindre om opstand og mere om en genforhandling af, hvad organisationer forventer af softwareudviklere. De er udmærket klar over, at deres idéer kan virke upraktiske og usandsynlige; deres præsentationer er sågar fulde af billeder af regnbuefarvede enhjørninger og Don Quixote. Men de er vedholdende i deres spørgsmål.
Ligesom så mange andre programmører før dem, har de lært, hvor forræderisk det kan være at sætte en knappenål i kalenderen på en bestemt dato og beslutte, at det er her, projektet vil være stå færdigt. Kan vi ikke nok stoppe, med at gøre det?
I al den tid vi har produceret software, har vi overskredet deadlines. Men i 1960erne, da behovet for mere omfattende softwareprojekter i industrien opstod, begyndte programmørerne at finde ud af, at jo hårdere de arbejdede på at levere et poleret produkt til tiden, jo mere galt gik det. I 1960erne blev Frederick Brooks sat til at lede et kæmpe programmeringsprojekt hos IBM og i den forbindelse opdagede han, at jo flere programmører han satte på opgaven, jo mere forsinket blev projektet.
Det stank.
Oh fuck, hvad laver jeg dog her? Jeg troede det var en strejkefest!”
Og softwareudviklingens annaler er pakket tæt med disse episke katastrofer. Dem, der er bedst dokumenteret, er dem i den offentlige sektor, herunder FAA (den amerikanske luftfartsmyndighed, red.), FBI og Healthcare.gov (et samlet website for amerikanske sundhedsforsikringer, red.). Det private erhvervsliv er bedre til at holde kortene tæt ind til kroppen, men når den fulde historie om slow-motion maveplaskere såsom Microsofts Windows Vista bliver fortalt, er det ikke kønt. De mest brugte tal for fejlslagne softwareprojekter kommer fra konsulenthuset The Standish Group, der i 2012 rapporterede at succesraten for softwareprojekter var på blot 39 procent.
Forsinkede softwareprojekter bliver dyrere end beregnet, de er skyld i følgeskader, og de kan endda betyde, at virksomheder må dreje nøglen om. Derfor har softwareindustrien dedikeret årtier til krigen mod forsinkelser — forsøgt sig med frontalangreb, beskydning fra siden, sabotage, diplomati og bestikkelse og brugt taktikker med navne som objektorienteret programmering, The Rational Unified Process, open-source, agil og extreme programming (alle forskellige tilgange, der på hver deres måde forsøger at tackle problematikken, red.).
Estimater spiller en rolle i næsten alle disse tilgange. Estimater er belejringsmaskinerne i krigen mod forsinkelser. Hvis vi bruger dem omhyggeligt, med tålmodighed og uden barmhjertighed, så er håbet, at vi, måske, en dag vil vinde.
Hvorfor bliver software forsinket? En ærværdig tradition inden for feltet siger, at det ligger i selve softwarens natur. Eftersom kode ikke koster noget at kopiere, så er programmører altid i gang med at løse nye problemer. For hvis problemet allerede havde en løsning, så kunne man jo bare kopiere koden. Herudover, så har vi meget svært ved at definere, hvornår et stykke software er ”færdigt.”
Disse pointer blev rejst af fysikeren Aaron Santos da jeg opsøgte ham, for at få hjælp til at forstå det kontroversielle i #NoEstimates — han er forfatter til bogen How Many Licks? How to Estimate Damn Near Anything. Han fortalte, at softwareudvikling kun minder en smule om andre grene af ingeniørfeltet og mere om grundforskning, hvor man blot må le ved tanken om at kunne estimere sig frem til et facit: ”Et lignende spørgsmål fra mit felt ville være, ’Giv mig et estimat på den tid, det vil tage os at finde ud af hvad dark matter er.’ (min kursivering, red.). Jeg aner ikke, hvor lang tid det vil tage! Når vi står ansigt til ansigt med problemer, vi ikke har beskæftiget os med før, så fungerer de traditionelle teknikker for estimering ikke altid.”
Der er mange måder at forsøge at lave softwareestimater på, men de fleste ser således ud: Først opdeler du projektet i små nok bidder, til at du kan overskue dem. Derefter finder du ud af, hvor længe hver bid vil tage at løse, ved at bryde dem ned i endnu mindre bidder. Så tæller du sammen, og der har du dit estimat!
Lad os stoppe med at forsøge at forudsige fremtiden”
Det kan du gøre, inden du påbegynder selve arbejdet med projektet— så er du en “vandfaldstype” der gerne vil gøre en ting færdig, inden du påbegynder den næste. Eller du kan gøre det i små bidder, i takt med at projektet skrider frem —det er den metode, der er populær i dag, fordi den giver dig mere plads til at ændre kurs. Grupper overalt i verden bruger nu den agile ”Scrum”-teknik, hvor programmører snakker med ”produktejere”, for at opdele arbejdet i ”stories”, som de herefter kigger på, for at gætte på, hvor lang tid de vil tage, og hvor mange af dem der kan være i et (kort, som regel to uger) ”sprint”.
I denne verden kan man ikke opdele i dage-og-timer estimater på forskellige ”stories”; I stedet vælger man ud fra en række forskellige træskolængde-tilgange: Man tildeler ”points” til hver ”story”, eller bruger en skjortestørrelse-tilgang, hvor hver ”story” tildeles en label såsom S, M, L, XL. Nogle grupper spiller også ”project poker,” en teknik hvor programmørerne byder på opgavens størrelse i blinde, ved at skrive deres estimater på bagsiden af et spillekort. På den måde bliver deres gæt ikke påvirket af den første person, der ytrer sin mening.
Nogle udviklere sværger ved disse teknikker; andre vender det hvide ud af øjnene over det, de opfatter som modefænomener i en markedsplads for programmering, der er under hastig forandring. Og problemet består: Uanset, hvordan du forsøger at nærme dig dem, så er estimater af softwareprojekter alt for ofte forkerte, og jo mere tid vi dedikerer til at lave estimaterne, jo mere tid fjerner vi fra det faktiske arbejde med at bygge software. Læg hertil, at ledere har en tendens til at opfatte udviklernes anslåede estimater som kontraktuelle deadlines, for derefter at få et føl, når den overskrides.
Og der er mere: Udviklerne, der er rædselsslagne for udsigten til at give deres chef et føl, lægger mere og mere energi i arbejdet med skruen-uden-ende estimater. Det arbejde bliver et meningsløst ritual, der foretages for at udskyde det egentlige udviklingsarbejde.
Det er i hvert fald tilfældet, når man spørger #NoEstimates-tilhængerne. De siger, lad os stoppe denne uendelige belejring. Lad os bruge tiden mere fornuftigt.
Zuill foreslår, at man dropper estimater fuldstændig, og med det samme. Få en eller anden form for førstehugs-software i hænderne på kunden så hurtigt som muligt, og tag den derfra. Hvordan ser den slags proces rent faktisk ud? Zuill siger, at når en leder efterspørger et estimat, inden projektet påbegyndes, så bør udvikleren spørge tilbage: ”Hvilken funktionalitet er den vigtigste?” — og derefter levere en fungerende prototype inden for to uger.
Hvis der leveres nok kode hurtigt nok og med tilpas meget plads til feedback og tilpasning, så forsvinder behovet for estimater sandsynligvis. Zuill fortæller, at det har fungeret sådan for ham i over et årti. ”Lad os stoppe med at forsøge at forudsige fremtiden,” siger han. ”Lad os få lavet noget og så bygge videre på det — vi kan arbejde os hen mod noget bedre.”
Duarte og Neil Killick, en australsk softwarekonsulent og #NoEstimates mester, foretrækker en mindre gennemgribende tilgang. Duarte, der har skrevet en bog om #NoEstimates, argumenterer for, at man først blot skal påbegynde arbejdet. Efter et par ’sprints’ er man bedre i stand til at give brugbare bud på, hvordan arbejdet vil udspille sig fremadrettet.
Ingen af de to fløje kan pege på en række eksempler, hvor deres idéer har været udført i den virkelige verden. Duartes bog fortæller historien om et #NoEstimates projekt, men det er fiktivt. Der er ikke noget ikonisk ”No Estimates projekt” som fortalere kan citere på samme måde som Chrysler C3-projektet fungerede som prøveballon for ”extreme programming”.
Så der er ikke en krop af verificérbar data som #NoEstimates-tilhængerne kan referere til, når deres idéer bliver akut nedskudt — som det sker, når den Seattle-baserede veteran Peter Kretzman argumenterer for noget, der ofte høres i forbindelse med kritik af #NoEstimates-tankegangen: Tag og bliv voksne! Resten af os bliver nødt til at forholde os til estimaternes hårde realiteter. Hvorfor skulle det være anderledes for forkælede programmører med bedende hundeøjne?
Denne vrede undrer Zuill og hans allierede. Zuill ligner måske en skyd-fra-hoften type — han begynder sine foredrag med undskyldende at proklamere, at han ”ikke er en særlig tidsbevidst person” — men han er ubøjelig i sin holdning til at #NoEstimates ikke er ensbetydende med mangel på disciplin, og det samme er Duarte. ”Markedet sætter deadlines for virksomheder,” siger Duarte. ”Disse er uden for virksomhedens kontrol. [Men] at prøve at bruge estimater for at overholde de deadlines, er en sag, man ikke kan vinde.”
Jeg spurgte Santos, estimeringseksperten, om han kunne komme i tanke om et andet eksempel hvor professionelle har gjort oprør mod estimeringer. Han tænkte så det knagede. ”Der var en gang i de tidlige 00er, hvor Bush og Cheney sagde at de ikke havde nogen idé om, hvor meget Irakkrigen kom til at koste, men det er vist også det,” sagde han. (I februar 2003 fastholdt Det Hvide Hus at ethvert estimat ikke ville være andet end blot et gæt, eftersom timing og længden på krigen, samt varigheden og typen af det fredsbevarende og genopbyggende arbejde er ukendt.)
Efter at have beskæftiget mig med #NoEstimates-debatten var jeg efterladt med en følelse af ambivalens, splittet mellem dens to poler: Detaljerede estimater eller Glem-dem? Kungfutse eller Lao-tse (To kinesiske filosoffer, red.)? Det gamle testamente eller det nye? Felix eller Oscar (de to hovedpersoner i Broadway-stykket The Odd Couple, red.)?
Jeg ville have en second opinion fra en, der havde tænkt grundigt over disse spørgsmål og som havde oplevet det på egen krop. Jeg tog fat i John Allspaw, en ekspert i systemer og skalering. Jeg havde arbejdet med ham for år tilbage; i dag er han vicedirektør for infrastruktur og drift hos Etsy (en online markedsplads for smykker og tøj, red.). Allspaw delte min ambivalens, men fremlagde nogen ret konkrete indvendinger mod #NoEstimates.
#NoEstimates er et eksempel på noget, som ingeniører ofte gør, sagde Allspaw — ”de fortæller om et koncept, ved at beskrive, hvad det ikke er.” Hashtagget understreger den form for kritisk tænkning, som bevægelsen påstår, at den har til formål at fremme og kommunikerer en beslutsomhed, som tilhængerne i sidste ende ikke har tænkt sig at leve op til. ”Hvis du samles omkring noget, der har ’No’ som en del af navnet, så betyder det at du er imod noget. Forestil dig, at du møder op til strejkekæden med dit protestskilt højt hævet. Så kigger du dig omkring og alle andre siger, ’nej, nej, vi er ikke imod det — vi ønsker bare at få en dybere forståelse for, hvad vi opgiver, ved denne model.’ Så må du bare tænke, Oh fuck, hvad laver jeg dog her? Jeg troede det var en strejkefest!”
Allspaw argumenterer for, at uanset hvor frustrerende arbejdet med estimeringer er, så er det en værdifuld del af den indsats, som alle softwareprojekter må igennem i forhold til research af emnet. Det er sandt, at du lærer i takt med at du bygger produktet, men du lærer også, når du estimerer.
”Lad os sige, at jeg sætter mig for at tilføje geolokation til søgninger. Så laver jeg et estimat: Det her kommer til at tage mig omkring en måned. Det er super informativt, ikke bare for mig, men også for andre dele af organisationen, når jeg prøver at beskrive, hvorfor jeg mener at det kommer til at tage en måned.”
Måske har du aldrig lavet geokodning før, så du har brug for ekstra tid til at lære det; eller måske er geokodning let for dig, men du har på fornemmelsen at der kommer til at være problemer med brugergrænsefladen, så du forventer at bruge længere tid på at arbejde på det.
”I forbindelse med, at jeg laver det estimat, så fortæller jeg dig en hel masse om, hvad der er vigtigt for mig og hvad mine antagelser er. Når jeg er færdig, og det enten tog meget længere, eller meget kortere tid, end en måned, så ved jeg noget jeg ikke vidste før: geokodning er meget lettere end jeg troede. Eller meget sværere.”
Allspaw peger også på, at der ikke er noget nyt over trangen til at bryde ud af estimaternes snærende bånd—han nyder at citere en passage fra The Unwritten Laws of Engineering, en manual fra 1944, der siger, at ingeniører ”sædvanligvis forsøger at undgå det irriterende ansvar det er at lave aftaler.”
#NoShirking! [#IngenUndvigelse!, red.] Pligten til at estimere, som den er beskrevet i Unwritten Laws må konfronteres direkte: ”Det burde ikke være tilladt for nogen at undvige problematikken ved at bruge den gamle ’der er for mange usikre faktorer, så jeg kan ikke love noget’-formel.”
Jeg opfatter mig selv som professionel i forhold til min karriere som skribent og jeg har generelt været ret god til at gætte, hvor lang tid jeg ville være om at skrive mine artikler. (Min træning: Årevis af sene nattetimer, hvor jeg skrev teateranmeldelser til redaktører med for meget koffein i blodet, der ikke kunne gå hjem, før jeg afleverede.)
På det seneste er det begyndt at skride for mig. Mine seneste artikler her på Backchannel (den del af Medium-hjemmesiden, hvor artiklen oprindelig optrådte, red.) var alvorligt forsinkede. Denne gang måtte jeg helle tage fat på et kort og sjovt emne, der var let at få færdigt. #NoEstimates så ud til at passe på den beskrivelse.
Hah! Der var over to års Twitterdebat at læse op på. Utallige blogindlæg at gennemse. Travle mennesker, som jeg skulle have fat i. Da jeg startede havde jeg ingen idé om, at der var en hel #NoEstimates-bog, som jeg skulle læse. Jeg endte med at skrive denne sætning hele 10 dage efter, jeg havde fortalt min redaktør, at jeg ville.
Beklager, at jeg ikke bliver siddende og prøver at finde på en mere elegant afslutning. Jeg tror jeg hellere bare må få den afleveret. Måske er jeg bedre til at estimere næste gang.
Skriv en kommentar
This site uses Akismet to reduce spam. Learn how your comment data is processed.