Ikke alle kan sverge til Smidig

Stadig flere velger smidige metodikker som Scrum og Agile når det skal utvikles programvare. Den før rådende Fossefallsmetoden - hvor utviklerne forholder seg til ferdig definert funksjonalitet som skal implementeres på tid og kost - må vike for en utviklingsprosess hvor kreativitet er satt i høysetet.

Hvorvidt man ender opp med et produkt som ligner det kunden eller egen organisasjon har sett for seg, er ikke like viktig. Tesen er at kvaliteten på det som faktisk leveres uansett blir bedre.

Rom

Det er lett å forstå at dette er en utviklingsmetodikk som gjør det mer interessant å være utvikler. Det gir stort rom for å finne de smarte løsningene og forfølge egne innfall. Men spørsmålet er selvsagt om Smidig metodikk gir et resultat bestiller av løsningen er fornøyd med. Ikke alltid, er nok svaret på det.

Det krever mot å sette bort utvikling til et smidig programmeringsteam. Som bestiller har du da akseptert at du kanskje ikke får det du har bestilt. Kanskje får du noe bedre, men kanskje får du også noe dårligere. Med dette som utgangspunkt er det litt overraskende at Smidig har fått så stor utbredelse.

Overtalelsesevner

Særlig i offentlig sektor - hvor anbudsprosessen setter strenge krav til kvalitetssikring av sluttproduktet - skulle man tro at en slik utviklingsmetodikk var lite kompatibel. Når det likevel i dag sporadisk benyttes smidig metodikk i offentlige it-prosjekter, er det et godt bilde på smidig-evangelistenes overtalelsesevner - som åpenbart er betydelige.

Som alltid når it-bransjen krangler om hvilken teknologi, programvare eller metodikk som er best, ligger ikke svaret i ytterpunktene. Ganske sikkert er smidige utviklingsmetoder kommet for å bli, men de kommer ikke til å ta livet av de tradisjonelle metodene. Derimot vil vi se at det i ulike prosjekter vil velges ulike metodikker - ut fra hva som er mest formålstjenelig for både kunde og utvikler. Det betyr et nytt verktøy i verktøykassa for å sikre at resultatet blir best mulig. Og det trengs jo...