Agil mjukvaruutveckling på beställarnas villkor – ett hederligt gammalt tågluffarkort

Först: Vad betyder ”agil mjukvaruutvecklingsmetod”?

 

Mjukvaruutveckling är ett annat ord för att ”bygga ett datorprogram”. Att bygga ett datorprogram är som att bygga ett hus. Man börjar med diffusa drömmar, skisser, krav och en ritning. Man bestämmer en dag långt fram i tiden (ofta flera år) när allt ska vara klart. När man sedan träffas på den överenskomna dagen för att kontrollera bygget är ingenting som man hade tänkt sig. Det är fel och försenat och för dyrt. Allt slutar med bråk och inte sällan rättegång. Det finns många exempel på havererade utvecklingsprojekt som blivit oerhört kostsamma. Försäkringskassans införande av sitt nya affärssystem i miljardklassen kostade nästan tre gånger mer än budgeterat[1]. Många skyller haverierna på fyrkantiga kontrakt. IT-branchen har länge varit tydliga i sitt budskap: ”Ett datorprogram är en levande organsim och ingen byggsats som kan monteras ihop efter färdiga ritningar”.  Bland annat för att komma till rätta med sådana problem har agila utvecklingsmetoder vuxit fram.

 

När man är ”agil” är man ”lättrörlig”. Beställaren och utvecklarna samarbetar nära under hela utvecklingstiden[2]. Man låser sig inte vid ett visst slutresultat utan kan under resans gång förändra beskrivningen av hur datorprogrammet ska fungera och se ut när det blir klart. När man kommer fram till den magiska dagen då allt ska vara färdigt, ser datorprogrammet inte ut som du hade tänkt från början, det är mycket bättre och det blev billigare och färdigt i tid.

 

Jag så är det om man får tro utvecklarna. Beställarna är emellertid mer skeptiska. ”Vi vill veta vad vi får för pengarna” och ”Jag företräder en myndighet och kan inte upphandla något enligt Lagen om offentlig upphandling (LOU) om vi inte vet vad det är vi ska köpa” och ”jojo, de säger agil mjukvaruutveckling, sen blir det löpande räkning, fikonspråk och extrafakturor”.

 

Är det omöjligt att skapa ett agilt kontrakt som beställarna känner sig trygga med och som kan användas som utgångspunkt för upphandling under LOU? 

 

Jo, det är möjligt!

 

Traditionell mjukvaruutveckling är som direkttåget mellan två storstäder – När man bestämt sig för vart man ska och dörrarna stängts går det inte att ångra sig. Agil mjukvaruutveckling på utvecklarnas villkor riskerar å andra sidan att bli som en taxiresa – Du kan ändra dig hur mycket som helst, stanna och fika och diskutera olika vägar som leder till ditt slutmål men när du väl är framme vill du inte veta vad som står på taxametern.

Agil mjukvaruutveckling på beställarnas villkor är ett mellanting mellan direkttåget och taxiresan som kanske bäst kan liknas vid det gamla hedliga tågluffarkortet – Fast pris, fast slutdag och många korta resor med utvärdering emellan.

 

Kontraktet ska bygga på fastpris, en låst kravspecifikation och delleveranser med korta leveranstider (10-30 dagar). Kravspecifikationen ska låsas upp efter varje godkänd delleverans och parterna ska aktivt ”stuva om” i framtida arbete, dvs. att lägga till och dra ifrån specificerad funktionalitet och omprioritera i vilken ordning specificerade egenskaper och funktionalitet ska levereras. Förändringarna av de framtida arbetena ska göras utan att priset ökar väsentligt eller att datorprogrammet inte blir helt annorlunda eller blir försenat. Utvecklarna ska ha sådan ordning på sitt arbete att en ny utvecklare ska kunna ta över arbetet med kort inskolning. Att beställaren faktiskt har förutsättningar att byta ut utvecklarna med kort varsel blir ett påtryckningsmedel för att projektet inte ska svälla ut till ett ”löpanderäkningsuppdrag” utan förutsebarhet och kontroll.

 

Många utvecklare skulle tycka att ovanstående villkor är för tuffa, signalerar bristande förtroende och kommer att leda till ett dåligt samarbetsklimat. Problemet är emellertid att väldigt få beställare, särskilt i den offentliga sektorn, är intresserade eller ens har legala möjligheter att gå in i allt för oförutsebara projekt. De agila kontrakten är oerhört värdefulla men de måste styras upp för att bli attraktiva för beställarna.



[1] http://www.idg.se/2.1085/1.175240/forsakringskassan-bloder-hundratals-miljoner

[2] http://sv.wikipedia.org/wiki/Agil_systemutveckling

  • http://ellnestam.wordpress.com Ola Ellnestam

    Jag gillar bloggen, speciellt att få en annan vinkel och ditt (advokat)perspektiv. Sedan gillar jag ju teatermetaforen mer än byggmetaforen, kanske för att den känns så verkligt när du själv använder den.

    Efter att ha reflekterat lite extra över varför programvarusatsningar går överstyr så undrar jag om det också kan bero på att ‘allt är möjligt’. Dvs, processen är så kreativ och kaotisk att när man väl satt igång den är den svår att stoppa?

    Det är väl kanske här ramarna, som inkluderar avtal, har sin verkliga plats. De kan fungera som påminnelser om var man är på väg och i värsta fall något man plockar fram när det gått helsnett?

  • Pingback: Skriva som projekt | Bakom tangenterna