Vi lever i en värld där agil metodik är allestädes närvarande. Från berömda teknikjättar till små nystartade företag använder alla den för att bygga sina produkter. När du lär dig om agilt arbetssätt kan du ha stött på begreppet ”vattenfallsmetodik”.
De flesta projektledare som använder agilt arbetssätt betraktar vattenfallsmetodik som en föråldrad metodik som inte längre fyller någon funktion år 2023. Men stämmer det verkligen?
Som senior produktchef har jag stor erfarenhet av både agilt arbetssätt och vattenfallsmetodik. Till vattenfallsmetodikens försvar ska vi gå på djupet med vad den är, hur den fungerar och när det är lämpligt att använda den.
Vad handlar vattenfallsmetodiken för projektledning om?
Vattenfallsmetodik innebär att utvecklingsprojekt hanteras genom att de delas upp i tydliga faser som genomförs sekventiellt.
Även om det har varit ett koncept som människor har använt sedan tidernas begynnelse att dela upp stora arbetsmängder i mindre delar, ägde vattenfallsmetodikens formella ”födelse” rum långt senare – år 1970, när dr Winston W. Royce, en framstående datavetare på den tiden, beskrev den i sin bok ”Managing the Development of Large Software Systems”.
Sedan dess har det varit det huvudsakliga sättet för programvaruföretag att hantera sina projekt, fram tills världen började luta åt agilt arbetssätt i början av 2000-talet.
Så här ser livscykeln för programvaruutveckling (SDLC) ut med vattenfallsmetoden
Till skillnad från agil metodiks iterativa och inkrementella struktur har SDLC för vattenfallsmetoden både en tydlig början och ett tydligt slut. Den delar upp hela processen för att skapa programvara i fem olika faser eller milstolpar, och arbetet med en fas påbörjas inte förrän den föregående fasen är klar. Visuellt ser det ut så här:
Arbetet flödar från en fas till nästa, tills det når botten och projektet betraktas som ”slutfört” – vilket visuellt liknar ett vattenfall (därav begreppet).
Nu ska vi titta på varje fas i detta linjära arbetssätt och förstå vad de handlar om.
Fas 1: Kravinsamling
Allt börjar med att samla in projektets krav från alla intressenter. Under kravfasen skapar projektledarna ett omfattande och mycket detaljerat dokument som täcker alla aspekter av projektet, från funktionella krav till budget och riskplan.
Have an account? Log In
Fas 2: Lösningsdesign
Utifrån kraven som samlades in under den föregående fasen börjar projektgruppen utforma lösningen och designa den. Begreppet ”design” syftar här på produktens tekniska struktur (systemdesign), produktens visuella utformning och interaktionsdesign (UI/UX-design) samt den fysiska utformningen (om det är en fysisk produkt).
Fas 3: Implementering
Det är nu den faktiska kodningen sker. Medlemmarna i ditt utvecklingsteam börjar bygga produkten utifrån de leverabler som du skapade under designfasen.
Till skillnad från agilt arbetssätt, där du fritt kan ändra projektets omfattning och design kontinuerligt, utgår vattenfallsmetodiken från att du följer designdokumentet och inte ”utvecklar” produkten under implementeringsfasen.
Fas 4: Testning
Så snart programvaruteknikteamet har byggt klart produkten kan vi gå vidare till nästa fas i vår projektplan – testning. Ditt team börjar kontrollera produkten för eventuella buggar, säkerhetsbrister eller problem med användarupplevelsen.
Under testfasen kontrollerar du också om den slutliga produktens funktionalitet och design överensstämmer med projektdokumenten med krav som du skapade under de två första faserna.
Fas 5: Driftsättning och support efter lansering
Förutsatt att ditt team har hittat och åtgärdat alla betydande problem i produkten är det dags att lansera den och överlämna lösningen till dina kunder och slutanvändare.
Dina programmerare går nu vidare till underhållsfasen genom att kontinuerligt samla in kundfeedback, göra nödvändiga korrigeringar samt släppa nya korrigeringar och uppdateringar av produkten.
Det var allt – projektet är slutfört och du kan gå vidare till nästa!
Så, bör du använda vattenfallsmetoden?
Om du, den agilt sinnade projektledaren (åtminstone antar jag att du är det), tycker att denna metodik är omodern och att du aldrig bör överväga att använda den, så håller jag (respektfullt) inte med dig och hävdar att vattenfallsmetoden faktiskt är det bättre valet för vissa typer av projekt.
Låt mig gå igenom ett par exempel med dig för att bevisa min poäng.
Fallstudier: Vattenfallsmetoden i praktiken
Som med alla komplexa koncept kan några konkreta exempel vara till hjälp för att förstå hur metoden fungerar i verkligheten. Här är därför några exempel baserade på verkliga projekt (som jag kanske har arbetat med själv eller kanske inte) för att hjälpa dig att verkligen förstå hur vattenfallsmetoden fungerar i praktiken.
Fall 1: En plattform för tullklarering åt Egyptens regering
Föreställ dig att du är en del av ett företag som har vunnit avtalet om att modernisera systemen för internationell handel och tullklarering i ett relativt stort land, exempelvis Egypten.
Det den egyptiska regeringen vill ha är ett hamnmyndighetssystem som ska hantera alla fartygs manifest (ett tulldokument som innehåller information om all last och alla passagerare ombord på fartyget) som anlöper Egyptens olika hamnar.
Dessutom vill de att detta system ska integreras direkt med en annan produkt som de vill att ni bygger och som ska hantera alla tulldeklarationer (även kallade SAD eller single administrative documents) i landet. Formuläret är ganska komplicerat för vanliga människor att fylla i, så de vill att ni automatiserar det åt dem.
Egypten har ett komplext system för beskattning och tullavgifter där satserna ändras beroende på vilken typ av varor du importerar, deras kvantitet och andra faktorer. Eftersom vanliga medborgare inte har någon aning om dessa satser vill den egyptiska regeringen att er app automatiskt ska beräkna allt åt medborgarna utifrån det de har deklarerat och låta dem betala online med sina kreditkort.
Det här låter som ett enormt åtagande, eller hur? När implementeringsdetaljerna ska slutföras kommer din ledning (och kanske till och med den egyptiska regeringen) att vända sig till dig, projektledaren, och fråga hur du vill organisera genomförandet av projektet.
Varför och hur du bör använda vattenfallsmetoden i det här scenariot:
Vad du än bygger åt en nationell regering kommer sannolikt att baseras på en lag eller ett beslut som parlamentet har ratificerat. Dessa beslut kommer att omfatta allt från projektets allmänna villkor (t.ex. kostnad och tidsplan) till de minsta detaljerna kring hur allt ska fungera.
Det låter och ser ut som ett kravdokument från vattenfallsmodellens första fas, eller hur? Det gör det faktiskt, och det innebär också att du inte riktigt kan ändra implementeringsdetaljer, design och krav under arbetets gång på samma sätt som i agil mjukvaruutveckling.
Jag ledde en sådan produkt tidigare. En dag insåg vi att vi kunde förbättra användarupplevelsen avsevärt genom att göra ett par mindre justeringar i affärslogiken. Vi delade omedelbart vår idé med representanten för tullmyndigheten som arbetade med oss.
Han sade nej. Man skulle kunna tro att det var en dålig idé att avvisa ett sådant erbjudande, men han hade ett gott skäl till att de inte kunde göra det.
Våra små justeringar skulle innebära en förändring av den formel som regeringen använde för att beräkna skatter för en viss produkt. Formeln var fastställd i lag, så att ändra den skulle innebära att samla hela parlamentet och rösta om saken.
More Articles
Fall 2: Flygstyrsystemet i helikoptern Ingenuity
Ingenuity är namnet som NASA gav den högteknologiska helikopter som de byggde och skickade till Mars 2021. Så här ser den lilla krabaten ut.
Föreställ dig att du var en av de lyckligt lottade projektledare som ansvarade för att utveckla programvaran till denna otroliga tekniska apparat. Ditt team behövde särskilt skriva koden som skulle styra helikopterns flygning.
Att skapa ett flygstyrsystem för ett luftfartyg (särskilt en helikopter) är mycket svårt. Du måste ta hänsyn till alla fysikens lagar som påverkar luftfartyget under flygningen och beräkna den nödvändiga rotationshastigheten för rotorbladen, rotorbladens vinkel och en miljon andra saker.
Men din uppgift är ännu mer komplex. Din helikopter måste flyga ovanför ytan på en annan planet med en atmosfär som är 100 gånger mindre tät än den vi har på jorden.
Varför och hur du bör använda vattenfallsmetoden i det här scenariot:
Enligt min mening är vattenfallsutveckling ditt enda alternativ här. Till skillnad från agil projektledning, där du bygger något litet (din MVP), driftsätter det, använder det i verkligheten, samlar in feedback och gradvis förbättrar lösningen utifrån denna feedback, är insatserna alldeles för höga i ett sådant här projekt.
Kan man verkligen riskera att skapa en buggig MVP av Ingenuity och flyga den 140 miljoner miles till Mars? Det finns helt enkelt inte en chans att någon skulle gå med på det.
Så du måste bygga den slutgiltiga versionen och sedan testa alla dess system rigoröst innan du har det nödvändiga förtroendet för att placera den i en raket som flyger till den röda planeten.
Vattenfallsmodellen lever och mår bra!
Faktum är att den är mycket mer populär än du kanske hade förväntat dig, eftersom hälften av alla projekt världen över fortfarande använder denna utvecklingsmetodik.
Även om agil metodik har gjort världen till en bättre plats för många projektledare genom att låta dem lansera produkter mycket tidigare och bygga vidare på feedback från sina användare, är vattenfallsmodellen fortfarande en mycket värdefull metodik som du kan använda för projekt med begränsad flexibilitet och låg tolerans för buggar.
Jag hoppas att du uppskattade vår genomgång av vattenfallsmetodiken. Om du också vill läsa lite mer om agil metodik kan jag rekommendera följande:
- Vår guide om agil produktledning.
- Sammanställningen av bästa praxis för agil portföljhantering.
- Vår utvalda lista över de bästa verktygen för agil produktledning.
Detta är bara tre av de många guider och artiklar om produkt- och projektledning som vi har. För mer information kan du prenumerera på vårt nyhetsbrev.
