Innan man ger ett direkt svar på frågan i rubriken är det alltid klokt att klargöra det slutliga målet med projektet.
Tänk på hur produkten ska se ut om en månad, ett halvår och ett år. Visualisera det här och nu. Det kommer att ge perspektiv och definiera grundläggande förväntningar på förutsägbarhet, flexibilitet, smidighet, snabbhet till marknaden och kostnadskontroll.
Idag kan det verka bakåtsträvande att föreslå vattenfallsprojekt. Särskilt som det upprepade gånger bevisats att agila metoder är det enda valet om man vill reagera snabbt på marknadsförändringar. Men, om målet är att leverera en produkt om ett år med redan tydliga och begränsade funktioner, och teamet saknar erfarenhet av agila metoder, kan det vara bäst att vara konservativ och välja vattenfallsmetoden.
Alla situationer är inte lika enkla. Låt oss undersöka hur man bättre kan avgöra vilken metod som lämpar sig bäst för ett specifikt projekt.
Hur fungerar vattenfallsmetoden?
Istället för att gå in på detaljerade definitioner som är välkända sedan flera decennier, ser ett praktiskt vattenfallsprojekt ut ungefär så här:
- Börja med att planera produktens slutresultat och en uppskattning av kostnaden.
- Inled kravinsamlingsprocessen. Gå igenom alla detaljer för slutprodukten, diskutera, ifrågasätt, kom överens, diskutera igen och slutligen bekräfta alla aspekter.
- Gör en totaluppskattning och bekräfta budgetförväntningarna.
- Designa lösningen. Ha flera möten med intressenter. Skapa dokumentation som granskas av intressenterna. Bekräfta och godkänn den slutliga funktions- och tekniska designen.
- Implementera lösningen enligt designen. Här sker utvecklingen av den färdiga produkten.
- Gå vidare till testfasen med olika typer av tester. Enhetstester, systemtester, funktionstester, integrationstester, prestandatester, regressionstester, användaracceptanstester och potentiellt fler (beroende på företagets kultur). Dokumentera allt och låt intressenterna granska och godkänna det.
- Distribuera lösningen till produktionsmiljön. Nu börjar slutanvändarna använda den färdiga produkten.
- Planera för en supportfas under vilken utvecklingsteamet åtgärdar eventuella buggar.
Hela processen kan pågå i månader eller till och med år. Som man kan förutse får användarna se resultaten först i slutet av denna process. Efter en lång väntan kommer sanningens ögonblick.
Om något förändras under den långa tidsperioden och slutprodukten behöver ändras, uppstår en så kallad ändringsförfrågan. Designen måste öppnas igen, bearbetas om och godkännas på nytt. Detta förlänger tidsplanen ytterligare. Varje ändring kräver en omstart av processen.
Å andra sidan har man en tydlig fasdefinition, en fast budget för varje fas och en fast tidsplan. Även om det tar lång tid att se de första resultaten, kan det fortfarande vara ett lämpligt val om risken för förändringar är minimal.
Hur fungerar den agila metoden?
Så här kan ett projekt fungera med en agil inställning:
- Definiera den övergripande affärsvisionen för slutprodukten. Ungefär, men med tydliga affärskrav och förväntningar på hur produkten ska gynna användarna.
- Skapa en lista över funktionella ”epics” och tekniska möjliggörare som stöder visionen.
- Gör en grov uppskattning av ”epics” för att kunna sätta budgetförväntningar och tidsramar. Definiera vad en Minimum Viable Product (MVP) är och vilka funktioner som utgör slutprodukten.
- Sätt ihop ett scrum-team och planera sprintar inom den definierade tidsramen. Bryt ner ”epics” i funktioner och berättelser med teamet. Uppskatta berättelserna och planera dem för de kommande sprintarna baserat på prioriteringarna.
- Arbeta med berättelserna i varje sprint. Inkludera alla aktiviteter i sprintarna, såsom design, utveckling, test och implementering. I slutet av varje sprint, presentera resultatet för användarna och samla in feedback.
- Om något inte går som planerat eller ger ett oväntat resultat, ändra funktioner eller berättelser för att anpassa sig till verkligheten. Återspegla detta direkt i kommande sprintar.
- När MVP är klar, släpp den till slutanvändarna för att snabbt samla in feedback.
- Fortsätt utveckla återstående funktioner genom att använda feedback från den redan släppta delen av systemet.
Detta är bara en sammanfattning, men skillnaden mot vattenfallsmetoden är tydlig. Snabb feedback, anpassning, reflektion av aktuella behov, och en första version av produkten levereras så snabbt som möjligt. Det är fördelar som man inte kan få med ett vattenfallsprojekt.
Agilt kontra Vattenfall
Ett framgångsrikt projekt kräver en lämplig projektledningsmetod med definierade processer, mätetal, utvärderingar och arbetsmetoder för teamet.
Teamet måste veta vilka regler som gäller, vad som definierar milstolparna, när de ska nås och hur framgång ska mätas. Intressenter behöver veta vad de kan förvänta sig av projektet och när de kan se de första resultaten.
Generellt sett tenderar projekt i molnmiljöer att föredra agila metoder (eller borde göra det). Projekt med lokal infrastruktur använder fortfarande ofta vattenfallsprocesser. Detta är en logisk slutsats.
Molnmiljön är uppbyggd för att hantera förändring. Den anpassar sig snabbt till ny verklighet med flexibla tjänster. Den lokala miljön är ofta fördefinierad i början. Det är svårt att ändra den över tid, så teamet arbetar med fasta variabler under hela projektet.
Sammanfattning av agil och vattenfallsmetod:
Funktion | Vattenfallsmetod | Agil metod |
Hantering av användarkrav | Ändringar behandlas som en formell process (ändringsförfrågan). Omgörningar kan påverka kostnader och tidslinjer. | Omfamnar ändringar som en del av standardprocessen, utan stor påverkan på kostnader eller tidslinjer. |
Projektplanering och omfattning | Omfattningen definieras i början och hålls fast vid. Faserna är strikta och följer den ursprungliga planen. | Har en tydlig vision men tillåter förändringar. Arbetet är organiserat i sprintar med flexibilitet i hur uppgifter slutförs. |
Spårning av projektframsteg | Spårar framsteg inom varje fas. Förseningar i en fas kan påverka hela tidslinjen. | Spårar framsteg genom demosessioner i slutet av varje sprint. Fokuserar på den fungerande produkten. |
Teamsamarbete | Olika personer i olika faser, begränsad interaktion. | Tvärfunktionellt team med kontinuerlig kommunikation mellan teammedlemmar och intressenter. |
Riskhantering | Statusspårning baserad på fasförlopp. Reagerar på risker i efterhand men följer planen. | Fokuserar på att lösa beroenden proaktivt. Anpassar planen för att eliminera förväntade risker. |
Implementeringsram | Traditionell metodik. | Kräver förändringar i metoder för att anpassa sig till det agila arbetssättet. |
Detta val påverkar flera aspekter av hur ett projekt genomförs.
#1. Projektkrav och förändringshantering
En viktig aspekt som avgör valet är hur användarkrav hanteras. Och hur hanteras det om kraven behöver ändras i efterhand?
I ett vattenfallsprojekt definieras och godkänns alla krav av intressenterna i början. Om en ändring sker behandlas det som en ändringsförfrågan. Den måste valideras, godkännas och bekräftas på nytt.
Allt arbete som gjorts hittills måste granskas och göras om. Kostnaderna måste justeras (eftersom det är extraarbete som inte täcks av det ursprungliga avtalet). I värsta fall kan hela projektets tidslinje behöva förlängas.
Med en agil metod välkomnas ändringar. De ses som en del av det dagliga arbetet. Man är överens med intressenterna (ofta efter en sprintdemo) om att förändringar är viktiga för att nå visionen för projektet. Dessa förändringar planeras direkt in i nästa sprint.
Det tidigare arbetet ändras med det, och teamet fortsätter arbeta med de nya kraven. Det finns ingen förlust av tid eller kostnader. Man anpassar sig helt enkelt till den nya verkligheten och ersätter den ursprungliga planen med den nya. Det behövs ingen särskild hantering av ändringsförfrågningar. Allt ingår i sprintplaneringen.
#2. Projektplanering och omfattning
Som man kan förvänta sig fastställs projektets fulla omfattning i början i ett vattenfallsprojekt. Projektplanen skapas runt denna omfattning. Projektets varaktighet delas in i faser (vanligtvis analys, design, utveckling, test, driftsättning, support och underhåll) och teamet och resurserna anpassas efter dessa faser. Huvudmålet är att följa den ursprungliga planen för kostnader och tidsplanering så långt det är möjligt.
Ett agilt projekt har en vision om slutprodukten istället för en strikt plan. Slutmålet är tydligt, men vägen dit kan förändras. Projektets tidslinje definieras och överenskommes baserat på en preliminär uppskattning av efterfrågan och teamets kapacitet. Planen har inte separata faser. Varje sprint är istället en liten fas som innehåller alla aktiviteter som teamet behöver för att leverera produkten.
Sammanfattningsvis ser vattenfallsprojekt förändringar som ett problem (och en möjlighet för leverantörer att få mer pengar). Ett agilt projekt ser förändringar som en del av det vanliga arbetet utan ytterligare konsekvenser (förutom en bättre slutprodukt).
#3. Spårning av projektförlopp
Vattenfallsprojektet följer planens framsteg inom projektets faser. Designfasen kan inte starta innan analysfasen är klar, testning kan inte starta innan hela bygget är klart och så vidare.
Om en fas försenas kommer det att påverka de återstående faserna. Därför är det viktigt att kontrollera aktiviteterna i varje fas och se till att de fortgår linjärt. Annars ökar risken för att försena just den fasen och därmed hela projektet.
Det agila projektet följer framstegen främst genom demosessioner i slutet av varje sprint. Den fungerande produkten är det viktigaste måttet på framsteg. Varje sprint bör avslutas med ett komplett sprintinnehåll. Inga eller endast ett fåtal berättelser ska föras över till nästa sprint.
Det är lättare att se projektets övergripande framsteg om man direkt kan prova den aktuella produktversionen och ge feedback direkt till teamet.
#4. Teamsamarbete
Här handlar det om tydliga avgränsningar i vattenfallsmetoden jämfört med kontinuerligt samarbete i ett agilt team.
I ett vattenfallsprojekt arbetar olika personer i olika faser. De kan överlappa varandra i viss utsträckning, men det är fortfarande olika grupper av människor, nästan som stuprör.
Det agila teamet definieras av kommunikation och värde. Det ska vara ett tvärfunktionellt team som kan hantera alla produktens livscykelaktiviteter. Stuprör i teamet bör undvikas. Kontinuerlig kommunikation mellan teamet och externa intressenter är avgörande för ett framgångsrikt agilt projekt.
#5. Riskhantering
Det är viktigt att ha en process för att spåra risker, problem eller hinder som kan uppstå under projektets gång.
I ett vattenfallsprojekt hanteras detta med hjälp av statusspårning av den aktuella fasen. En trafikljusliknande statusrapportering visar grönt (allt är ok), gult (vissa problem finns, men det finns en plan för lösning) eller rött (projektet har allvarliga problem som kan påverka tidsplanen eller budgeten).
Det agila projektet hanterar detta annorlunda. Istället för att spåra framsteg mot målet, löser man beroenden mellan olika team och aktiviteter. Målet är att se till att inget team behöver vänta på ett annat.
Risker kan uppstå, men då måste planen ändras så att risken försvinner istället för att man försöker lösa problemet och samtidigt behålla den ursprungliga planen.
Med andra ord, en agil metod använder alla möjliga sätt att ändra planen för att undvika risker, vilket gör riskhanteringen proaktiv. I ett vattenfallsprojekt reagerar man på riskerna i efterhand och försöker lösa dem snabbt samtidigt som man håller sig till den ursprungliga planen.
#6. Implementeringsram
Implementeringen av vattenfallsprojekt är ofta enklare än agila projekt. Vattenfallsmetoden är ofta det som folk har gjort i många år.
Å andra sidan kräver agila projekt förändringar i sättet man tänker och arbetar. Det är en svår och ofta lång process. Företag investerar mycket tid och resurser för att lära folk att anpassa sig till agila processer.
Fördelarna i form av snabb anpassning till kundens behov är betydande, men att ändra människors tankesätt och arbetsmiljö är det svåraste.
Det är också det bästa sättet att förbli konkurrenskraftig, och belöningen är stor för de som lyckas.
Slutord
Om man inte har en väldigt konservativ kund som inte har bråttom att lansera produkten snabbt, är det bäst att starta med agila team direkt. Det är ett enkelt val i dagens värld. Det gäller även traditionella installationer. Särskilt om teamet är nytt eller börjar från grunden, är det fortfarande klokt att anpassa processerna till agila metoder.
Ändå ser man projekt där folk vägrar att använda agila metoder och istället håller sig till strikt fasspecifik organisation. De följer den vanliga vägen att kontraktera arbetet för en specifik tid och budget. Sedan förväntar de sig att projektet ska följa den planen utan avvikelser (oftast med dåliga resultat).
Det är ett beslut de har rätt att ta, men samtidigt bestämmer de sig för att stanna kvar i det förflutna. Det kan fungera ett tag, men det är bara en tidsfråga innan det inte fungerar längre.
Läs sedan den detaljerade artikeln om livscykeln för agila tester.