Vilket är rätt projektledningsmetod

Innan du direkt svarar på frågan i rubriken är det alltid bra att göra det klart vad det slutliga projektmålet du vill uppnå

Hur produkten ska se ut om en månad, ett halvt år och ett år från nu. Men beskriv det nu. Detta kommer att ge dig lite perspektiv och ställa de grundläggande förväntningarna på nivån på din förutsägbarhet, flexibilitet, smidighet, snabbhet till marknaden och kostnadsfixering i tid.

Ja, idag verkar det vara en löjlig idé att sätta upp vattenfallsprojekten. Särskilt om det redan bevisats otaliga gånger att om du snabbt vill reagera på förändringarna på marknaderna har du inget annat alternativ än att gå agilt. Men om ditt mål är att leverera en produkt ett år från och med nu med funktioner som redan är ganska tydliga och begränsade redan från början, och du har team av människor utan tidigare erfarenhet av agil metodik, så förbli konservativ och gå vattenfall.

Alla fall är inte så lätta att sluta. Låt oss ta en titt på hur man bättre kan utvärdera vilken metod som är bättre för ditt projekt.

Hur ser ett vattenfall ut?

Istället för att gå in på några definitioner som alla redan är medvetna om i ett par decennier nu, ser ett praktiskt resultat av ett vattenfallsprojekt vanligtvis ut så här:

  • Planera först vad du vill göra som slutresultat/produkt och hur mycket det ungefär kan kosta.
  • Starta kravinsamlingsprocessen. Du diskuterade noggrant alla detaljer om slutprodukten, protesterade mot, ifrågasatte, kom överens om, diskuterade igen och bekräftade slutligen.
  • Uppskatta det hela och bekräfta budgetförväntningarna.
  • Designa lösningen. Genomför flera möten med intressenter. Skapa olika dokument och låt intressenter granska dem. Bekräfta och godkänn den slutliga funktionella och tekniska designen.
  • Implementera lösningen utifrån designen. Det är här du utvecklar den kompletta slutprodukten.
  • Gå in i testfasen och utför olika typer av tester. Enhetstester, systemtester, funktionstester, integrationstester, prestandatester, regressionstester, användaracceptanstester och potentiellt många fler (beroende på företagets kultur). Dokumentera allt och låt intressenterna granska och godkänna det.
  • Distribuera lösningen till produktionsmiljön. Det är här målanvändarna börjar använda den slutliga och kompletta produkten.
  • Schemalägg en supportfas under vilken utvecklingsteamet korrigerar potentiella buggar i lösningen.
  • Hela denna process kan ta några månader till några år. Som du kan förutsäga kommer användarna att se resultaten först i slutet av den processen. Så efter lång väntan kommer sanningens (eller misslyckandets) ögonblick.

    Om något förändras under den långa tiden och slutprodukten skulle se lite annorlunda ut, är det en situation man kallar en förändringsförfrågan. Designen måste öppnas igen, omarbetas och godkännas på nytt. Det förlänger hela tidsschemat med ytterligare en del. Varje förändring kräver en omstart av hela processen innan.

    Å andra sidan har du en stensäker fasdefinition, en fast budget för varje fas och en fast tid. Även om du måste vänta länge för att få det första resultatet, om chanserna för förändringar på vägen är minimala, kan det fortfarande vara ett att föredra att gå med.

    Hur ser en Agile ut?

    Nu är det så här projektet kan fungera under en Agile-inställning:

  • Definiera affärsvisionen för slutprodukten. Ungefär men med tydliga affärskrav och förväntningar på vad produkten ska uppfylla för användarna.
  • Skapa en lista över funktionella epos och tekniska möjliggörare som täcker visionen.
  • Gör en uppskattning på hög nivå av eposerna och gör det möjligt för dig att upprätta några slanka budgetförväntningar och tidsram för leverans. Definiera vad Minimum Viable Product (MVP) är och vilka är resten av funktionerna som utgör slutprodukten.
  • Skapa ett scrum-team och schemalägg sprintarna inom tidsramsperioden. Bryt ner eposerna i funktioner och berättelser med teamet. Uppskatta berättelserna och planera dem för de kommande spurterna baserat på den prioritet som funktionerna och berättelserna har.
  • Arbeta med berättelserna varje sprint. Inkludera alla aktiviteter i sprintarna, det vill säga design, utveckling, test och implementering. I slutet av varje sprint, presentera det ökade resultatet för användarna och sök feedback.
  • Om något går ur spåret eller har ett önskat resultat, ändra funktionerna eller berättelserna för att anpassa sig till den uppdaterade verkligheten. Reflektera det direkt från nästa spurter.
  • Direkt efter att omfattningen av MVP är klar, släpp den till slutanvändarna för att samla in snabb produktionsfeedback.
  • Fortsätt att utveckla resten av funktionerna genom att återspegla resultatet av användarens feedback från den redan släppta delen av systemet.
  • Detta är bara en snabb sammanfattning, men skillnaden mot vattenfallet är redan tydlig. Snabb feedback, anpassning, reflektion av aktuella behov som förändras i tiden, första värdefulla produkten levererad på kortast möjliga tid. Alla dessa är fastigheter som du inte har någon chans att få i ett vattenfallsprojekt.

    Agile vs. Vattenfall

    Ett projekt kan inte bli framgångsrikt utan en lämplig projektledningsmetod på plats. Detta innebär att definiera processer, mätetal, utvärderingar och allmänna arbetssätt för de team som bildar projektet.

    Teamen behöver veta vilka regler de ska följa, vad som kommer att definiera milstolparna, när de ska nå dem och hur de ska mäta och utvärdera framgången. Samtidigt måste intressenter förstå vad de kan förvänta sig av projektet och när de kommer att kunna se de första resultaten av arbetet.

    Med lite generalisering kan vi säga att projekt som arbetar i molnmiljöer är betydligt mer benägna att benäga sig till agila metoder (eller de borde åtminstone). Projekt som arbetar med lokal infrastruktur föredrar fortfarande mycket ofta vattenfallsprocesser. Detta kommer som en naturlig slutsats.

    Molnmiljön är byggd från marken för att passa den ständigt föränderliga miljön. Den anpassar sig så snabbt som möjligt (med olika ”elastiska” tjänster) till den nya verkligheten. Den lokala miljön är ofta fördefinierad i början. Det är svårt att ändra det över tid, så teamen arbetar med deterministiska variabler under hela projektets varaktighet.

    Sammanfattning av tillvägagångssättet Agile vs. Vattenfall.

    FeatureWaterfall ApproachAgil ApproachHantering av användarkravChange behandlas som en formell process (Change Request). Arbetet kan behöva göras om, vilket påverkar kostnader och tidslinjer. Omfamnar förändringar som en del av standardprocessen, utan någon betydande inverkan på kostnader eller tidslinjer. Projektplanering och omfattningDefinierar omfattningen i början och håller sig till den. Faserna är stela och följer den ursprungliga planen. Har en tydlig vision av slutprodukten men tillåter förändringar. Arbetet är organiserat i sprints med flexibilitet i hur uppgifterna slutförs. Spårning av projektframsteg Spårar framsteg inom varje fas. Förseningar i en fas kan påverka hela projektets tidslinje. Spårar framsteg genom demosessioner i slutet av varje sprint. Fokuserar på den fungerande produkten.Teamsamarbete Olika människor i olika projektfaser, begränsad interaktion.Tvärfunktionellt team med konstant kommunikation mellan teammedlemmar och intressenter.RiskhanteringStatusspårning baserad på fasförlopp. Reagerar på risker i efterhand samtidigt som den följer planen. Fokuserar på att lösa beroenden mellan team och aktiviteter proaktivt. Anpassar planen för att eliminera prognostiserade risker. Implementation FrameworkTraditionell metodik.Kräver transformationsmetoder för att anpassa sig till det agila tillvägagångssättet. Innebär att ändra vanor och tankesätt.

    Detta val kommer dock att definiera flera aspekter av projektutförandeegenskaperna.

    #1. Projektkrav och förändringsledning

    En av de viktigaste aspekterna som definierar valet är hur användarens krav kommer att hanteras. Och även, hur är processen om en förändring av de redan överenskomna kraven behövs senare?

    Med ett vattenfallsprojekt är alla krav definierade och undertecknade av intressenter i början; om någon ändring av det tillståndet uppstår, behandlar projektet det som en ändringsbegäran. Det måste återigen valideras, godkännas och bekräftas.

    Allt arbete som redan gjorts fram till det ögonblicket måste ses över och börja om igen. Kostnaderna måste justeras på nytt (eftersom det är tilläggsarbete som inte täcks av det ursprungliga kontraktet). I värsta fall måste till och med hela projektets tidslinje förlängas.

    Med en smidig installation är ändringarna välkomna. Du behandlar förändringarna som en vanlig daglig verksamhet. Du håller med intressenter (troligen som ett resultat av den senaste sprintdemon) att förändringar är avgörande för att upprätthålla visionen för projektet. Sedan schemalägger du dessa förändringar omedelbart för nästa sprint.

    Det tidigare innehållet kommer att förändras med det, och teamen fortsätter att arbeta med nya krav från den dagen. Det finns ingen förlust i tid eller kostnader. Du anpassar dig helt enkelt till den nya verkligheten omedelbart och ersätter den ursprungliga planen med den nya. Det finns inget behov av särskild hantering av ändringsförfrågningar alls. Allt är en del av sprintplaneringsinitiativ.

    #2. Projektering och omfattning

    Som du kanske förväntar dig, sätter och fixar vattenfallsprojektet hela omfattningen i början. Du skapar projektplanen kring detta omfång. Sedan delar du in projektets varaktighet i specifika faser (vanligtvis analys, design, utveckling, test, driftsättning, support och underhåll) och fixar teamen och resurserna runt dessa faser. För större delen av projektets tidslinje är ditt huvudmål att hålla fast vid denna ursprungliga plan när det gäller kostnader och timing så mycket som möjligt.

    Ett agilt projekt har en vision om slutprodukten istället för en hård plan. Sluttillståndet är tydligt, men vägen att nå det tillståndet är fri att förändras. Projektets tidslinje är fortfarande definierad och överenskommen baserat på en preliminär uppskattning av efterfrågan och kapacitetsbelastningsupplevelsen för teamen som arbetar med projektet. Planen har inga separata faser. Istället är varje sprint en liten fas i sig som innehåller alla aktiviteter som laget behöver för att framgångsrikt släppa inkrementprodukten.

    Sammanfattningsvis behandlar vattenfallsprojektet förändringarna som en komplikation att lösa (och en möjlighet för leverantörerna att skaffa ytterligare pengar). Däremot behandlar det agila projektet förändringen som en business as usual utan några ytterligare konsekvenser (förutom en bättre lämplig slutprodukt).

    #3. Spårning av projektförlopp

    Vattenfallsprojektet spårar 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 några av faserna blir försenade kommer det att påverka framstegen i de återstående faserna av projektet. Det är därför det är viktigt att kontrollera aktiviteterna i varje fas och se till att de framskrider linjärt under tiden. Annars ökar du risken att försena just den fasen och följaktligen hela projektet.

    Det agila projektet spårar framstegen, främst med demosessioner som sker i slutet av varje sprint. Den fungerande produkten är det primära måttet på framsteg. Naturligtvis vill du säkerställa att varje sprint avslutas med komplett sprintinnehåll. Inga eller endast minimiberättelser förs över till nästa spurter.

    I slutändan är det mycket lättare att se projektets övergripande framsteg om du direkt kan prova det aktuella produkttillskottet och komma tillbaka till teamet med mycket konkret feedback direkt.

    #4. Team Samarbete

    Det här handlar om strikt separata aktiviteter av vattenfall kontra kontinuerligt samarbete med alla parter i ett agilt team.

    Ett vattenfallsprojekt har vanligtvis olika personer som arbetar i olika faser av projektet. De kanske svämmar över varandra i viss utsträckning, men de är fortfarande olika grupper av människor. Nästan silorna kan man säga.

    Den agila teamdefinitionen ligger i kommunikation och värde. Det ska också vara ett tvärfunktionellt team som kan utföra alla produktlivscykelaktiviteter. Silos av lagen är något man inte vill ska finnas. Konstant fram och tillbaka kommunikation mellan teamet och externa intressenter är en grundläggande definition av ett framgångsrikt agilt projekt.

    #5. Riskhantering

    Självklart vill du ha en process för att spåra eventuella risker, problem eller någon form av hinder som projektet kan medföra under sin tidslinje.

    I fallet med ett vattenfallsprojekt översätts detta till statusspårning av den aktuella fasen av projektet. Den vanliga semaforliknande statusrapporteringen kommer att visa grönt (allt är OK och i linje med planen), gult (några viktiga problem är på plats, men det finns fortfarande en tydlig förståelse för hur man löser dem) eller röd (vilket betyder projektet har allvarliga problem som kan påverka de ursprungliga tidslinjerna eller budgeten).

    Det agila projektet är också annorlunda här. Du spårar inte riktigt framstegen mot målet. Snarare löser du beroenden mellan olika team och typer av aktiviteter. Målet är att säkerställa att inget team väntar på ett annat lag med framstegsaktiviteterna.

    Naturligtvis kan risker dyka upp, men då måste lösningen ändra planen framöver så att risken försvinner snarare än att räkna ut lösningen på risken samtidigt som den ursprungliga planen bevaras.

    Med andra ord, en smidig uppsättning av projektet använder alla möjliga sätt att ändra planen så att den inte möter de förväntade riskerna, vilket innebär att riskhanteringen är proaktiv. När det gäller ett vattenfallsprojekt reagerar man på riskerna i efterhand och försöker lösa dem på kortast möjliga tid samtidigt som man håller sig till den ursprungliga planen.

    #6. Implementeringsram

    Implementeringstaktik för vattenfallsprojekt är uppenbarligen mindre problematisk än för agila projekt. Vanligtvis är vattenfallsmetoden det status quo som människor redan har praktiserat i många år.

    Å andra sidan kräver projekt agila transformationsmetoder för att ändra sina vanor, tänkesätt och arbetssätt. Det är en svår och ofta också ganska långvarig process. Företag investerar betydande mängder tid och resurser för att lära människor att anpassa sig till agila processer.

    Fördelarna i form av snabb anpassning till kundens förändrade behov är betydande, men att förändra människors tankesätt och övergripande arbetsmiljö är det svåraste.

    För det mesta är det också det enda sättet att förbli kompetent på marknaden, så avvägningarna belönas med stor framgång för de som lyckas.

    Slutord

    Låt oss säga det tydligt. Om du inte har en mycket konservativ kund utan någon större motivation att leverera resultat till produktionen snabbt (av vilka anledningar de än kan ha för det), är din bästa insats att börja modellera de agila teamen redan från början. Detta är bokstavligen en no-brainer i dagens värld. Detta gäller även i fallet med traditionella systeminstallationer på plats. Särskilt om teamet är nytt eller börjar från början med originalpersoner, är det fortfarande vettigt att omvandla processerna för att anpassa sig till agila metoder.

    Med det sagt ser jag fortfarande projekt där människor bara vägrar att följa den här typen av agila processer eller någon annan uppställning men strikt fasspecifik organisation av arbetet. 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 kommer att följa denna uppställning utan avvikelser från planen och pengar (med olika resultat, vanligtvis inte bra).

    Detta är ett beslut de har rätt att fatta, men i slutändan, med ett sådant beslut, bestämmer de sig också för att stanna i det förflutna. Det kan fungera för dem ett tag framöver, men det är bara en tidsfråga tills det inte fungerar längre.

    Kolla sedan in den detaljerade artikeln om livscykeln för agila tester.