Utfor eller svingstang

Utfor eller svingstang

Utviklingsprosjekter blir planlagt ut fra to modeller: Fossefall eller iterasjoner. Hvilken er best?
Vi må ha en modell, da er det er godt at det bare finnes to å velge mellom. Fossefallsmodellen har vært med oss fra it-tidenes morgen. Den går ut på å planlegge prosjektet i en sekvens av faser, der hver fase overleverer sine resultater til den neste. Først spesifiserer vi kravene, så analyserer vi detaljene, konstruerer løsningen, programmerer, tester og til slutt setter vi i gang. Som i en foss går vi aldri oppover, bare nedover.

Men: Klarer vi virkelig å spesifisere kravene i begynnelsen av prosjektet? Erfaringene viser at det gjør vi ikke. Vi klarer kanskje 75 prosent, mens resten åpenbarer seg etterhvert. Krav avføder nye krav. Å gjennomføre et større prosjekt har mye læring i seg. Mye av innsatsen er bortkastet hvis hver fase skal avsluttes innen den neste starter. Altfor sent, når resultatet er der, ser vi hvordan vi skulle gjort det.

Brukbar presisjon

Tanken bak fossefall er at hvis vi kjenner kravene, vet vi omfanget, dvs at da kan vi anslå tidsforbruk og kostnader med brukbar presisjon. Tilbudsforespørsler pleier derfor å inneholde bunker med detaljerte krav. Sannheten er at ikke alle krav er kjent i starten og en del av dem endrer seg mens prosjektet pågår. Å tro at kravene lar seg beskrive til å begynne med er en illusjon.

Fossefall kan være bra for visse prosjekter, men fordelene ser vi sjelden. Vanligvis blir spesifisering, analyse og design unnagjort i en fei til bildet er blitt passe klart. Så går vi i gang med å kode, kode, kode og deretter tester vi og retter feil til krampa tar oss. Testfasen blir gjerne kjempelang. Mens feil blir rettet, blir nye feil oppdaget. Derfor gjenstår det alltid mange feil å rette. På et eller annet tidspunkt må systemet settes i produksjon, resten av feilene retter vi (kanskje) etterpå.

Alternativet

Derfor er alternativet, den iterative modellen, blitt populær. Tanken her er at utviklingen skal skje i iterasjoner eller runder. Først spesifiserer vi de viktigste kravene, konstruerer en løsning for dem, utvikler løsningen og tester den i praksis. Ingen endringer i krav får forstyrre, det kommer siden. Mens dette pågår har vi lært en masse, så da er vi klare til å ta fatt på de krav som ikke var med i første runden eller som har endret seg. Nå skal de inkluderes.

Den mest brukte standardkontrakten for utviklingsprosjekter i Norge, Dataforeningens PS2000, er basert på iterativ utvikling. Det er et par metodikker som er vanlig brukt i arbeidet: Rational Unified Process og Dynamic Systems Development Methodology. RUP er populært fordi det gir god støtte til utviklerne gjennom språket Unified Modeling Language.

Iterativ utvikling er definitivt en bedre idé enn fossefall, men det blir altfor sjelden brukt slik det var tenkt. Problemet er tiden. Leveransetidspunktet er som oftest fastsatt ved prosjektstart, og da blir det ikke tid til å gjennomføre så mange iterasjoner. Ofte blir det bare én ordentlig iterasjon, dvs at modellen degenererer til pseudo-fossefall. Skal den iterative modellen virke bra, kan ikke sluttpunktet fastsettes før vi kjenner materien til bunns. I hvert fall må én iterasjon være avsluttet, så vi har erfaringer å basere oss på. Men det får utviklerne nesten aldri lov til, virkeligheten trenger seg på.

Enkelt svar

Erkjenner vi dette, er svaret lett. Tid og kostnader er gitt før prosjektet starter. Det finnes én parameter til - omfang. Hvis tid og kostnad er gitt, har vi bare styring med omfanget. Utviklernes målsetning må da være å tilfredsstille så mange krav som mulig, og helst de viktigste. Levere så mye verdi som de kan innen de gitte rammer. Det forutsetter stor tillit mellom utviklere og bestillere (ofte en mangelvare). Sammen må de to partene bli enige om hvilke krav som skal realiseres. De må sette opp og vedlikeholde en liste, det viktigste felles styringsinstrumentet, med alle krav i prioritert orden. Noen kaller slike lister MOSCOW: Must, Should, Could, Won´t. Huskeregelen kan også være sydafrikansk, Mbeki: Må, Bør, Kan, Ikke mulig. Hvis det skjer noe høyt oppe på listen, må alltid noe annet vike. Kravene langt ned på lista vil aldri bli realisert, men det gjør ikke så mye. Mer er ikke alltid bedre.

hidas@online.no