Så hvilken metode skal man velge?

Vi har fortalt om strukturerte metoder og agile metoder - her vil vi fortsette å bruke eksemplene fra tidligere, men heller fokusere på hva som er positivt og negativt ved hver metode. Ingen metoder er universelle, og derfor vil vi bruke den ene over den andre i visse situasjoner. Det som vi ønsker å gå nærmere inn på er akkurat hvilken metode som er best til hva - og hvorfor.

Under lister vi opp noen eksempler på fordeler og ulemper i de forskjellige metode-typene. Vi ser i denne delen vekk fra muligheten til å tilpasse metoden til prosjektet, og fokuserer på ren Fossefall- og SCRUM-metode.

Agile/Scrum pros & cons

Strukturert/Fossefall pros & cons

Oppsummering SCRUM

Iterativ utvikling, stegene repeteres.

Denne metoden egner seg til prosjekter som trenger høyt tempo og muligheten for å snu på hælen. Det er større valgfrihet og mulighet til å bidra, da alle kan foreslå funksjoner til Product Backlog, og man har større frihet til å velge oppgaver selv ut fra tidligere utformede mål.

Man får hurtig sett første utkast til produktet, gjerne innenfor første måneden av prosjektet. Nettopp på grunnlag av denne egenskapen, så passer metoden til bruk i IT-utvikling, og f.eks markedsføring. I begge disse feltene har vi behov for å kunne snu raskt, legge til/fjerne funksjoner eller tilpasse oss en ny trend i markedet. Å bruke en agil metode slik som SCRUM krever disiplin og kommunikasjon - om kommunikasjonen skulle være for dårlig så vil tidsrammen til prosjektet bli forlenget.

Oppsummering Fossefall

Inkrementell utvikling, steg-til steg.

Da produktet blir planlagt, designet og utformet tidlig i prosessen, kan vi dermed sikre oss for logiske feil i kode. Derfor egner det seg til sikkerhetsmessige prosjekter, hvor vi må vite at produktet “fungerer” før vi har det.

Det egner seg også til prosjekter hvor det ikke er stor risiko for forandring i teknologi/standarder, slik som byggeprosjekter og lignende. En bonus her er at tidsrammen er enklere å beregne, da man har produktet og planen klar før utviklingen starter. Alle har en satt plan for hva de skal gjøre ila. prosjektet, og det er liten sannsynlighet for at en funksjon har overlappende kode fra 2 team. Samtidig er det liten kreativ frihet, og det er krav til nøye dokumentasjon.

Så hva skal man velge?

For oss impliserer det vi har lært om metodekategoriene og metodene i seg selv at agile metoder er hovedsakelig anbefalt for prosjekter innen IT- og utvikling. Dette kommer av den store fleksibiliteten, og enkel mulighet for å endre prosjektplan underveis. I andre prosjekter hvor produktet er noe mer permanent og ikke lett foranderlig, slik som i byggebransjen, kan det være gunstig å bruke Fossefallmetoden.