En tiger på tanken

En tiger på tanken

Scrum passer utmerket for intern utvikling, men er metodikken like godt egnet i leveranser der store penger skal skifte hånd?

Scrum er i vinden, den mest populære blant smidige utviklingsmodeller. Vi vet at metodikken passer utmerket for intern utvikling, for eksempel produktutvikling, der utviklere og bestillere kommer fra samme organisasjon. Et mer interessant spørsmål er om Scrum er like godt egnet i leveranser der store penger skal skifte hånd - kunden skal kjøpe og leverandøren skal levere.

Hvorfor er spørsmålet interessant? Fordi i vanlige leveransekontrakter blir kunden og leverandøren enige om hva som skal leveres når kontrakten blir inngått. Kunden vil ikke kjøpe før leveransens omfang og rekkefølge er fastlagt i detalj.

Man inngår ikke en millionavtale med å begynne å jobbe sammen og finne vi ut av målet etterhvert. Som oftest betyr millionavtaler at kunden utarbeider en detaljert kravspesifikasjon som, etter mange runder av forfining, forplikter leverandøren til å levere.

Det er kolossalt krevende å utarbeide en detaljert kravspesifikasjon. Å starte når alle krav er detaljert beskrevet, kaller vi ofte fossefallsmetoden. Først krav, så design, så utvikling, så testing og tilslutt leveranse. Kunden får ingenting helt til han får alt – det er modellen.

Fossefall-fiksjon

De fleste utviklingsmiljøer er enige om at fossefall er en fiksjon. Kunder klarer ikke i forkant å spesifisere mer enn ca 70 prosent av hva de skal ha. Resten kommer etter hvert. Både kunde og leverandør lærer og erfarer, tidene skifter, veien blir til mens de går.

Denne erkjennelsen har resultert i de såkalte iterative metoder (som RUP) der leveranseprosjektet blir delt opp i noen delleveranser, og etter hver delleveranse stopper man opp og blir enige om justeringer av det resterende løpet.

Det har vist seg at iterative modeller treffer målet bedre. Dessuten får kunden leveranser underveis istedenfor å måtte vente helt til den store dagen.

Omtrent hvert femte utviklingsprosjekt blir avbrutt underveis, av forskjellige grunner. Da er vanligvis over halvparten av de avsatte pengene oppbrukt. Med fossefallsmetoden sitter kunden igjen med null verdi etter et eventuelt brudd. Iterative modeller leverer i hvert fall noe som kan utnyttes. Er planene riktig lagt, bringer delleveranser mye av verdien.

PS2000

Dataforeningen har utarbeidet en standardkontrakt for å understøtte den iterative tankegangen for utvikling. Den kalles PS2000, foreligger i sin tredje versjon og er alminnelig brukt i Norge, spesielt i offentlig sektor.

Smidig utvikling, basert på Scrum eller andre modeller, er toppen av iterativ utvikling. Den store forskjellen til RUP og dens slektninger er at Scrum forutsetter mange korte iterasjoner, kalt sprint. En sprint varer typisk i fire uker. "Hyppige leveranser" er slagordet her. Jo mer kunden tar i bruk, desto raskere blir eventuelle feil og misforståelser ryddet av veien.

I store prosjekter som inneholder flere parallelle løp og varer i flere år, blir det mange sprinter. I motsetning til hva mange tror er Scrum ikke ustrukturert, tvert imot skal det legges mye planlegningsdisiplin i spillet.

En faggruppe i Dataforeningen har stilt seg spørsmålet: Kan PS2000 kontraktsstandarden benyttes hvis Scrum, ikke RUP, er valgt som modell? Jeg er medlem i gruppen, myndig ledet av Kjetil Strand fra Promis, som for noen dager siden leverte rapporten "Smidig utvikling med PS2000 – en veileder". Der blir tankegang og praksis detaljert gjennomgått. Konklusjonen er at PS2000, med et par enkle grep, egner seg godt som underlag.

Rugby

Det er ikke rart at smidig utvikling er i vinden. En grunn er at utvikling betyr å lage noe nytt, derfor har nye konsepter alltid fenget utviklere. Scrum er annerledes, et friskt pust. En annen er at Scrums sprinter og tette kontakt mellom bestillere og utviklere har noe umiskjennelig macho over seg.

Tøffe typer kaster ikke bort tiden, de spiller hardt. (Selve begrepet Scrum er hentet fra amerikansk rugby, det skjer når dommeren setter spillet i gang igjen etter en avbrytelse. Der står gutta, tett i tett over ballen, foroverbøyd med svulmende muskler og svære skulderputer. Ikke noen frøkensport, nei.)

Å velge Scrum som utviklingsmodell er et strategisk valg som må tenkes grundig gjennom. Det forutsetter at kunden har tillit til leverandøren. Kunden stoler på at leverandøren vil levere det kunden har mest nytte av, ikke akkurat det som er avtalt i utgangspunktet. Skal gevinstene materialisere seg, må kunden delta meget aktivt i arbeidet.

Det kan bli litt av et kultursjokk for dem. Det er ikke alle kunder som har kultur (eller mage) for sånt, mange kunderepresentanter er fornøyde hvis de får levert det de trodde de behøvde da arbeidet startet. Da blir de i hvert fall ikke hengt.

hidas@online.no

Les om: