Systemutvikling: Glem fossefall - kjør iterativt

Det er ingen enkel oppgave å utvikle it-systemer i dag. Systemet skal brukes i en verden som endrer seg i rasende tempo. I tillegg øker kompleksiteten - både i selve løsningen og i verden omkring. Utviklingsteamene blir større og kravene blir stadig høyere. Ofte får man følelsen av at man skal treffe et mål som stadig flytter seg. Iterativ utvikling møter disse utfordringene på en helt annen måte enn f.eks fossefallsmetoden.

 

---

 

Gode råd for iterative prosjekter

 

•  Dyrk fram en atmosfære preget av tillit og «vi er i samme båt»-mentalitet.
• Prøv med en iterasjonslengde på 4 uker hvis du prøver iterativ utvikling for første gang.
• Automatisert testing er svært nyttig ved iterativ utvikling.
• Bruk gjerne prototyper for å utforske alternativer og bli enige om hvordan løsningen skal se ut.
• Husk at produktet bare er et verktøy - det viktigste er brukerne. Involver organisasjonen og brukerne så mye som mulig.
• Ikke vær redd for endringer. I et iterativt prosjekt er endringsønsker oftest et uttrykk for ny kunnskap.
• Hold iterasjonslengden fast - ikke utsett leveransen pga. forsinkelser, men kutt i omfanget i stedet.
• Ta beslutninger på det seneste ansvarlige tidspunktet. Da har du best informasjon.
• Et team bør bestå av 5-9 medlemmer. Større prosjekter bør deles opp i flere teams med daglige møter mellom teamlederne.

 

---

 

  

Iterativ = gjentagende
Iterativ systemutvikling kjennetegnes ved at man bruker en gjentagende metodologi, med røtter i spiralmodellen, for å sikre et resultat med høyt kvalitetsnivå.

Tradisjonelt er det vanlig å dele et prosjekt inn i faser som resulterer i en endelig produksjonssetting. Man starter med kravhåndtering, fortsetter med design og implementasjon før man prøver å integrere og teste ulike delsystemer. Til slutt setter man forhåpentligvis en løsning i produksjon.

I en iterativ prosess deler man inn prosjektet i iterasjoner som hver for seg er små miniprosjekter. På denne måten begynner man tidlig å lage et produkt og det blir mulig å sette deler av produktet i produksjon for å gi brukerne og virksomheten tidligst mulig avkastning for sin investering.

 

Større fleksibilitet
Hovedfordelen med iterativ systemutvikling er at den tillater stor fleksibilitet.  I tradisjonell programmering, som f.eks. fossefallsmodellen, setter man gjerne kravspesifikasjoner og lignende grunnlag på forhånd. Det medfører ofte store utgifter, når man mot slutten av arbeidsfasen blir nødt til å starte på nytt fordi noen av system-kravene er blitt endret underveis. 

 

Beskriv prosjektet
Begynn med å beskrive prosjektet fra 10 000 meters høyde: Mål, overordnede krav og rammer for tid og budsjett. I forhold til det som er vanlig, bør det brukes mer tid på å finne fram til og beskrive de reelle målene og mindre tid på å beskrive kravene.

Inkludert i målene bør være en beskrivelse og gjerne tall på hvilke gevinster prosjektet forventes å oppnå. Det er vår klare anbefalting at prosjektets suksess bør vurderes mot måloppnåelse, ikke kravoppfyllelse. Kravene bør ikke detaljeres i noen særlig grad, dette gjør du senere i prosjektet når du vet mer om løsningen.

 

Planlegg på et overordnet nivå
Med de overordnede kravene og rammene på plass, utvikler du den overordnede prosjektplanen. Begynn med å grovestimere de overordnede kravene. Grovprioriter deretter kravene basert på verdi, risiko og estimert kost.

En god regel for prioritering er å ta det viktigste først og det vanskeligste tidlig. Deretter grupperer du kravene inn i releaser - leveranser som skal ut til sluttbrukerne.

I prosjekter med litt størrelse bør du planlegge flere leveranser hvert år. Da vil virksomheten få realisert verdi fra prosjektet tidlig og hyppig, og du vil få viktige tilbakemeldinger basert på faktisk bruk av løsningen. Som del av den overordnede planleggingen bestemmer du også hvor mange og hvor lange iterasjoner du skal ha. Husk at en iterasjon er et mini-prosjekt for en begrenset del av løsningen. Det bør være mange iterasjoner per release. En god iterasjonslengde er en til fire uker.

  

Planlegg iterasjonen
Nå er det på tide å begynne første fase eller iterasjon, og den begynner med at kunden og leverandøren sammen lager en iterasjonsplan. Finn først et overordnet mål for iterasjonen, for eksempel «Utvikle helt grunnleggende funksjonalitet for kunde-behandling».  Velg deretter ut krav som skal tilfredsstilles - begynn fra toppen av listen over prioriterte, overordnede krav. Diskuter hva hvert krav innebærer i nok detalj til at leverandøren får god nok forståelse til å skissere mulige løsninger og estimere kravet på nytt. Bestem også hvordan kunden vil teste om kravet er oppfylt. Når det er nok arbeid til å fylle første iterasjon, stopper dere.

 

Gjennomfør iterasjonen
Etter planleggingen gjennomfører du iterasjonen. Løsningen på de utvalgte kravene skal designes, implementeres, testes og leveres. Det er viktig at resultatet av iterasjonen blir en reell leveranse - kjørbar,
testet programkode - som reelle brukere kan prøve ut og evt. ta i bruk. For eksempel kan løsningen i slutten av iterasjonen legges inn i et produksjonslikt testmiljø.

Husk at iterasjonens lengde er fast. Hvis det viser seg at leverandøren ikke klarer å levere alt som var planlagt i iterasjonen, må kunden inn i bildet og redusere omfanget på iterasjonen.

Ikke forleng iterasjonen! Hvis du gjør det, mister du mange av fordelene med iterativ utvikling.

 

Ha et kort møte hver dag
Hver dag samles teamet eller sub-teamet i 15 minutter og hver av teammedlemmene svarer på tre spørsmål: Hva har du gjort siden sist? Hva skal du gjøre til neste gang? Og ikke minst viktig: Hva hindrer deg i å gjøre framdrift? Ved fjerne hindringer vil prosjektets raske framdrift opprettholdes.

 

Reflekter og juster
I slutten av hver iterasjon må dere reflektere over hva dere har lært i forhold til framdrift, produkt og prosess. Finn ut hva som er bra og dårlig, både med løsningen som er laget og med arbeidsformen. Kanskje bør planene justeres, kravene justeres, eller prosessen justeres. Velg ut ett eller to områder hvor dere skal gjøre ting annerledes i neste iterasjon. Slik kontinuerlig prosessforbedring øker sjansene betraktelig for å lage riktig løsning på en effektiv måte.

 

Start neste iterasjon
Når første iterasjon er gjennomført og levert, starter neste iterasjon umiddelbart med planlegging. På dette tidspunktet kan det, i tillegg til krav som skal løses, også ha dukket opp feil som må rettes eller ønsker om endringer eller forbedringer. Disse prioriteres inn på samme måte som nye krav. Ikke vent til slutten av prosjektet med å rette kjente feil.

 

Lever release til brukerne
Etter noen iterasjoner har prosjektet implementert, testet og evaluert den funksjonaliteten som er mest viktig for kunden. En release med denne funksjonaliteten bør nå tas i bruk, enten av alle brukerne eller som en pilot av utvalgte brukere. Ved en release bestemmer kunde og leverandør om prosjektet skal fortsette med nye iterasjoner og nye releaser eller om prosjektet skal avsluttes. Prosjektet avsluttes når kunden ser at det ikke er kostnadseffektivt å implementere flere krav.

  

Noen ord om avtaleutforming
Når prosjekter utføres med to parter må kontrakten gi begge parter incentiv til å gjennomføre og fullføre prosjektet. Avtaler med fast pris og fast omfang fungerer dårlig i denne sammenhengen, fordi de ikke gir kunden incentiv til å være fleksibel i forhold til omfang, krav og tidsbruk. Dessuten krever fastprisavtaler at detaljerte krav og planer lages først, dette bryter med den iterative prosessen.Tilsvarende fungerer avtaler med løpende timer dårlig, fordi de ikke gir leverandøren incentiv til å være effektiv. Det er mange prioriteringer og valg som må tas i løpet av et prosjekt, og avtalen bør gi både kunde og leverandør et felles ansvar for å komme i mål. Det er en fordel om betaling er knyttet til delleveranser. Målprisavtaler kan være et alternativ, og det finnes andre. Dataforeningen har sin PS2000-avtale, og Statskonsult jobber med en avtale tilpasset iterativ utvikling.

  

KONTAKTER
Kjetil Røe, senior prosjektleder
E-post: ktr@steria.no
Tlf. 900 29 921 Faks: 22 57 59 60

Kurt M. Nilsen, senior prosjektleder
E-post: kmn@steria.no
Tlf. 922 59 036 Faks: 22 57 59 60

Trond Wingård, senior prosjektleder
E-post: tw@steria.no
Tlf. 48 13 46 67 Faks: 22 57 59 60

Steria AS, Biskop Gunnerus´ gate 14A,
Pb 2, N- 0051 Oslo