Fossefallsmetoden: Definisjon, prosess & eksempler

Vi lever i en verden der Agile-metodikken er allestedsnærværende. Fra kjente teknologigiganter til små oppstartsbedrifter bruker alle den til å utvikle produktene sine. Når du lærer om Agile, har du kanskje kommet over begrepet «fossefallsmetodikk».

De fleste prosjektledere som bruker Agile, anser fossefallsmetodikken som en utdatert metodikk som ikke lenger har noen funksjon i 2023. Men stemmer det egentlig?

Som senior produktleder har jeg mye erfaring med både Agile og fossefallsmetodikken. Til forsvar for fossefallsmetodikken skal vi se nærmere på hva den er, hvordan den fungerer, og når det er hensiktsmessig å bruke den.

Hva går fossefallsmetodikken for prosjektledelse ut på?

Fossefallsmetodikken innebærer å håndtere utviklingsprosjekter ved å dele dem opp i tydelige faser og gjennomføre hver av dem sekvensielt.

Selv om det å dele store arbeidsmengder opp i mindre deler er et konsept mennesker har brukt siden tidenes morgen, skjedde den formelle «fødselen» til fossefallsmetodikken langt senere – i 1970, da Dr. Winston W. Royce, en fremtredende informatiker på den tiden, beskrev den i boken «Ledelse av utviklingen av store programvaresystemer».

Siden den gang har det vært den viktigste måten programvareselskaper har håndtert prosjektene sine på, frem til verden begynte å gå over til Agile tidlig på 2000-tallet.

Slik ser livssyklusen for programvareutvikling (SDLC) ut med fossefallsmetoden

I motsetning til Agiles iterative og inkrementelle struktur har SDLC for fossefallsmetoden både en tydelig start og slutt. Den deler hele prosessen med å lage programvare inn i fem ulike faser eller milepæler, og arbeidet med én fase starter ikke før den forrige fasen er fullført. Visuelt ser det slik ut:

Arbeidet flyter fra én fase til den neste, før det når bunnen og prosjektet regnes som «fullført» – noe som gjør at det visuelt ligner på en foss (derav navnet).

La oss nå se på hver fase i denne lineære tilnærmingen og forstå hva de innebærer.

Fase 1: Innsamling av krav

Det hele starter med å samle inn kravene til prosjektet fra alle interessenter. I kravfasen utarbeider prosjektlederne et omfattende og svært detaljert dokument som dekker alle aspekter ved prosjektet, fra funksjonelle krav til budsjett- og risikoplan.

Fase 2: Utforming av løsningen

Basert på kravene som ble samlet inn i forrige fase, begynner prosjektteamet å utforme og designe løsningen. Begrepet «design» viser her til produktets tekniske struktur (systemdesign), produktets visuelle utforming og interaksjonsdesign (UI/UX-design), samt den fysiske utformingen (hvis det er et fysisk produkt).

Fase 3: Implementering

Det er nå selve kodingen skjer. Utviklingsteamet ditt begynner å bygge produktet basert på leveransene dere utarbeidet i designfasen.

I motsetning til Agile, der du står fritt til å endre prosjektomfanget og designet kontinuerlig, forutsetter fossefallsmetodikken at du følger designdokumentet og ikke «videreutvikler» produktet under implementeringsfasen.

Fase 4: Testing

Så snart programvareutviklingsteamet har bygget ferdig produktet, kan vi gå videre til neste fase i prosjektplanen – testing. Teamet ditt begynner å kontrollere produktet for eventuelle feil, sikkerhetssvakheter eller problemer med brukeropplevelsen.

I testfasen kontrollerer dere også om funksjonaliteten og designet til det endelige produktet samsvarer med kravdokumentene for prosjektet som dere utarbeidet i løpet av de to første fasene.

Fase 5: Distribusjon og støtte etter lansering

Hvis teamet ditt har funnet og løst alle de vesentlige problemene med produktet, er det på tide å lansere det og overlevere løsningen til kundene og sluttbrukerne dine. 

Programmererne dine går nå videre til vedlikeholdsfasen ved kontinuerlig å samle inn tilbakemeldinger fra kundene, gjøre de nødvendige rettingene og utgi nye feilrettinger og oppdateringer av produktet.

Det var det – prosjektet er fullført, og du kan gå videre til det neste!

Bør du altså bruke fossefallsmetoden?

Hvis du, den Agile-orienterte prosjektlederen (i hvert fall antar jeg det), mener at denne metodikken er utdatert og at du aldri bør vurdere å bruke den, er jeg (med all respekt) uenig med deg. Jeg vil hevde at fossefallstilnærmingen faktisk er det beste valget for bestemte typer prosjekter.

La meg gå gjennom et par eksempler med deg for å underbygge poenget mitt.

Casestudier: Vannfallsmetoden i praksis

Som med alle komplekse konsepter kan noen konkrete eksempler være nyttige for å forstå hvordan metoden fungerer i virkeligheten. Her er derfor noen eksempler basert på virkelige prosjekter (som jeg kanskje har jobbet med selv, eller kanskje ikke) for å hjelpe deg med å få et tydelig bilde av hvordan vannfallstilnærmingen fungerer i praksis.

Eksempel nr. 1: En plattform for fortolling for Egypts regjering

Se for deg at du er en del av et selskap som har vunnet kontrakten om å modernisere systemene for internasjonal handel og fortolling i et relativt stort land, for eksempel Egypt.

Det den egyptiske regjeringen ønsker, er et system for havnemyndighetene som skal håndtere alle skipsmanifestene (et tolldokument som inneholder informasjon om all lasten og alle passasjerene om bord på skipet) som kommer inn til de ulike havnene i Egypt.

I tillegg ønsker de at dette systemet skal integreres direkte med et annet produkt de vil at du skal bygge, som skal håndtere alle tolldeklarasjonene (også kalt SAD-er eller administrative enhetsdokumenter) i landet. Skjemaet er ganske komplisert for vanlige mennesker å fylle ut, så de vil at du skal automatisere det for dem.

Egypt har et komplekst system for skattlegging og tollavgifter som endrer satsene basert på typen varer du importerer, mengden og andre faktorer. Ettersom vanlige borgere ikke har peiling på disse satsene, ønsker den egyptiske regjeringen at appen din automatisk skal beregne alt for innbyggerne basert på det de har deklarert, og la dem betale på nettet med kredittkortene sine.

Dette virker som en enorm oppgave, gjør det ikke? Når detaljene i gjennomføringen skal ferdigstilles, vil ledelsen din (og kanskje til og med den egyptiske regjeringen) komme til deg, prosjektlederen, og spørre hvordan du ønsker å organisere gjennomføringen av dette prosjektet.

Hvorfor og hvordan du bør bruke vannfallsmetoden i dette scenarioet:

Alt du bygger for en nasjonal regjering, vil mest sannsynlig være basert på en lov eller et vedtak som parlamentet har ratifisert. Disse vedtakene vil omfatte alt fra prosjektets generelle betingelser (for eksempel kostnad og tidsplan) til de minste detaljene om hvordan alt skal fungere.

Det høres ut og ser ut som et kravdokument fra den første fasen i vannfallsmodellen, ikke sant? Det gjør det faktisk, og det betyr også at du ikke egentlig kan endre detaljer i gjennomføringen, designet og kravene underveis slik man gjør i smidig programvareutvikling.

Jeg har tidligere ledet et slikt produkt. En dag innså vi at vi kunne forbedre brukeropplevelsen betydelig ved å gjøre et par mindre justeringer i forretningslogikken. Vi delte umiddelbart ideen vår med representanten for tollmyndighetene som jobbet sammen med oss.

Vel, han sa nei. Du skulle kanskje tro at det var en dårlig idé å avslå et slikt tilbud, men han hadde en god grunn til at de ikke kunne gjøre det.

De små justeringene våre ville innebære en endring i formelen regjeringen brukte til å beregne skatter for et bestemt produkt. Formelen var fastsatt i loven, så å endre den ville innebære å samle hele nasjonalforsamlingen og stemme over den.

Eksempel nr. 2: Flystyringssystemet til Ingenuity-helikopteret

Ingenuity er navnet NASA ga det høyteknologiske helikopteret de bygde og sendte til Mars i 2021. Slik ser den lille krabaten ut.

Se for deg at du var en heldig prosjektleder som hadde ansvaret for å utvikle programvaren til denne utrolige teknologien. Teamet ditt måtte spesielt skrive koden som skulle styre helikopterets flyging.

Det er svært vanskelig å lage et flystyringssystem for et luftfartøy (spesielt et helikopter). Du må ta hensyn til alle fysikkens lover som påvirker luftfartøyet under flyging, og beregne den nødvendige rotasjonshastigheten til rotorbladene, bladvinkelen og en million andre ting.

Men oppgaven din er enda mer kompleks. Helikopteret ditt må fly over overflaten til en annen planet med en atmosfære som er 100 ganger mindre tett enn den vi har på jorden.

Hvorfor og hvordan du bør bruke vannfallsmetoden i dette scenarioet:

Etter min mening er vannfallsutvikling det eneste alternativet ditt her. I motsetning til smidig prosjektledelse, der du bygger noe lite (minimumsproduktet ditt), tar det i bruk, bruker det i virkeligheten, samler inn tilbakemeldinger og gradvis forbedrer løsningen basert på disse tilbakemeldingene, er innsatsen altfor stor i et prosjekt som dette.

Kan du virkelig risikere å lage en feilfylt MVP av Ingenuity og fly den 140 millioner miles til Mars? Det finnes ingen mulighet for at noen ville gått med på det.

Så du må bygge den endelige versjonen av den og deretter teste alle systemene grundig før du har den nødvendige tilliten til å plassere den i en rakett som skal fly til den røde planeten.

Fossefallsmodellen lever i beste velgående!

Faktisk er den langt mer populær enn du kanskje hadde forventet, med halvparten av alle prosjekter over hele verden som fortsatt bruker denne utviklingsmetodikken.

Selv om fremveksten av smidig utvikling har gjort verden til et bedre sted for mange prosjektledere ved å la dem lansere produkter langt tidligere og bygge videre på tilbakemeldingene fra brukerne, er fossefallsmodellen fortsatt en svært verdifull metodikk som du kan bruke i prosjekter med begrenset fleksibilitet og liten toleranse for feil.

Jeg håper du likte gjennomgangen vår av fossefallsmetodikken. Hvis du også vil lese litt mer om smidig utvikling, er dette det jeg kan anbefale:

• Guiden vår om smidig produktstyring.
• Samlingen vår av beste praksiser for smidig porteføljestyring.
• Den kuraterte listen vår over de beste verktøyene for smidig produktstyring.

Dette er bare tre av de mange guidene og artiklene vi har om produkt- og prosjektstyring. Hvis du vil lese mer, kan du abonnere på nyhetsbrevet vårt.