Waterfall Project Management - Vandaag overwegen de meeste IT-teams Agile Project Management-systemen te gebruiken. Maar wat ze uiteindelijk doen, is Agile Project Management- systemen aan hun projecten toevoegen. Dit betekent een combinatie van traditionele projectmanagementsystemen (Waterfall Project Management Systems genoemd), gecombineerd met de Principles of Agile Management, zoals beschreven in het originele Agile Manifesto.
Naarmate meer projecten over de hele wereld gebruikmaken van Agile Project Management-praktijken, betekent dit het einde van watervalprojectmanagement? Zullen alle IT-projecten uiteindelijk Agile Project Management worden?
Om de verschillende modellen te begrijpen, inclusief Agile, en om het model te gebruiken dat het beste bij uw situatie past, is het belangrijk om eerst te begrijpen waar het traditionele projectbeheersysteem, het Waterfall Project Management Model, om draait.
Het Waterfall-projectmanagementmodel, zo genoemd vanwege de aard van het workflowproces, wordt gekenmerkt door het volgende:
- Het eindproduct wordt eerst zeer gedetailleerd gevisualiseerd.
- Vervolgens worden de fasen van de workflow in volgorde geïmplementeerd:
- Vereisten en analyse
- Ontwerp
- Implementatie
- testen
- Installatie
- Onderhoud
- Het projectplan moet waterdicht zijn, want zodra een fase in de reeks is voltooid, kunnen ontwikkelaars hetzelfde niet opnieuw bezoeken zonder de planning opnieuw te beginnen.
- Er is weinig ruimte voor wijzigingen of fouten en het projectplan moet nauwgezet worden gevolgd.
Oorsprong van Waterfall Project Management-model:
In de vroege stadia van de IT-industrie was er geen specifiek model voor softwareontwikkeling.
Dus nam de industrie het sequentiële workflowmodel over dat in de productie- en constructie-industrie wordt gebruikt. Deze industrieën hadden goed gedefinieerde fasen van het werk en ze hadden een model ontwikkeld dat voldeed aan hun behoefte aan strakke kostenbeheersing. Dus het hardware-industriemodel werd toegepast op de software-industrie.
Winston W Royce presenteerde dit model voor het eerst in 1970, maar hij gebruikte de term "Waterfall Project Management" niet. In feite presenteerde hij het model als een gebrekkig exemplaar. De picturale weergave van het model zag eruit als een waterval. Thomas E. Bell en TA Thayer gebruikten later de term "waterval" in hun paper uit 1976, "Softwarevereisten: zijn ze echt een probleem?" En de term bleef bestaan.
Er zijn een aantal varianten van dit model. De veel gebruikte zes verschillende fasen in het Waterfall-projectmanagementmodel worden hieronder uitgelegd. Afhankelijk van het project kunnen echter twee fasen worden gecombineerd.
Laten we het voorbeeld van het bouwen van een school beschouwen als een voorbeeld om het projectmanagementmodel voor waterval beter te begrijpen.
-
Vereisten en analysefase:
Eerst moeten we precies weten wat we ontwerpen. Hiervoor willen we misschien:
- Voer gedetailleerde gesprekken met de klant
- Probeer het product duidelijk te visualiseren met de kleinste details
- Analyseer welke hardware- en softwarecomponenten vereist zijn
- Maak een lijst van de details, waaronder: het probleem dat het product moet oplossen, de beperkingen van de klant, het prestatieniveau en de compatibiliteit met reeds bestaande systemen.
- Casestudy's van een soortgelijk product uitvoeren.
- Overweeg de vereisten van elke stakeholder
- Maak een lijst van de specificaties in het document met productvereisten, dat de invoer vormt voor de volgende stap.
In ons voorbeeld om een school te bouwen, vermelden we in deze stap het aantal klaslokalen, het te gebruiken materiaal, de benodigde mensen, de reeds bestaande infrastructuur. We noteren ook wat de schoolleiding nodig heeft (kantoorruimte, personeelsruimte) en wat de studenten nodig hebben (betere toiletten, speelplaatsen)
-
Ontwerp:
In de ontwerpfase wordt alles dat in de eerste fase is gevisualiseerd omgezet in een blauwdruk.
In IT-projecten bestaat dit uit het definiëren van:
- De hardware die zal worden gebruikt
- Het te gebruiken softwareplatform, inclusief lokale of cloud-implementatie
- De software-architectuur, inclusief de verschillende componenten en modules die moeten worden gemaakt
- Vereiste invoer om het project succesvol te laten werken
- Uitgangen die kunnen worden verwacht (idealiter wordt dit gesynchroniseerd met de vereisten die in de eerdere fase zijn beschreven)
Er zijn twee soorten ontwerp die een rol spelen in een softwareproject:
- Logisch ontwerp
- Fysiek ontwerp
Logisch ontwerp:
Dit omvat de basisgegevens en -processen die in het project worden opgenomen. Het beschrijft het ontwerp van formulieren en rapporten, het ontwerp van de interface en het databaseontwerp. Voor een website voor treinkaartjes zal dit ontwerp bijvoorbeeld bepalen hoe het hele proces zal werken: het scherm waarop de reiziger zijn gegevens invoert en hoe die gegevens in de database vloeien, en ook welk type database deze gegevens opslaat.
Fysiek ontwerp:
Dit betreft het ontwerp van de fysieke database, de programma's en processen en de gedistribueerde systemen. Dit gebeurt na het logische ontwerp en omvat "hoe" het project zal worden uitgevoerd: de hardware, het platform waarop het zal worden ontwikkeld, de verschillende databases, schermen en formulieren die zullen worden gebruikt, enz.
-
Implementatie:
- Hier vindt de daadwerkelijke ontwikkeling van de software / het systeem plaats.
- De input voor deze fase zijn de ontwerpspecificaties van de vorige fase.
- De output is een of meer van de productcomponenten die volgens specificaties zijn gebouwd, zijn gedebugged, getest en geïntegreerd om aan de systeemarchitectuur te voldoen.
- Deze fase wordt meestal verzorgd door het ontwikkelteam dat bestaat uit programmeurs, interfaceontwerpers en andere specialisten en de gebruikte tools zijn compilers, debuggers, tolken en media-editors.
- Deze fase duurt meestal de maximale tijd en het is belangrijk om de processen en het ontwerp nauwgezet bij te houden. Wijzigingen in het ontwerp in dit stadium zijn moeilijk in Waterfall Project Management.
- Voor een groot project waarbij meerdere teams betrokken zijn, wordt versiebeheer aanbevolen om wijzigingen in de codestructuur bij te houden en terug te keren naar eerdere snapshots voor foutafhandeling.
- In ons voorbeeld: de feitelijke constructie van het gebouw met arbeid en materialen gebeurt in deze fase.
-
testen:
Testen kan worden gedaan voor het product als geheel of voor afzonderlijke componenten. "Testgevallen" kunnen worden geverifieerd om te zien of het product kan leveren zoals beloofd. Er kunnen modules worden getest, systeemtests van het geïntegreerde product en acceptatietests. Acceptatietests omvatten het testen van het product op lacunes door de eindgebruiker of klant. Defecten worden genoteerd voor het implementatieteam om dit te corrigeren. Nadat de correcties zijn aangebracht, wordt een formele productdocumentatie opgesteld.
In het voorbeeld wordt de infrastructuur van de school getest, waarschijnlijk door een auditteam. In sommige gevallen worden leraren uitgenodigd om binnen te komen en het gebouw te gebruiken om feedback te geven.
-
Installatie:
Nadat het testen van het product in alle aspecten is voltooid, kan het product op de markt worden gebracht of bij de klant worden geïnstalleerd. In dit stadium wordt ook de volledige productdocumentatie overhandigd.
In het geval van onze school wordt deze formeel ingewijd (bij voorkeur door een groot schot!) En begint de school met werken!
-
Onderhoud:
In deze fase lost het IT-team problemen op die kunnen optreden zodra de klant het product daadwerkelijk begint te gebruiken, of wanneer er een productverbetering is. Goede documentatie is de ruggengraat van onderhoud. Problemen worden verholpen door codes te wijzigen, "patches" genoemd.
Als er grote veranderingen nodig zijn, kan het project als nieuw project teruggaan naar het ontwikkelingsteam.
In ons voorbeeld heeft de school regelmatig onderhoud nodig, meestal infrastructureel, bijvoorbeeld defecte elektrische bedrading of lekkende badkamers. Deze problemen moeten van tijd tot tijd worden aangepakt.
Zoals je nu kunt zien, zijn de fasen in Waterfall Development Project Management verschillend, en hoewel er meestal constante interactie is met de klant, is het vooral om de voortgang van het project te bespreken, niet het ontwerp of de vereisten. Het projectmodel voor watervalprojecten had de IT-industrie echter al vele jaren voldoende gediend, en voor de meeste projecten zijn de fasen nog steeds goed, hoewel niet zo rigide.
Er zijn echter verschillende projecten waarvoor het Waterfall-projectmanagementmodel zeer geschikt is.
Voor welk soort project is Waterfall Project Management geschikt?
Product definitie:
Ten eerste moet het eindresultaat (product) in het begin zelf goed kunnen worden gedefinieerd. Projecten waarbij de producteigenaar niet erg zeker is over de exacte specificaties van het gewenste product, kunnen er goed aan doen Agile Management-praktijken te volgen.
Documentatie:
Het project moet er een zijn dat kan worden gedocumenteerd. Documentatie is een belangrijke vereiste van het Waterfall-projectmanagementmodel. De productvereisten, het ontwerp en de broncode moeten in alle fasen duidelijk worden gedocumenteerd. Als de oorspronkelijke leden van het team stoppen, vormt dit de gids voor projectcontinuïteit.
Tijd en middelen:
Er mag geen onmiddellijke urgentie zijn om het product vrij te geven. De tijdlijnen worden aan het begin van het project vastgesteld en het team moet zich eraan kunnen houden. Ook moeten er voldoende middelen beschikbaar zijn op het gebied van mankracht en technologie.
Risico en onzekerheid:
Waterfall Project Management Tools werkt niet goed in een omgeving van risico en onzekerheid. De mobiele app is bijvoorbeeld een soort product dat voor constante onzekerheid staat wat betreft klantacceptatie en concurrentie van vergelijkbare apps.
Duidelijk gedefinieerde fasen:
De fasen van het systeem moeten goed worden gedefinieerd, aangezien ze na elkaar moeten worden voltooid en er geen overlapping mag zijn.
Wanneer een nieuwe versie van bestaande software wordt gemaakt.
Buiten het IT-domein is het Waterfall-projectmanagementmodel met succes gebruikt in grote projecten zoals
- Vliegtuig bouwen
- Infrastructuurprojecten zoals bruggen
- Productie van defensiemateriaal
- Gezondheidszorgsystemen in ziekenhuizen
In IT-projecten is Waterfall Project Management met name geschikt voor die projecten waarbij externe hardware vereist is. De specificaties hiervan kunnen niet halverwege worden gewijzigd, omdat dit zou leiden tot verlies van miljoenen dollars.
Toen tekortkomingen in het Waterfall Project Management aan het licht kwamen in de software-industrie, werd er veel nagedacht over hoe IT-teams klanten maximale waarde kunnen bieden en tegelijkertijd flexibiliteit in het workflowproces kunnen garanderen.
En zo werd het Agile Project Management Systeem, dat nu door de meeste softwarebedrijven wordt overgenomen, geboren.
Waterfall Project Management vs Agile Systems:
Het Agile Project Management-systeem is een flexibel model dat populair werd in de jaren negentig. Het omvat het opsplitsen van het project in "mini-projecten" genaamd sprints en onafhankelijk werken aan elk van hen. Dit soort model stelt de ontwikkelaars in staat om vereiste veranderingen sneller op te nemen en het is zeer effectief wanneer de klantomgeving variabel is.
De positieve punten van Waterfall Project Management-stappen zijn:
- Omdat het eindproduct volledig bekend is, zijn de planning en het ontwerp ondubbelzinnig.
- Potentiële problemen die zich in het project kunnen voordoen, kunnen tijdens de ontwerpfase zelf worden opgelost; voordat er code is geschreven.
- Het meten van de voortgang van het werk is eenvoudig omdat de fasen goed zijn gedefinieerd.
- Stabiliteit van het team is er omdat het team blijft tot het einde van het project. In het geval van Agile verandert het team voortdurend en dit vereist een zekere aanpassing.
- Documentatie is uitgebreid, waardoor het voor teams gemakkelijker is om te beheren als een lid vertrekt.
- Ontwikkelaars vinden dit model gemakkelijker om mee te werken omdat het gemakkelijk te begrijpen is,
- Na de fase Vereisten is actieve deelname van de eindklant alleen nodig in de testfase. Dit komt omdat alle vereisten versleten zijn en geen dubbelzinnigheid achterlaten.
- Het product kan in zijn geheel worden ontwikkeld, in plaats van het in delen te ontwikkelen.
- Contract- en klantbeheerproblemen worden beter afgehandeld onder het Waterfall project management Model.
De pluspunten van Agile Project Management zijn:
- De klant kan gedurende de hele cyclus met het projectteam communiceren en kan het product van tijd tot tijd aanpassen aan de veranderende omgeving.
- Als het product vanwege marktomstandigheden zeer snel moet worden vrijgegeven, kan het Agile Project Management-team een basisversie uitbrengen die later geavanceerde versies kan hebben.
- Het systeem is vrij transparant vanuit het oogpunt van de klant en hij heeft een redelijk idee van de fase waarin zijn product zich bevindt.
- Omdat de klant de prioriteit van functies biedt, weet het team dat het zich moet concentreren op de functies die de meeste zakelijke waarde bieden.
- Het proces heeft zijn eigen momentum.
- Teams zijn vloeiend en flexibel, waardoor ideeën van elk lid mogelijk zijn
- Documentatie is minimaal, en dus wordt tijd vrijgemaakt van die taken.
Na vele jaren dat beide modellen naast elkaar bestonden, is het duidelijk dat:
Het Waterfall-projectmanagementmodel is effectief voor projectmanagement waarbij, zodra het project klaar is, er minimale wijzigingen zijn.
Agile Project Management is geschikter voor Product Management waar het belangrijk is om flexibel te zijn in veranderingen.
Hoe dan ook, het Waterfall-projectbeheersysteem blijft een belangrijk onderdeel van de meeste IT-projecten. Men kan niet met zekerheid zeggen dat een bepaald project strikt Agile Management Practices volgt. Het is meestal dat Agile-principes worden "opgenomen" in IT-projecten.
Sommige Agile Project Management hebben projectmanagers, terwijl strikt een Agile-model alleen Scrum Masters heeft. Dit zijn hybride combinaties van Agile en Waterfall Project Management-modellen die sommigen 'Agifall'- of' Agency Agile'-projecten noemen.
De populariteit van het Waterfall-projectbeheersysteem is ook te wijten aan het feit dat problemen met contract- en klantbeheer beter worden opgelost door Waterfall Project Management-methoden.
Terwijl steeds meer projecten onder de Agile Project Management-vouw vallen en meer bedrijven de voordelen zien van een flexibel managementmodel, is de populariteit van het Waterfall-projectmanagementmodel ongetwijfeld aan het afnemen.
Het is echter moeilijk om een toekomst te voorzien voor IT-projecten die volledig Agile zijn, in de nabije toekomst. En Waterfall Project Management, dat de software-industrie door zijn kinderschoenen hielp, zal nog een paar jaar in een paar componenten van projectmanagement voortleven.
Eerste afbeeldingsbron: picjumbo.com
gerelateerde artikelen
- 6 Handige workflowstadia in projectbeheer met waterval
- Effectieve tips voor groepsdiscussie (advies van experts)
- Top 10 Mythes over projectmanagement betrapt
- 6 effectieve redenen Iedereen heeft op het werk een passieproject nodig
- Top 5 soorten projectmanagement rapportagetool
- Productmanagement versus merkmanagement - Nuttige verschillen