Waarom de watervalmethode verboden moet worden

Tot een paar jaar geleden werd de watervalmethode nog volop toegepast in software projecten.

Het is al jaren een feit. Meer dan de helft van alle IT projecten eindigt niet goed. Het lukt niet om de software binnen tijd en budget op te leveren of de geleverde software voldoet niet aan de verwachtingen van de gebruikers of de managers. Hoe kunnen we het tij keren?

De bron van alle kwaad: de watervalmethode

Tot een paar jaar geleden werd de watervalmethode nog volop toegepast in software projecten. Het project werd opgedeeld in verschillende achtereenvolgende fasen: definitiestudie, basisontwerp, detailontwerp, bouw, test, integratie en beheer. Pas als de éne fase afgerond was, kon de volgende beginnen.

Deze manier van werken is voortgekomen uit de productie industrie. IT bedrijven werden gezien als fabrieken waar aan de lopende band zo efficiënt mogelijk standaard producten moeten worden opgeleverd. Inmiddels zijn we erachter dat deze aanpak niet werkt. Het maken van maatwerk software is een creatief proces dat zoveel specifieke kennis vraagt, dat het niet in een mal is te gieten maar juist om een flexibel proces vraagt.

Waarom een waterval nooit werkt

Gelukkig raakt de waterval methode steeds meer uit zwang. De belangrijke nadelen van de watervalmethode:

  • Aan het begin van een traject wordt al vastgelegd wat je allemaal gaat doen. Dat werkt dus niet bij softwareontwikkeling. Tijdens een project wordt steeds meer duidelijk over de omgeving, de wensen van de gebruikers en de technische mogelijkheden. Er moet ruimte zijn voor voortschrijdend inzicht.
  • Na elke fase moet er een product liggen dat 100% volledig is. Daardoor wordt er nauwelijks geprioriteerd. Zo ontstaan vanzelf grote, onbeheersbare projecten die niet meer te managen zijn.
  • Een klein misverstand tijdens het ontwerpproces wordt pas laat in het traject onderkend. Elke tekortkoming in het ontwerp die tijdens het testen wordt ontdekt, kan grote impact hebben.
  • Gebruikers staan gedurende het project grotendeels buiten spel. Ze hebben geen inzicht in wat het IT team doet en kunnen er geen invloed op uitoefenen. Het is veel handiger om te werken met korte feedbackloops en gebruikers vanaf het begin mee te nemen in het proces zodat ze betrokken blijven bij het traject. Dit komt niet alleen ten goede van de kwaliteit van het eindproduct, maar ook de acceptatie.

De oplossing: Agile

Om deze valkuilen zo veel mogelijk te ontlopen, hebben we de watervalmethode helemaal afgezworen bij CNOC. We werken helemaal volgens de Agile principes. Dat betekent dat we onze software in sprints van drie weken opleveren waarin we stapsgewijs werken aan het eindproduct.

Minder risico voor de klant

Onze flexibele werkwijze heeft voor de klant belangrijke voordelen: hij hoeft zich niet voor lange tijd vast te leggen, maar betaalt alleen voor de functiepunten die gerealiseerd worden. Is men niet tevreden over de opgeleverde software, dan kan de samenwerking worden opgezegd. De kosten blijven dan beperkt tot de gerealiseerde functiepunten.

Gelukkig kunnen we zeggen dat het nog nooit zover is gekomen. We gaan altijd voor samenwerking op de lange termijn. Het doel is altijd onze software zo snel mogelijk in productie te brengen. Uiteindelijk levert dat de beste resultaten. Komende maand gaan we starten met een nieuw project voor Events Travel. Ook dan gaan we er weer vol tegenaan. We houden jullie op de hoogte!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *