Waterfall Project Management - Idag tittar de flesta IT-team på att använda Agile Project Management-system. Men vad de slutar göra är att anta Agile Project Management- system till sina projekt. Detta innebär en kombination av traditionella projektledningssystem (kallad Waterfall Project Management Systems) i kombination med principerna för Agile Management, som beskrivs i det ursprungliga Agile Manifesto.
Eftersom fler projekt över hela världen har agile-projekthanteringspraxis, betyder det slutet på projektledningen av vattenfall? Kommer alla IT-projekt att bli Agile Project Management?
För att förstå de olika modellerna, inklusive Agile, och att använda den som bäst passar din situation är det viktigt att först förstå vad det traditionella projektledningssystemet, som kallas Waterfall Project Management Model, handlar om.
Waterfall-projektledningsmodellen, så kallad på grund av arbetsflödesprocessen, kännetecknas av följande:
- Slutprodukten visualiseras först i detalj.
- Därefter implementeras steg i arbetsflödet i följd:
- Krav och analys
- Design
- Genomförande
- Testning
- Installation
- Underhåll
- Projektplanen bör vara idiotsäker eftersom en gång ett steg i sekvensen är klar kan utvecklarna inte gå igenom detsamma utan att planera om igen.
- Det finns lite utrymme för förändringar eller fel och projektplanen måste följas noggrant.
Ursprunget till Waterfall Project Management-modell:
I de tidiga stadierna av IT-branschen fanns det ingen specifik modell för mjukvaruutveckling.
Så industrin antog den sekventiella arbetsflödesmodellen som används i tillverknings- och byggsektorn. Dessa branscher hade väldefinierade arbetssteg och de hade utvecklat en modell som tillgodoser deras behov av stram kostnadskontroll. Så hårdvaruindustrimodellen tillämpades på mjukvaruindustrin.
Winston W Royce presenterade först denna modell 1970 men han använde inte termen "Waterfall Project Management". Han presenterade faktiskt modellen som en felaktig modell. Bildbilden av modellen såg ut som ett kaskadvattenfall. Thomas E. Bell och TA Thayer använde senare termen ”vattenfall” i sitt papper från 1976, ”Programkrav: Är de verkligen ett problem?” Och termen kom att stanna.
Det finns ett antal varianter av denna modell. De vanligtvis använda sex distinkta faserna i projektledningsmodellen för vattenfall förklaras nedan. Beroende på projekt kan dock två steg kombineras tillsammans.
Låt oss betrakta exemplet med att bygga en skola som ett exempel för att bättre förstå projektet för förvaltningen av vattenfallet.
-
Krav och analysfas:
Först måste vi veta exakt vad vi utformar. För detta kanske vi vill:
- Föra detaljerade diskussioner med kunden
- Försök att tydligt visualisera produkten med de minsta detaljerna
- Analysera vilka hårdvaru- och programvarukomponenter som krävs
- Lista upp detaljerna som inkluderar: problemet som produkten ska lösa, kundens begränsningar, prestandanivån och kompatibiliteten med redan befintliga system.
- Gör fallstudier av en liknande produkt.
- Tänk på kraven från varje intressent
- Lista upp specifikationerna i produktkravdokumentet, som utgör ingången för nästa steg.
I vårt exempel på att bygga en skola listar vi i detta steg antalet klassrum, materialet som ska användas för att bygga, personer som krävs, den redan befintliga infrastrukturen. Vi noterar också vad skolans ledning kräver (kontorsrum, personalrum) och vad eleverna behöver (bättre toaletter, lekplatser)
-
Design:
I designstadiet görs allt som har visualiserats i det första steget till en plan.
I IT-projekt består detta av att definiera:
- Maskinvaran som kommer att användas
- Programvaruplattformen som ska användas, inklusive lokal eller molninstallation
- Programvaruarkitekturen, inklusive de olika komponenter och moduler som ska skapas
- Ingångar som krävs för att projektet ska fungera framgångsrikt
- Utgångar som kan förväntas (helst synkroniseras detta med kraven som beskrivs i det tidigare skedet)
Det finns två typer av design som kommer in i ett programvaruprojekt:
- Logisk design
- Fysisk design
Logisk design:
Detta inkluderar basdata och processer som kommer att ingå i projektet. Den beskriver utformningen av formulär och rapporter, utformningen av gränssnittet och databasdesignen. Till exempel för en tågbiljetteringswebbplats kommer denna design att avgöra hur hela processen kommer att fungera: skärmen som resenären matar in sina detaljer och hur dessa data kommer att flyta in i databasen, och även vilken typ av databas som lagrar dessa detaljer.
Fysisk design:
Detta handlar om utformningen av den fysiska databasen, programmen och processerna och de distribuerade systemen. Detta görs efter den logiska designen och kommer att inkludera ”hur” projektet kommer att göras: hårdvaran, plattformen på vilken det kommer att utvecklas, olika databaser, skärmar och formulär som kommer att användas, etc.
-
Genomförande:
- Det är här den faktiska utvecklingen av programvaran / systemet sker.
- Ingången för detta steg är konstruktionsspecifikationerna från föregående steg.
- Utgången är en eller flera av produktkomponenterna byggda efter specifikationer, felsöks, testas och integreras för att tillfredsställa systemarkitekturen.
- Det här steget tas vanligtvis hand om av utvecklingsgruppen som består av programmerare, gränssnittsdesigners och andra specialister och verktygen som används är kompilatorer, debuggers, tolkar och medieredigerare.
- Detta steg tar vanligtvis maximal tid och det är viktigt att noggrant hålla reda på processerna och designen. Förändringar av designen i detta skede är svåra i Waterfall Project Management.
- För ett stort projekt som involverar flera team rekommenderas versionskontroll för att spåra ändringar i kodträdet och återgå till tidigare ögonblicksbilder för felhantering.
- I vårt exempel: Byggnadens faktiska konstruktion med arbete och material görs i detta skede.
-
Testning:
Testning kan göras för produkten som helhet eller för enskilda komponenter. "Testfall" kan verifieras för att se om produkten kan leverera som utlovat. Det kan vara test av moduler, systemtestning av den integrerade produkten och godkännande testning. Acceptantestning innebär att testa produkten för kryphål av slutanvändaren eller kunden. Defekter noteras för att implementeringsteamet ska korrigera. När korrigeringarna har gjorts bereds en formell produktdokumentation.
I exemplet testas skolans infrastruktur, sannolikt av en granskningsteam. I vissa fall uppmanas lärarna att komma in och använda lokalerna för att ge feedback.
-
Installation:
När testen av produkten är klar i alla aspekter kan produkten släppas ut på marknaden eller installeras i kundens lokaler. I detta skede överlämnas också den kompletta produktdokumentationen.
När det gäller vår skola invigs den formellt (helst med ett stort skott!) Och skolan påbörjar verksamheten!
-
Underhåll:
I detta skede fixar IT-teamet alla problem som kan uppstå när kunden faktiskt börjar använda produkten, eller när det finns en produktförbättring. Bra dokumentation är ryggraden i underhåll. Frågor korrigeras genom att modifiera koder, kallade ”patches”.
Om stora förändringar krävs kan projektet gå tillbaka till utvecklingsgruppen som ett nytt projekt.
I vårt exempel behöver skolan regelbundet underhåll, mestadels infrastrukturell, till exempel felaktig elektrisk ledning eller läckande badrum. Dessa problem måste hanteras då och då.
Som ni nu ser är stadierna i projektledningen för vattenfallsutveckling distinkta, och även om det vanligtvis är konstant interaktion med klienten, är det främst att diskutera projektets framsteg, inte designen eller kraven. Men projektledningsmodellen för vattenfall hade tjänat IT-industrin tillräckligt under många år, och för de flesta projekt håller stadierna fortfarande bra, men inte lika styva.
Det finns emellertid flera projekt för vilka projektledningsmodellen för vattenfall är mycket lämpad.
Vilket slags projekt passar Waterfall Project Management för?
Produktdefinition:
Först måste slutresultatet (produkten) kunna definieras väl i början. Projekt där produktägaren inte är särskilt säker på exakta specifikationer för den önskade produkten kan vara bra att följa Agile Management-rutiner.
Dokumentation:
Projektet ska vara ett som kan dokumenteras. Dokumentation är ett viktigt krav i projektledningsmodellen för vattenfall. Produktkraven, designen och källkoden ska tydligt dokumenteras i alla steg. Om de ursprungliga medlemmarna i teamet slutar bildar detta vägledningen för projektets kontinuitet.
Tid och resurser:
Det får inte finnas någon omedelbar brådskning att släppa produkten. Tidslinjerna är inställda i början av projektet och teamet måste kunna följa dem. Det måste också finnas gott om resurser när det gäller arbetskraft och teknik.
Risk och osäkerhet:
Waterfall Project Management Tools fungerar inte bra i en miljö med risk och osäkerhet. Till exempel är mobilappen en typ av produkt som står inför ständig osäkerhet när det gäller kundens acceptans och konkurrens av liknande appar.
Tydligt definierade stadier:
Stegen i systemet bör vara väl definierade eftersom de måste slutföras i följd och det kan inte finnas någon överlappning.
När en ny version av befintlig programvara skapas.
Utanför IT-domänen har Waterfall-projektledningsmodellen framgångsrikt använts i enorma projekt som
- Flygplan
- Infrastrukturprojekt som broar
- Tillverkning av försvarsutrustning
- Sjukvårdssystem på sjukhus
I IT-projekt är Waterfall Project Management särskilt lämpad för de projekt där extern hårdvara krävs. Specifikationerna för detta kan inte ändras halvvägs eftersom det skulle leda till förlust av miljoner dollar.
När brister i Waterfall Project Management visade sig i mjukvaruindustrin var det en hel del tankar om hur IT-team kan leverera maximalt värde till klienterna samtidigt som de garanterar flexibilitet i arbetsflödesprocessen.
Och därmed föddes Agile Project Management System, som nu antas av de flesta mjukvaruföretag.
Waterfall Project Management vs Agile Systems:
Agile Project Management-systemet är en flexibel modell som blev populär på 1990-talet. Det handlar om att dela upp projektet i ”miniprojekt” som kallas sprints och arbeta självständigt med var och en av dem. Denna typ av modell gör det möjligt för utvecklarna att snabbt integrera nödvändiga förändringar och det är mycket effektivt där kundmiljön varierar.
Positiven med projektledningsstegen för vattenfall är:
- Eftersom slutprodukten är känd i sin helhet är planeringen och designen entydiga.
- Potentiella problem som kan uppstå i projektet kan strykas ut under själva designfasen; innan någon kod har skrivits.
- Att mäta framstegen i arbetet är lätt eftersom stadierna är väl definierade.
- Teamets stabilitet är där eftersom teamet kvarstår till projektets slut. När det gäller Agile förändras teamet ständigt och detta kräver en viss justering.
- Dokumentationen är omfattande, vilket gör det lättare för team att hantera om en medlem lämnar.
- Utvecklare tycker att den här modellen är lättare att arbeta med eftersom den är lätt att förstå,
- Efter kravfasen behövs slutkundens aktiva deltagande endast i testfasen. Detta beror på att alla krav har diskuterats tråkigt, vilket inte lämnar någon tvetydighet.
- Produkten kan utvecklas som en helhet istället för att utveckla den i delar.
- Kontrakts- och klienthanteringsfrågor hanteras bättre under projektledningsmodellen för Waterfall.
Positiven med Agile Project Management är:
- Kunden kan interagera med projektgruppen under hela cykeln och kan ändra produkten från tid till annan för att passa den föränderliga miljön.
- Om produkten måste släppas mycket snart på grund av marknadsförhållanden kan Agile Project Management-teamet släppa en grundversion som kan ha avancerade versioner senare.
- Systemet är ganska genomskinligt ur kundens synvinkel och han har en rättvisande uppfattning om scenen där hans produkt är.
- Eftersom klienten prioriterar funktioner, vet teamet att det måste fokusera på de funktioner som erbjuder mest affärsvärde.
- Processen har sin egen fart.
- Lag är flytande och flexibla, vilket möjliggör idéer från varje medlem
- Dokumentationen är minimal, och så frigörs tiden från dessa uppgifter.
Efter många år med båda modellerna som finns sida vid sida, är det uppenbart att:
Waterfall-projektledningsmodellen är effektiv för projektledningen där det väl är minimalt med förändringar när projektet är klart.
Agile Project Management är mer lämpad för Product Management där det är viktigt att vara flexibel för förändringar.
Hur som helst, Waterfall-projektledningssystemet är fortfarande en viktig komponent i de flesta IT-projekt. Man kan inte säga säkert att ett visst projekt strikt följer Agile Management Practices. Det är vanligtvis att Agile-principer ”integreras” i IT-projekt.
Vissa Agile Project Management har projektledare medan strikt en Agile-modell endast har Scrum Masters. Detta är hybridkombinationer av Agile och Waterfall Project Management-modeller som vissa kallar "Agifall" eller "Agency Agile" -projekt.
Populariteten för Waterfall-projektledningssystemet beror också på att kontrakts- och kundhanteringsfrågor hanteras bättre med Waterfall Project Management-metoder.
Medan fler och fler projekt faller under Agile Project Management-vikten och fler företag ser fördelarna med en flexibel förvaltningsmodell, är populariteten för projektet för Waterfall-projektledningen utan tvekan avtagande.
Det är dock svårt att föreställa sig en framtid för IT-projekt som är helt smidiga, inom en snar framtid. Och Waterfall Project Management, som hjälpte programvaruindustrin genom sin barndom kommer att leva vidare i några få delar av projektledningen åtminstone under några år framöver.
Första bildkälla: picjumbo.com
relaterade artiklar
- 6 användbara arbetsflödessteg i projektledningen av vattenfall
- Effektiva tips för gruppdiskussion (expertråd)
- Topp 10 Projektledning Myter Busted
- 6 effektiva skäl till att alla behöver ett passionsprojekt på jobbet
- Topp 5 typer av rapporteringsverktyg för projektledning
- Produkthantering vs varumärkeshantering - användbara skillnader