Vi lever i en verden, hvor Agile-metoden er allestedsnærværende. Fra berømte teknologigiganter til små startups bruger alle den til at bygge deres produkter. Når du lærer om Agile, er du måske stødt på begrebet "vandfaldsmetoden".
De fleste projektledere, der bruger Agile, betragter vandfaldsmetoden som en forældet metode, der ikke længere tjener noget formål i 2023. Men er det virkelig sandt?
Som seniorproduktchef har jeg stor erfaring med både Agile og vandfaldsmetoden. Til forsvar for vandfaldsmetoden vil jeg gå i dybden med, hvad den er, hvordan den fungerer, og hvornår det er hensigtsmæssigt at bruge den.
Hvad går vandfaldsmetoden inden for projektledelse ud på?
Vandfaldsmetoden repræsenterer konceptet med at styre udviklingsprojekter ved at opdele dem i særskilte faser og håndtere hver fase sekventielt.
Selvom det at opdele store arbejdsopgaver i mindre dele er et koncept, som mennesker har brugt siden tidernes morgen, fandt den formelle “fødsel” af vandfaldsmetoden sted langt senere – i 1970, da dr. Winston W. Royce, en fremtrædende datalog på den tid, beskrev den i sin bog “Managing the Development of Large Software Systems”.
Siden da er den blevet den primære måde, hvorpå softwarevirksomheder har styret deres projekter, indtil verden begyndte at hælde mod Agile i begyndelsen af 2000'erne.
Sådan ser softwareudviklingens livscyklus (SDLC) ud med vandfaldsmetoden
I modsætning til Agiles iterative og inkrementelle struktur har SDLC'en for vandfaldsmetoden både en tydelig begyndelse og afslutning. Den opdeler hele processen med at skabe software i fem forskellige faser eller milepæle, og arbejdet i én fase begynder ikke, før den foregående fase er afsluttet. Visuelt ser det sådan ud:
Arbejdet flyder fra den ene fase til den næste, hvorefter det når bunden, og projektet betragtes som “afsluttet” – hvilket visuelt minder om et vandfald (deraf betegnelsen).
Lad os nu se nærmere på hver fase i denne lineære tilgang og forstå, hvad de går ud på.
Fase 1: Indsamling af krav
Det hele begynder med at indsamle projektets krav fra alle interessenter. I kravfasen udarbejder projektlederne et omfattende og meget detaljeret dokument, der dækker alle aspekter af projektet, fra funktionelle krav til budget- og risikoplan.
Have an account? Log In
Fase 2: Løsningsdesign
Med udgangspunkt i de krav, der blev indsamlet i den foregående fase, begynder projektteamet at formulere og designe løsningen. Begrebet “design” henviser her til produktets tekniske struktur (systemdesign), produktets visuelle design og interaktionsdesign (UI/UX-design) samt det fysiske design (hvis der er tale om et fysisk produkt).
Fase 3: Implementering
Det er her, selve kodningen finder sted. Medlemmerne af dit udviklingsteam begynder at bygge produktet baseret på de leverancer, du har skabt i designfasen.
I modsætning til Agile, hvor du frit kan ændre projektets omfang og design løbende, forudsætter vandfaldsmetoden, at du følger designdokumentet og ikke “udvikler” dit produkt under implementeringsfasen.
Fase 4: Test
Så snart softwareudviklingsteamet er færdigt med at bygge produktet, kan vi gå videre til næste fase i vores projektplan – test. Dit team begynder at kontrollere produktet for fejl, sikkerhedsbrister eller problemer med brugeroplevelsen.
Under testfasen kontrollerer du også, om det endelige produkts funktionalitet og design stemmer overens med de projektdokumenter med krav, som du udarbejdede under de to første faser.
Fase 5: Implementering og support efter udgivelsen
Hvis dit team har fundet og løst alle væsentlige problemer med produktet, er det tid til at udgive det og overdrage løsningen til dine kunder og slutbrugere.
Dine programmører går nu videre til vedligeholdelsesfasen ved løbende at indsamle kundefeedback, foretage de nødvendige rettelser og udgive nye programrettelser og opdateringer til dit produkt.
Det var det – dit projekt er færdigt, og du kan gå videre til det næste!
Bør du så bruge vandfaldsmetoden?
Hvis du som Agile-orienteret projektleder (i hvert fald går jeg ud fra, at du er det) mener, at denne metode er umoderne, og at du aldrig bør overveje at bruge den, så er jeg (med respekt) uenig med dig og vil argumentere for, at vandfaldsmetoden faktisk er det bedre valg til bestemte typer projekter.
Lad mig gennemgå et par eksempler med dig for at bevise min pointe.
Casestudier: Vandfaldsmetoden i praksis
Som med ethvert komplekst koncept kan nogle konkrete eksempler være nyttige for at forstå, hvordan metoden fungerer i virkeligheden. Så her er nogle få eksempler baseret på virkelige projekter (som jeg måske har arbejdet på, måske ikke) for at hjælpe dig med at danne dig et klart billede af, hvordan vandfaldstilgangen fungerer i praksis.
Eksempel nr. 1: En platform til toldbehandling for Egyptens regering
Forestil dig, at du er en del af en virksomhed, der har vundet kontrakten på at modernisere et relativt stort lands systemer til international handel og toldbehandling, eksempelvis Egyptens.
Det, den egyptiske regering ønsker, er et system til havnemyndigheder, som skal håndtere alle skibes lastlister (et tolddokument, der indeholder oplysninger om al den last og alle de passagerer, der befinder sig om bord på skibet), som ankommer til Egyptens forskellige havne.
Desuden ønsker de, at dette system skal integreres direkte med et andet produkt, som de vil have dig til at bygge, og som skal håndtere alle toldangivelser (også kaldet SADs eller enhedsadministrative dokumenter) i landet. Formularen er ret kompleks for almindelige mennesker at udfylde, så de vil have dig til at automatisere den for dem.
Egypten har et komplekst system for skatter og toldafgifter, hvor satserne ændres afhængigt af typen af varer, du importerer, deres mængde og andre faktorer. Da almindelige borgere ikke har nogen idé om disse satser, ønsker den egyptiske regering, at din app automatisk beregner det hele for borgerne ud fra det, de har angivet, og lader dem betale online med deres kreditkort.
Det lyder som en enorm opgave, ikke? Når implementeringsdetaljerne skal færdiggøres, vil din ledelse (og måske endda den egyptiske regering) komme til dig som projektleder og spørge, hvordan du vil organisere implementeringen af dette projekt.
Hvorfor og hvordan du bør bruge vandfaldsmetoden i dette scenarie:
Alt, hvad du bygger for en national regering, vil højst sandsynligt være baseret på en lov eller en beslutning, som parlamentet har ratificeret. Disse beslutninger vil omfatte alt fra projektets overordnede vilkår (f.eks. dets omkostninger og tidsplan) til de mindste detaljer om, hvordan alting skal fungere.
Det lyder og ser ud som et kravdokument fra vandfaldsmetodens første fase, ikke? Det gør det faktisk, og det betyder også, at du ikke uden videre kan ændre implementeringsdetaljer, design og krav undervejs, sådan som man kan i agil softwareudvikling.
Jeg har tidligere stået i spidsen for et sådant produkt. En dag indså vi, at vi kunne forbedre brugeroplevelsen betydeligt ved at foretage et par mindre justeringer i forretningslogikken. Vi delte straks vores idé med repræsentanten for toldmyndigheden, som arbejdede sammen med os.
Han sagde nej. Man skulle tro, at det var en dårlig idé at afvise et sådant tilbud, men han havde en god grund til, at de ikke kunne gøre det.
Vores små justeringer ville betyde en ændring af den formel, som regeringen brugte til at beregne skatter for et bestemt produkt. Formlen var fastlagt ved lov, så en ændring af den ville betyde, at hele landets parlament skulle samles og stemme om den.
More Articles
Eksempel nr. 2: Flyvestyringssystemet i Ingenuity-helikopteren
Ingenuity er det navn, NASA gav den højteknologiske helikopter, som de byggede og sendte til Mars i 2021. Sådan ser den lille fyr ud.
Forestil dig, at du var den heldige projektleder, der havde ansvaret for at udvikle softwaren til dette utrolige stykke teknologi. Dit team skulle især skrive den kode, der skulle styre helikopterens flyvning.
Det er meget vanskeligt at skabe et flyvestyringssystem til et luftfartøj (især en helikopter). Du bliver nødt til at tage højde for alle de fysiske love, der påvirker dit luftfartøj under flyvningen, og beregne den nødvendige rotationshastighed for rotorbladene, bladenes vinkel og en million andre ting.
Men din opgave er endnu mere kompleks. Din helikopter skal flyve over overfladen på en anden planet med en atmosfære, der er 100 gange mindre tæt end den, vi har på Jorden.
Hvorfor og hvordan du bør bruge vandfaldsmetoden i dette scenarie:
Efter min mening er vandfaldsudvikling din eneste mulighed her. I modsætning til agil projektledelse, hvor du bygger noget lille (dit MVP), implementerer det, bruger det i virkeligheden, indsamler feedback og gradvist forbedrer din løsning på baggrund af denne feedback, er indsatsen alt for stor i et projekt som dette.
Kan man virkelig risikere at lave en fejlbehæftet MVP af Ingenuity og flyve den 140 millioner miles til Mars? Der er simpelthen ingen måde, nogen ville gå med til det på.
Så du bliver nødt til at bygge den endelige version og derefter teste alle dens systemer grundigt, før du har den nødvendige tillid til at placere den i en raket, der flyver til den røde planet.
Vandfaldsmodellen lever i bedste velgående!
Faktisk er den langt mere populær, end du måske havde forventet, idet halvdelen af alle projekter på verdensplan stadig bruger denne udviklingsmetode.
Selvom fremkomsten af agil udvikling har gjort verden til et bedre sted for mange projektledere ved at give dem mulighed for at lancere produkter langt tidligere og bygge videre på brugernes feedback, er vandfaldsmodellen stadig en yderst værdifuld metode, som du kan anvende til projekter med begrænset fleksibilitet og lav tolerance over for fejl.
Jeg håber, du kunne lide vores gennemgang af vandfaldsmetoden. Hvis du også gerne vil læse lidt mere om agil udvikling, er her nogle forslag:
- Vores guide til agil produktledelse.
- Samlingen af bedste praksisser inden for agil porteføljeledelse.
- Vores kuraterede liste over de bedste værktøjer til agil produktledelse.
Dette er blot tre af de mange vejledninger og artikler, vi har om produkt- og projektledelse. Hvis du vil læse mere, kan du tilmelde dig vores nyhedsbrev.
