
Da flere projekter overalt i verden inkorporerer Agile Project Management-praksis, betyder det da afslutningen på vandfaldets projektstyring? Vil alle it-projekter ende med at blive Agile Project Management?
For at forstå de forskellige modeller, inklusive Agile, og bruge den, der bedst passer til din situation, er det vigtigt først at forstå, hvad det traditionelle projektstyringssystem, kaldet Waterfall Project Management Model, handler om.
Waterfall-projektledelsesmodellen, der er navngivet på grund af arten af arbejdsgangsprocessen, er kendetegnet ved følgende:
- Slutproduktet visualiseres først i detaljer.
- Derefter implementeres trin i arbejdsgangen i rækkefølge:
- Krav og analyse
- Design
- Implementering
- Test
- Installation
- Vedligeholdelse
- Projektplanen skal være idiotsikker, fordi en gang et trin i sekvensen er afsluttet, kan udviklere ikke se det samme uden at starte planlægningen igen.
- Der er ringe plads til ændringer eller fejl, og projektplanen skal følges nøje.
Oprindelse af Waterfall Project Management-model:
I de tidlige stadier af IT-branchen var der ingen specifik model for softwareudvikling.
Så industrien vedtog den sekventielle workflow-model, der blev brugt i fremstillings- og byggebranchen. Disse industrier havde veldefinerede arbejdsfaser, og de havde udviklet en model, der opfyldte deres behov for stram omkostningskontrol. Så hardwareindustriens model blev anvendt til softwareindustrien.
Winston W Royce præsenterede først denne model i 1970, men han brugte ikke udtrykket “Waterfall Project Management”. Faktisk præsenterede han modellen som en mangelfuld model. Den billedlige repræsentation af modellen lignede et kaskaderende vandfald. Thomas E. Bell og TA Thayer brugte senere udtrykket "vandfald" i deres papir fra 1976, "Softwarekrav: Er de virkelig et problem?", Og udtrykket kom til at blive.
Der er en række varianter af denne model. De ofte anvendte seks forskellige faser i Waterfall-projektstyringsmodellen er forklaret nedenfor. Afhængigt af projektet kan to trin dog kombineres.
Lad os overveje eksemplet med at bygge en skole som et eksempel for bedre at forstå vandfaldets projektstyringsmodel.
-
Krav og analysefase:
Først skal vi vide nøjagtigt, hvad vi designer. Til dette ønsker vi måske:
- Foretag detaljerede diskussioner med kunden
- Prøv at visualisere produktet tydeligt med dets mindste detaljer
- Analyser, hvilke hardware- og softwarekomponenter der kræves
- Skriv de detaljer, der inkluderer: det problem, som produktet skal løse, kundens begrænsninger, ydeevneniveauet og kompatibiliteten med allerede eksisterende systemer.
- Foretag casestudier af et lignende produkt.
- Overvej kravene fra hver interessent
- Liste over specifikationerne i produktkravdokumentet, som danner input til det næste trin.
I vores eksempel på bygning af en skole viser vi i dette trin antallet af klasseværelser, det materiale, der skal bruges til bygning, de nødvendige mennesker, den allerede eksisterende infrastruktur. Vi bemærker også, hvad skoleledelsen kræver (kontorlokale, personalelokale), og hvad eleverne har brug for (bedre toiletter, legepladser)
-
Design:
I designfasen er alt, hvad der er blevet visualiseret i den første fase, lavet til en plan.
I it-projekter består dette af at definere:
- Den hardware, der vil blive brugt
- Den softwareplatform, der skal bruges, inklusive lokal eller cloud-implementering
- Softwarearkitekturen, inklusive de forskellige komponenter og moduler, der skal oprettes
- Input, der kræves for, at projektet kan fungere med succes
- Output, der kan forventes (ideelt set synkroniseres de med kravene, der er beskrevet i det tidligere trin)
Der er to typer design, der kommer i spil i et softwareprojekt:
- Logisk design
- Fysisk design
Logisk design:
Dette inkluderer de grundlæggende data og processer, der vil blive inkluderet i projektet. Det beskriver design af formularer og rapporter, design af interface og databasedesign. For eksempel for et togbilletwebsted bestemmer dette design, hvordan hele processen fungerer: skærmen, som den rejsende indtaster sine detaljer, og hvordan disse data flyder ind i databasen, og også hvilken type database, der lagrer disse detaljer.
Fysisk design:
Dette drejer sig om designet af den fysiske database, programmerne og processerne og de distribuerede systemer. Dette gøres efter det logiske design og vil omfatte “hvordan” projektet skal udføres: hardware, platformen, hvorpå det skal udvikles, de forskellige databaser, skærme og formularer, der vil blive brugt osv.
-
Implementering:
- Det er her den faktiske udvikling af softwaren / systemet finder sted.
- Input til dette trin er designspecifikationerne leveret af den forrige fase.
- Outputet er en eller flere af produktkomponenterne bygget efter specifikationer, debugges, testes og integreres for at tilfredsstille systemarkitekturen.
- Denne fase tages normalt af udviklingsholdet, der består af programmerere, interface-designere og andre specialister, og de anvendte værktøjer er compilers, debuggers, tolke og medieredaktører.
- Denne fase tager normalt den maksimale tid, og det er vigtigt nøje at holde styr på processerne og designet. Ændringer i designet på dette trin er vanskelige i Waterfall Project Management.
- For et stort projekt, der involverer flere teams, anbefales versionskontrol for at spore ændringer i kodetræet og vende tilbage til tidligere snapshots til fejlhåndtering.
- I vores eksempel: Den faktiske konstruktion af bygningen ved hjælp af arbejdskraft og materialer udføres på dette trin.
-
Test:
Testning kan udføres for produktet som helhed eller for individuelle komponenter. "Test cases" kan verificeres for at se, om produktet kan levere som lovet. Der kan være test af moduler, systemtest af det integrerede produkt og acceptstest. Acceptacitetstest involverer afprøvning af produktet for smuthuller fra slutbrugeren eller kunden. Mangler noteres for, at implementeringsteamet kan korrigere. Når korrektionerne er foretaget, udarbejdes en formel produktdokumentation.
I eksemplet testes skolens infrastruktur sandsynligvis af et revisionsteam. I nogle tilfælde opfordres lærerne til at komme ind og bruge lokalerne til at give feedback.
-
Installation:
Når testen af produktet er afsluttet i alle aspekter, kan produktet frigives på markedet eller installeres i kundens lokaler. På dette tidspunkt udleveres også den komplette produktdokumentation.
I tilfælde af vores skole indvies den formelt (helst med et stort skud!), Og skolen starter operationen!
-
Vedligeholdelse:
I dette trin løser IT-teamet eventuelle problemer, der måtte opstå, når kunden rent faktisk begynder at bruge produktet, eller når der er en produktforbedring. God dokumentation er rygraden i vedligeholdelse. Problemer korrigeres ved at ændre koder, kaldet “patches”.
Hvis der kræves større ændringer, kan projektet gå tilbage til udviklingsholdet som et nyt projekt.
I vores eksempel har skolen brug for regelmæssig vedligeholdelse, for det meste infrastrukturelle, for eksempel defekte elektriske ledninger eller lækkende badeværelser. Disse problemer skal løses fra tid til anden.
Som du kan se nu, er stadierne i Waterfall Development Project Management forskellige, og selvom der normalt er konstant interaktion med klienten, er det primært at diskutere projektets fremskridt, ikke designet eller kravene. Imidlertid havde vandfaldets projektstyringsmodel tilstrækkeligt tjent IT-branchen i mange år, og for de fleste projekter er stadierne stadig gode, mens de ikke er så stive.
Der er dog flere projekter, som vandfaldets projektstyringsmodel er meget velegnet til.
Hvilken type projekt er Waterfall Project Management velegnet til?
Produktdefinition:
For det første skal slutresultatet (produktet) være i stand til at være veldefineret i starten af sig selv. Projekter, hvor produktsejeren ikke er særlig sikker på, om de nøjagtige specifikationer for det ønskede produkt kan være godt at følge Agile Management-praksis.
Dokumentation:
Projektet skal være et, der kan dokumenteres. Dokumentation er et vigtigt krav i Waterfall-projektledelsesmodellen. Produktkrav, design og kildekode skal være klart dokumenteret i alle faser. Hvis de originale medlemmer af teamet afslutter, danner dette vejledningen til projektets kontinuitet.
Tid og ressourcer:
Der må ikke være nogen øjeblikkelig haste med at frigive produktet. Tidslinjerne er indstillet i begyndelsen af projektet, og teamet skal kunne overholde dem. Der skal også være rigelige ressourcer til rådighed med hensyn til arbejdskraft og teknologi.
Risiko og usikkerhed:
Waterfall Project Management Tools fungerer ikke godt i et miljø med risiko og usikkerhed. For eksempel er Mobile-appen en type produkt, der står over for konstant usikkerhed med hensyn til kundens accept og konkurrence fra lignende apps.
Tydeligt definerede faser:
Systemets faser skal være veldefinerede, da de skal udføres i rækkefølge, og der kan ikke være nogen overlapning.
Når der oprettes en ny version af eksisterende software.
Uden for IT-domænet er vandfaldets projektstyringsmodel med succes blevet brugt i store projekter som f.eks
- Flybygning
- Infrastrukturprojekter såsom broer
- Fremstilling af forsvarsudstyr
- Sundhedsplejesystemer på hospitaler
I IT-projekter er Waterfall Project Management især velegnet til de projekter, hvor der kræves ekstern hardware. Specifikationerne for dette kan ikke ændres midtvejs, da det ville resultere i tab af millioner af dollars.
Da utilstrækkeligheder i vandfaldets projektstyring blev tydelige i softwarebranchen, blev der tænkt meget på, hvordan it-teams kan levere maksimal værdi til klienterne samtidig med at de sikrer fleksibilitet i arbejdsgangsprocessen.
Og således blev Agile Project Management System, som nu vedtages af de fleste softwarevirksomheder, født.
Waterfall Project Management vs Agile Systems:
Agile Project Management-systemet er en fleksibel model, der blev populær i 1990'erne. Det involverer at opdele projektet i ”miniprojekter” kaldet sprints og arbejde uafhængigt af hver af dem. Denne type model gør det muligt for udviklerne at integrere de nødvendige ændringer hurtigere, og det er meget effektivt, hvor kundemiljøet er variabelt.
Positive ved trin i Waterfall Project Management er:
- Da slutproduktet er kendt i sin helhed, er planlægningen og designen entydig.
- Potentielle problemer, der kan opstå i projektet, kan udskilles i selve designfasen; før der er skrevet nogen kode.
- Det er let at måle arbejdsforløbet, da stadierne er veldefinerede.
- Holdets stabilitet er der, da holdet forbliver indtil projektets afslutning. I tilfælde af Agile skifter holdet konstant, og dette kræver en vis justering.
- Dokumentation er omfattende, hvilket gør det lettere for teams at styre, hvis et medlem forlader.
- Udviklere finder denne model lettere at arbejde med, da den er let at forstå,
- Efter kravets fase er slutkundens aktive deltagelse kun nødvendig i testfasen. Dette skyldes, at alle kravene er blevet drøftede uklare og ikke efterlader nogen tvetydighed.
- Produktet kan udvikles som en helhed i stedet for at udvikle det i dele.
- Problemer med kontrakt- og klientstyring håndteres bedre under projektledelsesmodellen for vandfald.
Positive ved Agile Project Management er:
- Kunden kan interagere med projektgruppen gennem hele cyklussen og kan fra tid til anden foretage ændringer i produktet for at passe til det skiftende miljø.
- Hvis produktet skal frigives meget snart på grund af markedsforhold, kan Agile Project Management-teamet frigive en grundlæggende version, der kan have avancerede versioner senere.
- Systemet er ganske gennemsigtigt ud fra kundens synspunkt, og han har en god idé om det stadie, hvor hans produkt er.
- Da klienten prioriterer funktioner, ved teamet, at det er nødt til at fokusere på de funktioner, der tilbyder mest forretningsværdi.
- Processen har sit eget momentum.
- Holdene er flydende og fleksible, hvilket muliggør ideation fra hvert medlem
- Dokumentation er minimal, og derfor frigøres tiden fra disse opgaver.
Efter mange år med begge modeller, der eksisterer side om side, er det tydeligt, at:
Vandfaldets projektstyringsmodel er effektiv til projektstyring, hvor der, når projektet er færdig, er minimale ændringer.
Agile projektstyring er mere velegnet til produktstyring, hvor det er vigtigt at være fleksibel over for ændringer.
Uanset hvad er vandfaldets projektstyringssystem stadig en vigtig komponent i de fleste it-projekter. Man kan ikke med sikkerhed sige, at et bestemt projekt strengt følger Agile Management Practice. Det er normalt, at Agile-principper "integreres" i it-projekter.
Nogle agile projektledelser har projektledere, hvorimod en agile model kun har Scrum Masters. Dette er hybridkombinationer af Agile og Waterfall Project Management-modeller, som nogle kalder “Agifall” eller “Agency Agile” -projekter.
Populariteten af Waterfall-projektledelsessystemet skyldes også, at problemer med kontrakt og klientstyring håndteres bedre efter Waterfall Project Management-metoder.
Mens flere og flere projekter hører under Agile Project Management-folden, og flere virksomheder ser fordelene ved en fleksibel styringsmodel, falder utvivlsomt populariteten af Waterfall-projektledelsesmodellen.
Det er imidlertid vanskeligt at forestille sig en fremtid for it-projekter, der er helt smidige, i den nærmeste fremtid. Og Waterfall Project Management, som hjalp softwareindustrien gennem sin barndom, vil leve videre i et par komponenter i projektstyring i det mindste i nogle få år fremover.
Første billedskilde: picjumbo.com
relaterede artikler
- 6 Nyttige arbejdsgange i vandfald-projektstyring
- Effektive tip til gruppediskussion (ekspertrådgivning)
- Top 10 myter om projektstyring Busted
- 6 effektive grunde til at alle har brug for et lidenskabsprojekt på arbejdspladsen
- Top 5 typer af projektstyringsrapporteringsværktøj
- Produktstyring vs Brand Management - Nyttige forskelle