Agile Informatie Technologie

en hoe Scrum toe te passen

De waterval methode

De waterval methode is wellicht de oudste en nog steeds veelvuldig toegepaste methode voor software ontwikkeling.


De methode leent zich goed om kleinere projecten uit te voeren met vaste, achteraf niet onderhandelbare, requirements. Op voorhand kunnen de kosten en opleverdatum worden afgesproken. Een risico-opslag voor tegenvallers van 30% of meer is gebruikelijk evenals een afspraak voor de tarieven voor meerwerk. Een waterval project kan gemakkelijk worden uitbesteed als vooraf de acceptatiecriteria en de QA eisen goed zijn afgesproken. Een groot nadeel is dat direct voor de finale test de integratie van afzonderlijk ontwikkelde en externe componenten plaats moet vinden. Niet zelden blijkt pas dan dat het werk niet af is, met een budget- en tijdsoverschrijding als gevolg. Lees hier verder over de methode.

De methode schrijft voor dat een fase moet zijn afgesloten voordat met de volgende wordt begonnen. Ik de praktijk wordt dat niet gedaan omdat er dan leegloop ontstaat en men geen tijd en geld wil verliezen. Deze dakpansgewijze aanpak is toegepast bij het project van de belastingdienst voor de huur- en zorgtoeslag. In combinatie met andere factoren en het ontbreken van een versiebeheersysteem leidde dat tot een enorme kostenoverschrijding.

De waterval methode is niet geschikt voor grote, langdurige en risicovolle projecten. Van dergelijke projecten is zeker dat de vooraf vastgestelde requirements of het pakket van eisen zal moeten worden bijgesteld gedurende het project. Is het niet door voortschreidend inzicht dan is het wel omdat de omgeving is veranderd. De waterval methode is daar niet op ingericht omdat bij een verandering van eisen het hele proces van analyse, ontwerp, bouw en test opnieuw moet worden doorlopen. Ook het budget en doorlooptijd moeten per verandering opnieuw worden vastgesteld. Het Scrum framework doorloopt iedere iteratie (van standaard 2 weken) alle fasen van ontwerp tot test en is daarmee bij uitstek geschikt om veranderde eisen en inzichten te verwerken.

Dat grote waterval projecten toch kunnen slagen ligt vooral aan de kwaliteiten van de projectmanager. Mijn aanpak was om dagelijks een gedetailleerde projectplanning bij te werken en deze wekelijks met de opdrachtgever door te nemen op risico's. Bij iedere verandering van specificaties maak ik aan de opdrachtgever en gebruikersvertegenwoordiging duidelijk wat de consequenties zijn. In eerste instantie wordt dan op de reserves (slack) ingeteerd. Gaat dat te snel, of is de slack op, dan onderhandel ik namens de opdrachtgever met de gebruikers over een ruil van minder belangrijke functionaliteit met de zo gewenste nieuwe eisen. Een mooi voorbeeld van deze aanpak was het Artemis project van VNU Publitec.

Aan de verschillende fasen van de methode ontlenen veel functies in de IT hun naam. Zoals Definitiestudie/ analyse (analist), basisontwerp (architect), Technisch ontwerp/detailontwerp (technisch ontwerper), Bouw (ontwikkelaar), Testen (tester), implementatie en beheer (beheerder) en onderhoud (applicatie specialist).

De waterval methode is ongeschikt voor grote of risicovolle projecten. Daartoe is Scrum de beste aanpak. Alleen een goede projectmanager kan door met gezag en overtuiging te onderhandelen over de scope van een waterval project toch nog een goed resultaat bereiken.

© 2006-2018 | Created by Erik Verheul