– Siden datamaskinens spede begynnelse har mennesker forsøkt å estimere hvor lang tid det tar å utvikle programvare, og like lenge har de konsekvent feilet.
Det skriver Heinemeier Hansson ("DHH") i et innlegg på LinkedIn. DHH er kjent som skaperen av Ruby on Rails og teknologisjef i 37 Signals, selskapet bak prosjektstyringsverktøyet Basecamp.
Selv det å estimere tidsbruken for middels store utviklingsprosjekter er svært vanskelig, og for store prosjekter er det praktisk talt umulig, hevder han.
– Likevel insisterer bransjen på at metoden som ikke har fungert i 60 år definitivt vil virke på det neste prosjektet, hvis vi bare prøver litt hardere. Det er definisjonen på en illusjon.
Aldri blitt gjort før
Det grunnleggende problemet med å prøve å estimere tidsbruk for utviklingsprosjekter, er at så snart programvareutvikling har blitt så rutinepreget at det blir mulig å estimere – så ender det opp som et produkt eller en tjeneste du kan kjøpe i stedet for å bygge selv.
Som eksempel nevner han at få mennesker har behov for å bygge et publiseringssystem eller en e-handelsløsning fra bunnen av i dag. De bruker bare WordPress, Shopify eller andre alternativer.
– Derfor er mesteparten av programvareutvikling fokusert på nyskapende arbeid, skriver Hansson.
«Smarte programmerere har prøvd i flere tiår.»
Simon trodde han hadde god tid: - Men måtte jobbe 20 timer i strekk for å bli ferdig
Umulig å spesifisere på forhånd
Problemet med nyskapende arbeid, er at ingen vet nøyaktig hvordan sluttproduktet kommer til å se ut før de har begynt å bygge det. Og hvis man prøver å spesifisere nyskapende arbeid på forhånd, ender man kanskje opp med å bygge noe folk ikke vil ha når de får se sluttproduktet.
De virkelige problemene løses gjerne når man har bygget halve løsningen feil, endret retning, og deretter kommet opp med noe bedre, argumenterer Hansson.
– Det er på tide å akseptere dette. Smarte programmerere har prøvd i flere tiår.
Hansson slår i innlegget sitt et slag for Shape Up, en arbeidsmetodikk som er basert på erfaringen til utviklerne bak hans eget Basecamp. Metodikken beskrives i boken Shape Up, som kan leses gratis her – og også er tilgjengelig i papirutgave. Boken og metodikken kom ut første gang for fem år siden.
«Det du ba om før du begynte å utvikle var basert på den absolutt verste forståelsen av problemet.»
- Hjelper ikke å holde estimatet som en pisk over utviklerne
Kan levere på tid og budsjett
Hansson mener det er på tide å slutte å tro at man kan estimere tidsbruk for programvareutvikling, og heller bytte taktikk. Han foreslår selvfølgelig Shape Up-taktikken, som de altså utviklet hos Basecamp.
– Men uansett om du bruker en spesifikk metodikk eller ikke; det å droppe estimater kan hjelpe deg med å levere bedre og raskere.
I korte trekk argumenterer Hansson for å definere tidsrom/sykluser ulike arbeidsoppgaver skal gjøres innenfor, uten å gå for mye i detalj, slik at teamet har handlingsfrihet.
– Det viser seg at programmerere er overraskende gode til å levere fantastisk programvare innenfor en tidsfrist, hvis du lar omfanget ("scopet") være åpent for forhandlinger under utviklingen, skriver Hansson.
Ifølge Hansson vil du riktignok ikke få nøyaktig det du ba om, men det er ikke noe du uansett vil ha, mener han.
– Fordi det du ba om før du begynte å utvikle var basert på den absolutt verste forståelsen av problemet.
