Tidsuppskattningar ett hinder mot lyckad systemutveckling

I dag brottas man med skillnader mellan agil systemutveckling och traditionell, så kallad vattenfallsutveckling på många företag. Men vad är det egentligen som skiljer de båda arbetssätten åt?

När man kommer till kärnan av de olika sätten att jobba så hamnar uppskattningar i strålkastarljuset. Traditionella vattenfallsprojekt bygger i hög utsträckning på uppskattningar av olika slag. I början av projekten görs uppskattningar av hur stor arbetsinsats som krävs. Och sådana uppskattningar ligger till grund för tidsplanen för ett projekt.

Eftersom uppskattningar till sin natur är osäkra så blir det ofta problem med att hålla tidsplaner.

Läs också: Risk för kaos när företagen omfamnar devops

I de flesta agila projekt, till exempel Scrumprojekt, görs också uppskattningar av tidsåtgång. Men de görs oftare och fortlöpande, typiskt i samband med planering av och prioritering för nästa iteration, eller sprint. Det gör att i ett typiskt agilt projekt så kanske man gör nya uppskattningar varannan eller var tredje vecka.

I bästa fall blir de många fortlöpande tidsuppskattningarna mer precisa än en enda stor tidsuppskattning i början av ett projekt, eftersom de förfinas gradvis. Men det lämnas ändå utrymme för felaktiga uppskattningar. Så problemen med uppskattningar finns ofta även i agila projekt. Vad ska man göra åt det?

Man ska kanske strunta i att göra uppskattningar. Det är vad man kan tro att en rörelse som heter No Estimates förespråkar.

– No Estimates innebär inte att man aldrig ska göra uppskattningar, utan att man ska göra uppskattningar när det är meningsfullt att göra det, förklarar Woody Zuill som är av de drivande krafterna för de här tankegångarna, under ett Sverigebesök.

Men man behöver inte prata länge med Woody Zuill för att inse att han verkligen tycker att det inte är en bra idé att göra uppskattningar i utvecklingsprojekt. Den grundläggande orsaken till det är enkel att formulera:

– Uppskattningar är inte fakta, utan gissningar, säger han.

Problemet är att uppskattningar uppfattas som fakta. Ett annat problem är att tidsuppskattningar tenderar att matcha ramarna som finns för ett projekt. Om det finns 200 mantimmar tillgängliga, så är det lätt hänt att komma fram till att nästa fas i projektet ska ta… 200 mantimmar.

Men är inte lösningen på problemen att göra bättre uppskattningar?

– Ska man försöka bli bättre på att göra saker som inte fungerar, blir motfrågan från Woody Zuill.

Hans erfarenhet är att satsningar på att göra bättre uppskattningar leder till att en känsla av att man behöver mer tid på sig i iterationer, för att kunna hantera mer detaljer. Tvåveckors iterationer blir treveckors, fyraveckors och slutligen kanske tremånaders. Till ingen nytta.

Läs också: Du ska vara mångsidig för att bli mobilutvecklare

En kärnpunkt är att uppskattningar har blivit det gängse, eller det enda, verktyget för att leda utvecklingsprojekt. Woody Zuill ifrågasätter varför det är så, när det bevisligen fungerar dåligt.

Finns det hårda fakta som visar att produktiviteten förbättras när uppskattningar undviks? Woody Zuill blir något defensiv när han får den frågan. Han berättar att han har gott om exempel på lyckade projekt som han har varit inblandad i, men att man oftast gjort flera förändringar samtidigt. Det är svårt att veta exakt vad som har bidragit.

Kontentan av hans resonemang är att det handlar om en annorlunda helhetssyn på hur systemutveckling ska bedrivas. Ett stort fel i de flesta projekt är enligt honom att de är för omfattande. Man bör i stället koncentrera sig på de delar som faktiskt ger värde och skapa fungerande mjukvara för dem.

– Som jag ser det krävs det tre saker: en chans att skapa värde, att olika delar hänger ihop och att man har en allmän förståelse för de delar man jobbar med. Då kan man välja att jobba med de delar som faktiskt tillför värde.

I idealfallet hänger de här tre sakerna ihop. En bättre allmän förståelse leder till delar som hänger ihop bättre, vilket i sin tur leder till värde. Och så vidare, man kan kombinera de olika aspekterna på olika sätt.

Allt det här bygger på att mjukvara till skillnad från mycket annat som produceras är föränderliga skapelser.

– Mjukvara är värdefull om den kan förändras och ju mer värdefull den är, desto mer kommer folk att vilja förändra den.

Det synsättet kan tolkas som att man inte bör bedriva utveckling av mjukvara i traditionell projektform. I stället bör man kontinuerligt sträva efter att tillföra värde med ny funktionalitet och se kodbasen som en föränderlig organism.

Och inte minst, slänga kod som inte längre uppfyller ett värde.