Projectmethodologieën uitgelegd: van "Waterfall" naar "Agile"
Als freelance project manager was ik betrokken bij vele projecten. Veel teams gebruiken de term Agile, maar werken in een “Inter-Sprint Waterfall” of “Intra-Sprint Waterfall” proces. In dit artikel leg ik het verschil uit tussen “Waterfall”, “Inter-Sprint Waterfall”, “Intra-Sprint Waterfall” en “Agile”.
Wat is Waterfall?
Het waterfall-model (watervalmodel), voor het eerst geïntroduceerd door Dr. Winston W. Royce in een paper uit 1970, benadrukt een logische opeenvolging van stappen gedurende de software development life cycle (SDLC), vergelijkbaar met de opeenvolgende trappen van een trapsgewijze waterval. Hoewel de populariteit van het watervalmodel de laatste jaren is afgenomen ten gunste van meer agile methodologieën, valt de logische aard van het sequentiële proces niet te ontkennen en blijft het een veelgebruikt ontwerpproces.
Hieronder vindt u de 6 fasen van Waterfall.
Requirements: Tijdens deze beginfase worden de potentiële vereisten van de applicatie methodisch geanalyseerd en vastgelegd in een specificatiedocument dat als basis dient voor alle toekomstige ontwikkeling. Het resultaat is doorgaans een requirements-document dat definieert wat de applicatie moet doen, maar niet hoe.
Analysis: Tijdens deze tweede fase wordt het systeem geanalyseerd om de modellen en business logica te genereren die in de applicatie gebruikt zullen worden.
Design: Deze fase omvat grotendeels de technische ontwerpvereisten, zoals programmeertaal, datalagen, services, enz. Doorgaans wordt er een ontwerpspecificatie opgesteld die precies beschrijft hoe de business logica uit de analyse technisch geïmplementeerd zal worden.
Coding: De eigenlijke broncode wordt uiteindelijk geschreven in deze vierde fase, waarbij alle modellen, business logica en service-integraties uit de voorgaande fasen worden geïmplementeerd.
Testing: In deze fase ontdekken en rapporteren QA, bètatesten en alle andere testers systematisch problemen in de applicatie die opgelost moeten worden. Het is niet ongewoon dat deze fase een “noodzakelijke herhaling” van de vorige codeerfase veroorzaakt om de gevonden bugs definitief weg te werken.
Operations: Ten slotte is de applicatie klaar voor uitrol naar een live omgeving. De operationele fase omvat niet alleen de deployment van de applicatie, maar ook de daaropvolgende ondersteuning en het onderhoud dat nodig is om het functioneel en up-to-date te houden.
High-level overzicht van het Waterfall-proces:
Wat is Inter-Sprint waterfall?
Een “Inter-Sprint Waterfall” ziet er als volgt uit: in één sprint werken de business product owner, waarschijnlijk een business analyst en het visual design team (UX/UI) aan “wat” er gebouwd moet worden. Omdat ze “Agile” werken, nemen ze een agile proces aan. Requirements worden gedocumenteerd in user stories. Deze user stories worden echter niet behandeld als echte user stories, maar eerder als mini-specificatiedocumenten. De mini-specs/user stories zijn bijna onbevattelijk uitgebreid voor een gegeven story.
De volledige sprint 0 wordt verbruikt om de user en technische vereisten uit te zoeken en te documenteren. Er worden grooming sessies gehouden, visuele ontwerpen gemaakt, UX-flows en style guides opgesteld. Een tweede sprint wordt toegevoegd om de nieuwe functies te ontwikkelen. Diverse documenten worden overgedragen aan de programmeurs: visuele ontwerpen, specificatiedocumenten, UX-flows, enz. De programmatie kan pas starten als alle gedefinieerde artefacten zijn opgeleverd. De programmeurs nemen de houding aan dat ze alles zullen bouwen wat gevraagd wordt. Sommige teamleden zijn soms iets meer agile en ontwikkelen mini-specs voordat een user story volledig is afgerond. Andere teamleden vinden het gevaarlijk om op een agile manier te werken.
De derde sprint wordt in sommige organisaties uitsluitend voor testdoeleinden gebruikt. In de Inter-Sprint Waterfall methode werkt het testteam 1 sprint achter op de programmeurs. Gelukkig beseffen de meeste teams dat developers en testers in dezelfde iteratie moeten werken, al trekken ze dit niet door naar het hele team.
Dit leidt tot het proces zoals getoond in deze figuur.
Deze figuur toont een eerste iteratie gewijd aan design. Een tweede iteratie (mogelijk licht overlappend met de eerste) is gewijd aan ontwikkeling. En een derde iteratie is gewijd aan testen. Het kan de eerste stap van uw organisatie zijn naar agile werken, maar het is geen agile.
Wat is Intra-Sprint waterfall?
Mensen die gewend waren in een uitgebreide waterval-omgeving te werken en nieuw zijn in agile, denken vaak dat een sprint een mini-waterval is. Dat is het niet!
“We hebben Agile/Scrum geprobeerd, maar het werkte niet”.
Het team probeerde een iteratieve waterval-aanpak. Dezelfde fouten als beschreven in de “Inter-Sprint Waterfall methode” werden gemaakt. User stories zijn te complex.
Een “Intra-Sprint Waterfall” ziet er zo uit: in één sprint werken de business product owner, waarschijnlijk een business analyst en het visual design team aan wat er gebouwd moet worden. Omdat ze “Agile” werken, gebruiken ze een agile proces. Requirements worden vastgelegd in user stories, maar deze worden behandeld als mini-specificaties. Zodra de requirements klaar zijn, begint het team met ontwikkelen binnen de gedefinieerde time-box. Als de ontwikkeling klaar is, doet het testteam de validatie binnen diezelfde time-box.
Deze aanpak kan werken als features geprioriteerd en getime-boxed zijn, met een sterke definition of done en de afspraak om geen onvolledige features op te leveren.
Wat is agile?
Agile is een specifieke projectmanagementmethodologie, meestal gebruikt door softwareontwikkelaars en ingenieurs. Deze Agile-methodiek is een getime-boxte, iteratieve benadering van softwarelevering die software incrementeel opbouwt vanaf het begin van het project, in plaats van alles in één keer aan het einde te willen leveren. Traditionele technieken focussen op het behalen van mijlpalen via complexe planningstools zoals Gantt-charts. Agile werkt door projecten op te splitsen in kleine stukjes gebruikersfunctionaliteit, genaamd user stories, deze te prioriteren en ze vervolgens continu te leveren in korte cycli van twee weken, iteraties genoemd.
Idealiter zouden in een agile proces alle soorten werk tegelijkertijd eindigen. Er wordt constant om feedback van eindgebruikers gevraagd om developers en de product owner te helpen bij het definiëren van functionaliteiten voor volgende builds. De teams zijn cross-functional en werken aan interacties van een product over een vastgelegde periode. Het werk is georganiseerd in een backlog die geprioriteerd is op basis van de behoeften van de klant. De backlog herinnert elk teamlid eraan dat het doel van elke iteratie het produceren van een werkend product is.
Het team zou de analyse van het probleem afronden op hetzelfde moment dat ze het ontwerp en de oplossing afronden, wat ook hetzelfde moment is waarop het coderen en testen klaar is. Meerdere features worden geanalyseerd, ontwikkeld en getest door de cross-functional teams binnen de time-box. Aan het einde van de iteratie volgt een demo. De klant kan snel feedback geven, waarna wijzigingen geïmplementeerd en naar productie verplaatst kunnen worden.
Agile management is niet altijd de beste keuze voor elke sector, vooral niet bij complexe besluitvormingsprocessen op lange termijn. Agile stelt managers en teamleden echter in staat om snel aanpassingen te doen. Problemen die worden ontdekt voordat ze te ver vorderen, besparen veel tijd en helpen bedrijven binnen budget te blijven.
Het volledige plaatje: “Waterfall” vs “Inter-Sprint Waterfall” vs “Intra-Sprint Waterfall” vs “Agile”
Welke methodologie zou u gebruiken?
Het is niet nodig om te zeggen welke methodologie de beste is. U kunt degene kiezen die het meest geschikt is voor uw project.
Maak zoveel mogelijk gebruik van wat u al weet en hanteer vervolgens een iteratieve "trial-and-error" aanpak om de beste methodologie voor uw situatie te vinden.
Rob Gielen