Hva er forskjellen på smidig utvikling og fossefallsmetoden? Og når bør du styre prosjektet ditt ved hjelp av den ene metoden fremfor den andre?

Dette er et gjesteinnlegg fra partneren vår, Netmaking

Fossefall

Fossefallsmetoden, også kjent som sekvensiell, er den tradisjonelle måten å styre programvareprosjekter.

Flyt

  1. Produkteieren presenterer en komplett kravspesifikasjon. Denne kan produkteieren ha utarbeidet selv, eller den kan ha blitt utarbeidet av noen andre.
  2. Leverandøren estimerer kostnader og tidsbruk for å implementere systemet i henhold til kravene.
  3. Produkteieren vurderer estimatet.
  4. Hvis produkteieren godtar estimatet utvikler leverandøren systemet, inkludert design, dokumentasjon og kvalitetskontroll. Hvis ikke produkteieren godtar estimatet kan stegene 1-3 gjentas.
  5. Det ferdige systemet gjøres tilgjengelig for brukerne, for eksempel på en webserver.

Fordeler

Den sekvensielle metoden gir produkteieren et estimat både over kostnader og lanseringsdato før implementeringen påbegynnes. Dette letter planleggingen for produkteieren. For øvrig krever metoden minimal innsats fra produkteier i implementeringsfasen, ettersom alle kravene er ferdig spesifisert.

Ulemper

Kravspesifikasjonen og estimatene utarbeides på det tidspunktet alle vet minst om prosjektet: før utviklingen påbegynnes. Man lærer typisk mye underveis i utviklingsprosessen – ukjente muligheter og problemer oppdages, og prioriteter og forutsetninger endrer seg. Den sekvensielle metoden legger ikke godt til rette for å benytte den nye kunnskapen.

Ettersom relativt lite er kjent når man spesifiserer og estimerer er det betydelig risiko for at både spesifikasjon og estimat inneholder betydelige feil, unøyaktigheter og mangler. Jo større og mer komplekst systemet er, desto større blir disse ulempene.

Som regel kan systemet ha en verdi for brukerne også før det tilfredsstiller alle kravene. Ettersom systemet ikke lanseres før alle kravene er tilfredsstilt går man glipp av denne verdien.

Smidig

Som en reaksjon på ulempene ved tradisjonell prosjektstyring begynte smidige prosjektstyringsmetoder å gjøre seg gjeldende på syttitallet.

Generelt innebærer en smidig prosess å kontinuerlig legge til, fjerne, prioritere og implementere ulike krav.

Etter et visst punkt (når systemet tilfredsstiller noen minimumskrav) gjøres forbedringer kontinuerlig tilgjengelig for brukerne.

Flyt

  1. Oppgaver legges i liste som inneholder all ønsket funksjonalitet.
  2. Produkteieren bestemmer i hvilken rekkefølge oppgavene skal løses.
  3. Oppgavene estimeres av leverandøren, og produkteieren oppdaterer eventuelt rekkefølgen i lys av denne nye informasjonen.
  4. Leverandøren løser oppgavene i rekkefølgen produkteieren har valgt, inkludert design, dokumentasjon, lansering, etc.
  5. Stegene 1-4 gjentas.

Fordeler

Smidige metoder reduserer risiko og øker kvaliteten ved å muliggjøre læring og endring underveis i utviklingen. Når partene samarbeider tettere underveis kan prioriteringer endre seg og ny kunnskap tas med i beregningen. Som regel bedres den gjensidige tilliten i denne prosessen.

Ettersom nye funksjoner og forbedret eksisterende funksjonalitet kontinuerlig lanseres kan systemet hurtig skape verdi for brukerne.

Ulemper

Produkteieren må være involvert under utviklingen, noe som kan ta en del tid.

Ettersom produkteier kan justere prosjektets omfang underveis (målet er bevegelig) kan ikke leverandøren forplikte seg til å levere i henhold til den opprinnelige spesifikasjonen. Men leverandøren kan forplikte seg til å holde et visst kvalitetsnivå og til å levere et visst antall effektive arbeidstimer med et visst tempo.

Hvilken bør du velge?

I Netmaking styrer vi noen prosjekter sekvensielt og noen smidig. Generelt anbefaler vi en smidig tilnærming med høy involveringsgrad fra kunden, slik at vi sammen oppnår en løsning som i størst mulig grad oppnår målene med prosjektet. Dette forutsetter imidlertid at produkteier  har mulighet til og ønske om å være involvert i utviklingsprosessen.

Load Comments
loading...