Det tar tid å lage programvare. For lang tid får vi ofte høre, vi som driver med slikt. Av og til syns vi det sjøl, også. Vi lever i balansen mellom å lage det skikkelig med en gang og å få levert i tide. Slikt sett er det ikke så forskjellig fra andre yrker. Men en forskjell er at programvare utvikles inkrementelt og leveres i mer og mer ferdige versjoner. Feil må rettes og funksjonalitet må inn eller forandres. Kompleksiteten er høy og fallgruvene mange.

Det finnes forskjellige metodikker for å designe og skrive programvare. Uansett hvilken man velger så må man forholde seg til kravet om å bli ferdig. En gitt funksjonalitet skal til slutt med.

Men underveis, kan det tenkes at det gjør noe med resultatet å la funksjonaliteten skli i stedet for datoen? Et alternativ til å levere mellomresultat med en gitt funksjonalitet (og ofte for sent), er å levere til avtalt tid (men uten alt).

I det prosjektet jeg jobber i nå har vi prøvd dette en stund. Vi har en liste over punkt som før eller senere skal tas, og vi leverer det vi rekker. Et dokument beskriver akkurat hva vi fikk med, og hva som er i gjære. Noe er i alle fall nytt. Noen feil er i alle fall rettet. Men datoen holdes. Likevel prøver vi å få med mest mulig, for vi vet det endelige målet.

På veggen henger et gruppebilde av laget vårt. Under, en kalender med et par-tre måneder brettet ut. Her merker vi tydelig av Datoen og Versjonsnummeret for neste release. Alt dette er godt synlig. For oss. Og sjefene, med stigende tiltro til det vi driver med. Det er viktig at vi til slutt og i tide leverer det vi skal. Likevel kjennes det ikke som om vi spiller høyt. Og det er godt å kunne jobbe mot sikre leveranser, og se programvaren modnes gjennom mange, beståtte leveringer.


Opp - Se TU (Layouten ovenfor er mer komprimert)
og TU nr. 15, mai 2006, side 71