Waterfall Project Management - I dag ser de fleste IT-team på å ta i bruk Agile Project Management-systemer. Men det de ender opp med å ta i bruk Agile Project Management- systemer til prosjektene sine. Dette betyr en kombinasjon av tradisjonelle prosjektstyringssystemer (kalt Waterfall Project Management Systems), kombinert med prinsippene for Agile Management, som beskrevet i det originale Agile Manifesto.
Når flere prosjekter over hele verden innlemmer Agile Project Management-praksis, betyr det at slutten på prosjektledelse av fossefall? Vil alle IT-prosjekter ende opp med å bli smidig prosjektledelse?
For å forstå de forskjellige modellene, inkludert Agile, og bruke de som passer best for din situasjon, er det viktig å først forstå hva det tradisjonelle prosjektstyringssystemet, kalt Waterfall Project Management Model, handler om.
Waterfall-prosjektledelsesmodellen, så kalt på grunn av arbeidsflytprosessen, er preget av følgende:
- Sluttproduktet blir først visualisert i detalj.
- Deretter implementeres trinnene i arbeidsflyten i rekkefølge:
- Krav og analyse
- Design
- Gjennomføring
- testing
- Installasjon
- Vedlikehold
- Prosjektplanen skal være idiotsikker fordi en gang et trinn i sekvensen er fullført, ikke kan utviklere se det samme uten å starte planleggingen på nytt.
- Det er lite rom for endringer eller feil, og prosjektplanen må følges nøye.
Opprinnelse til Waterfall Project Management-modell:
I de tidlige stadiene av IT-bransjen var det ingen spesifikk modell for programvareutvikling.
Så industrien tok i bruk den sekvensielle arbeidsflytmodellen som ble brukt i industrien og byggebransjen. Disse næringene hadde veldefinerte stadier av arbeid, og de hadde utviklet en modell som tilfredsstilte deres behov for stram kostnadskontroll. Så maskinvarebransjens modell ble brukt til programvareindustrien.
Winston W Royce presenterte denne modellen først i 1970, men han brukte ikke begrepet “Waterfall Project Management”. Faktisk presenterte han modellen som en mangelfull. Den billedlige representasjonen av modellen så ut som en fallende foss. Thomas E. Bell og TA Thayer brukte senere begrepet “fossefall” i papiret fra 1976, “Programvarekrav: Er de virkelig et problem?”, Og begrepet ble værende.
Det er en rekke varianter av denne modellen. De ofte brukte seks distinkte fasene i Waterfall-prosjektledelsesmodellen er forklart nedenfor. Avhengig av prosjektet, kan imidlertid to trinn kombineres.
La oss vurdere eksemplet med å bygge en skole som et eksempel for å bedre forstå prosjektledelsesmodellen for fossefall.
-
Krav og analysefase:
Først må vi vite nøyaktig hva vi designer. For dette, vil vi kanskje:
- Gjennomfør detaljerte diskusjoner med kunden
- Prøv å visualisere produktet med de minste detaljer
- Analyser hvilke maskinvare- og programvarekomponenter som er nødvendige
- Liste over detaljene som inkluderer: problemet produktet skal løse, kundens begrensninger, ytelsesnivået og kompatibiliteten med allerede eksisterende systemer.
- Gjennomfør casestudier av et lignende produkt.
- Vurder kravene til hver interessent
- Liste ut spesifikasjonene i produktkravdokumentet, som danner input for neste trinn.
I vårt eksempel på å bygge en skole, viser vi i dette trinnet antall klasserom, materialet som skal brukes til å bygge, personer som kreves, den allerede eksisterende infrastruktur. Vi vil også legge merke til hva skoleledelsen krever (kontorlokale, personalrom), og hva elevene trenger (bedre toaletter, lekeplasser)
-
Design:
I designstadiet blir alt som har blitt visualisert i første etappe gjort til en blåkopi.
I IT-prosjekter består dette av å definere:
- Maskinvaren som skal brukes
- Programvareplattformen som skal brukes, inkludert lokal distribusjon eller skyinstallasjon
- Programvarearkitekturen, inkludert de forskjellige komponentene og modulene som skal opprettes
- Innganger som kreves for at prosjektet skal fungere
- Utganger som kan forventes (ideelt sett vil dette synkronisere med kravene som er beskrevet i tidligere stadium)
Det er to typer design som kommer inn i et programvareprosjekt:
- Logisk design
- Fysisk design
Logisk design:
Dette inkluderer grunnleggende data og prosesser som vil bli inkludert i prosjektet. Den beskriver utformingen av skjemaer og rapporter, utformingen av grensesnittet og databasedesignen. For eksempel, for et nettsted for togbilletter, vil dette designet bestemme hvordan hele prosessen vil fungere: skjermen som den reisende legger inn detaljene sine og hvordan disse dataene vil strømme inn i databasen, og også hvilken type database som vil lagre disse detaljene.
Fysisk design:
Dette er opptatt av utformingen av den fysiske databasen, programmene og prosessene og de distribuerte systemene. Dette gjøres etter den logiske designen og vil omfatte "hvordan" prosjektet skal gjøres: maskinvaren, plattformen det skal utvikles på, de forskjellige databaser, skjermbilder og skjemaer som skal brukes, etc.
-
Gjennomføring:
- Det er her den faktiske utviklingen av programvaren / systemet skjer.
- Innspillet for dette trinnet er designspesifikasjonene levert av forrige trinn.
- Utgangen er en eller flere av produktkomponentene som er bygget etter spesifikasjoner, feilsøkt, testet og integrert for å tilfredsstille systemarkitekturen.
- Denne fasen blir vanligvis ivaretatt av utviklingsteamet som består av programmerere, grensesnittdesignere og andre spesialister, og verktøyene som brukes er kompilatorer, feilsøkere, tolker og medieredaktører.
- Dette stadiet tar vanligvis maksimal tid, og det er viktig å følge nøye med på prosessene og designen. Endringer i designen på dette stadiet er vanskelige i Waterfall Project Management.
- For et stort prosjekt som involverer flere team, anbefales versjonskontroll for å spore endringer i kodetreet og gå tilbake til tidligere øyeblikksbilder for feilhåndtering.
- I vårt eksempel: Selve byggingen av bygningen ved bruk av arbeidskraft og materialer gjøres på dette stadiet.
-
testing:
Testing kan gjøres for produktet som helhet eller for individuelle komponenter. "Test cases" kan bekreftes for å se om produktet kan levere som lovet. Det kan være testing av moduler, systemtesting av det integrerte produktet og akseptasjonstesting. Aksepttesting innebærer å teste produktet for smutthull av sluttbruker eller kunde. Mangler noteres for at implementeringsteamet skal rette opp. Når korreksjonene er gjort, utarbeides en formell produktdokumentasjon.
I eksemplet blir skolens infrastruktur testet, sannsynligvis av et revisjonsteam. I noen tilfeller blir lærere invitert til å komme inn og bruke lokalene for å gi tilbakemelding.
-
Installasjon:
Når testingen av produktet er fullført i alle aspekter, kan produktet frigjøres i markedet eller installeres i kundens lokaler. På dette stadiet blir også den komplette produktdokumentasjonen overlevert.
Når det gjelder skolen vår, blir den formelt innviet (helst med stort skudd!) Og skolen starter driften!
-
Vedlikehold:
I dette stadiet løser IT-teamet eventuelle problemer som kan oppstå når kunden faktisk begynner å bruke produktet, eller når det er en produktforbedring. God dokumentasjon er ryggraden i vedlikehold. Problemer blir utbedret ved å endre koder, kalt “patches”.
Hvis det kreves større endringer, kan prosjektet gå tilbake til utviklingsteamet som et nytt prosjekt.
I vårt eksempel trenger skolen regelmessig vedlikehold, for det meste infrastrukturelle, for eksempel feil elektriske ledninger eller lekkende bad. Disse problemene må løses fra tid til annen.
Som du kan se nå, er stadiene i Waterfall Development Project Management forskjellige, og selv om det vanligvis er konstant samspill med klienten, er det først og fremst å diskutere fremdriften til prosjektet, ikke designet eller kravene. Imidlertid hadde prosjektledelsesmodellen for fosser tilstrekkelig tjent IT-bransjen i mange år, og for de fleste prosjekter holder stadiene fortsatt bra, mens de ikke er like stive.
Det er imidlertid flere prosjekter som Waterfall-prosjektledelsesmodellen er svært godt egnet for.
Hva slags prosjekt passer Waterfall Project Management for?
Produktdefinisjon:
For det første må sluttresultatet (produktet) være i stand til å være godt definert i begynnelsen av seg selv. Prosjekter der produktseieren ikke er veldig sikre på de nøyaktige spesifikasjonene for ønsket produkt, kan gjøre det bra å følge Agile Management-praksis.
dokumentasjon:
Prosjektet skal være et som kan dokumenteres. Dokumentasjon er et viktig krav i prosjektledelsesmodellen for fossefall. Produktkrav, design og kildekode skal være tydelig dokumentert i alle stadier. Hvis de opprinnelige medlemmene av teamet slutter, danner dette guiden for prosjektkontinuitet.
Tid og ressurser:
Det må ikke være øyeblikkelig haster for å slippe produktet. Tidslinjene er satt i begynnelsen av prosjektet, og teamet må kunne følge dem. Det må også være mange ressurser tilgjengelig når det gjelder arbeidskraft og teknologi.
Risiko og usikkerhet:
Waterfall Project Management Tools fungerer ikke bra i et miljø med risiko og usikkerhet. For eksempel er Mobile-appen en type produkt som står overfor konstant usikkerhet når det gjelder kundenes aksept og konkurranse fra lignende apper.
Tydelig definerte stadier:
Trinnene i systemet bør være veldefinerte fordi de må fullføres i rekkefølge og det kan ikke være noen overlapping.
Når en ny versjon av eksisterende programvare opprettes.
Utenfor IT-domenet har Waterfall-prosjektledelsesmodellen blitt vellykket brukt i store prosjekter som
- Flybygg
- Infrastrukturprosjekter som broer
- Produksjon av forsvarsutstyr
- Helsevesen i sykehus
I IT-prosjekter er Waterfall Project Management spesielt egnet for de prosjektene som det kreves ekstern maskinvare. Spesifikasjonene for dette kan ikke endres midtveis, da dette vil føre til tap på millioner av dollar.
Da mangler i Waterfall Project Management ble tydelig i programvareindustrien, var det mye tanke om hvordan IT-team kan levere maksimal verdi til klienter samtidig som de sikrer fleksibilitet i arbeidsflytprosessen.
Og dermed ble Agile Project Management System, som nå blir adoptert av de fleste programvareselskaper, født.
Waterfall Project Management vs Agile Systems:
Agile Project Management-systemet er en fleksibel modell som ble populær på 1990-tallet. Det innebærer å dele opp prosjektet i “miniprosjekter” som heter sprints og jobbe uavhengig av hvert av dem. Denne typen modeller gjør det mulig for utviklerne å integrere nødvendige endringer raskere, og det er veldig effektivt der kundemiljøet er varierende.
Positivene ved trinnene i Waterfall Project Management er:
- Siden sluttproduktet er kjent i sin helhet, er planleggingen og utformingen entydig.
- Potensielle problemer som kan oppstå i prosjektet kan strykes ut i selve designfasen; før noen kode er skrevet.
- Det er enkelt å måle fremdriften i arbeidet siden stadiene er godt definert.
- Teamets stabilitet er der siden teamet forblir til slutten av prosjektet. Når det gjelder Agile, endrer teamet seg konstant, og dette krever en viss justering.
- Dokumentasjon er omfattende, noe som gjør det lettere for team å administrere hvis et medlem forlater.
- Utviklere finner denne modellen enklere å jobbe med da den er lett å forstå,
- Etter kravsfasen er sluttkundens aktive deltagelse bare nødvendig i testfasen. Dette er fordi alle kravene er blitt diskutert tøffe, og ikke etterlater noen tvetydigheter.
- Produktet kan utvikles som en helhet, i stedet for å utvikle det i deler.
- Problemer med kontrakt og klientadministrasjon blir bedre håndtert under prosjektledelsesmodellen for fossefall.
Positivene med Agile Project Management er:
- Kunden kan samhandle med prosjektgruppen gjennom hele syklusen og kan gjøre endringer i produktet fra tid til annen for å passe til det skiftende miljøet.
- Hvis produktet må slippes veldig snart på grunn av markedsforhold, kan Agile Project Management-teamet gi ut en grunnleggende versjon som kan ha avanserte versjoner senere.
- Systemet er ganske gjennomsiktig fra kundens synspunkt, og han har en god ide om scenen der produktet hans befinner seg.
- Siden klienten gir prioritet til funksjoner, vet teamet at det må fokusere på funksjonene som gir mest forretningsverdi.
- Prosessen har sitt eget momentum.
- Lagene er flytende og fleksible, og muliggjør forestillinger fra hvert medlem
- Dokumentasjon er minimal, og dermed frigjøres tiden fra oppgavene.
Etter mange år med begge modeller som eksisterer side om side, er det tydelig at:
Waterfall-prosjektledelsesmodellen er effektiv for prosjektledelse der når prosjektet først er gjort, er det minimale endringer.
Agile prosjektledelse er mer egnet for produktstyring der det er viktig å være fleksibel for endringer.
Uansett er Waterfall-prosjektstyringssystemet fortsatt en viktig komponent i de fleste IT-prosjekter. Man kan ikke si med sikkerhet at et bestemt prosjekt strengt følger Agile Management Practices. Det er som regel at Agile-prinsipper "blir integrert" i IT-prosjekter.
Noen agile prosjektledelser har prosjektledere, mens strengt tatt en smidig modell kun har Scrum Masters. Dette er hybridkombinasjoner av Agile og Waterfall Project Management-modeller som noen kaller “Agifall” eller “Agency Agile” -prosjekter.
Populariteten til prosjektfallshåndteringssystemet Waterfall skyldes også at problemstillinger med kontrakt og klienthåndtering blir bedre håndtert av Waterfall Project Management-metoder.
Mens flere og flere prosjekter hører under Agile Project Management-folden og flere selskaper ser fordelene med en fleksibel styringsmodell, blir populariteten til prosjektfallsmodellen for Waterfall utvilsomt.
Imidlertid er det vanskelig å se for seg en fremtid for IT-prosjekter som er helt smidige, i nær fremtid. Og Waterfall Project Management, som hjalp programvarebransjen gjennom sin spede begynnelse, vil leve videre i noen få komponenter i prosjektstyring i det minste noen få år fremover.
Første bildekilde: picjumbo.com
relaterte artikler
- 6 nyttige arbeidsflytfaser i prosjektledelse av fossefall
- Effektive tips for gruppediskusjon (ekspertråd)
- Topp 10 prosjektledelse Myter Busted
- 6 effektive grunner til at alle trenger et lidenskapsprosjekt på jobb
- Topp 5 typer rapporteringsverktøy for prosjektledelse
- Product Management vs Brand Management - Nyttige forskjeller