Grote uitdagingen binnen software ontwikkeltrajecten zijn het binnen het budget blijven en het opleveren van een product dat voldoet aan de wens van de klant.
Softwareprojecten worden vaak aangeboden volgens het fixed price/fixed date principe. Als projectaanpak wordt vaak gekozen voor de watervalmethode [Waterfall]. Deze methode is vergelijkbaar met het bouwen van huizen. Eerst maak je een volledig afgebakend plan, vervolgens bouw je exact volgens de specificatie. Echter, in de jaren ‘80 werd al gezegd dat de vaak gemaakte vergelijking tussen het bouwen van huizen en het bouwen van software niet opgaat. Toch houden wij, de IT-leveranciers, samen met onze klanten deze illusie in stand door projecten aan te bieden volgens een watervalmodel met een vaste projectprijs en vast oplevermoment.
Omdat het model niet goed matcht met de software ontwikkeling leidt dit tot irritaties bij zowel de klant als de leverancier.

In dit artikel ga ik in op andere manieren om software ontwikkeling aan te pakken.

Verschillen tussen software- en huizenbouw
Er zijn natuurlijk parallellen te vinden tussen het bouwen van huizen en het bouwen van software. Er zijn echter ook grote verschillen. Bij het bouwen van een huis wordt er vanuit gegaan dat de specificaties vooraf nagenoeg exact bekend zijn. Op het moment dat de fabricage begint zijn de aanpassingsmogelijkheden beperkt tot kleine- en cosmetische zaken [Blum]. Het watervalmodel is op dit principe gebaseerd.
Het ontwikkelen van een stuk software is echter iets anders dan het bouwen van een huis. Van de verschillen die er zijn wil ik er 2 noemen:

1. Uit ervaring blijkt dat de wens van de klant vaak verandert gedurende softwareprojecten tov de oorspronkelijke wens. Redenen hiervoor zijn een verschuivende behoefte of voortschrijdend inzicht. Het watervalmodel dwingt dat aan de eerder vastgestelde scope wordt vastgehouden. Dit is voor de klant vaak onacceptabel;
2. Het ontwikkelen van software is dynamischer dan het bouwen van huizen. Gedurende de realisatie zijn de aanpassingsmogelijkheden niet beperkt tot enkel cosmetische zaken, waardoor de scope flexibeler kan worden bijgestuurd.

Kernpunt is dat klanten vaak scopewijzigingen willen doorvoeren binnen een softwareproject en de mogelijkheden hiertoe worden beperkt door het ontwikkelmodel.

Waarom dan toch het watervalmodel?
Hoe kan het dat we dan toch projecten aanbieden volgens een model dat bedoeld is voor andersoortige ontwikkeltrajecten? Historie geeft een antwoord. Toen het ontwikkelen van software zonder duidelijk ontwerp niet meer afdoende bleek werd er gekeken naar ontwikkelprocessen die al bekend waren [Sorensen]. Daarnaast is er bij aanvang van projecten vaak nog geen vertrouwen tussen opdrachtgever en opdrachtnemer. De opdrachtgever start met de wens voor een stuk software. Deze wens legt hij neer bij een softwareleverancier. Hij wil daarbij gelijk een garantie, voor een vaste prijs, dat de leverancier dit ook gaat realiseren. Door de vaste prijs is de leverancier bang voor budgetoverschreiding wanneer hij scopewijzigingen gedurende het project toestaat.

Om van het watervalmodel af te komen moet de benadering van het project aan beide kanten veranderen. De opdrachtgever moet erop vertrouwen dat de leverancier hem gaat helpen om zijn doel te verwezenlijken binnen bepaalde budgetgrenzen. Andersom moet de softwareleverancier gedreven zijn om de klant te helpen zijn doel te bereiken, ook als hiervoor de scope van het project moet wijzigen.

Alternatieve ontwikkelmodellen
Het watervalmodel is voor deze projectbenadering niet goed te gebruiken als software ontwikkelmodel. Gelukkig zijn er alternatieven. In de jaren 80 werden bijvoorbeeld al het incrementele model en het Spiral model bedacht [Boehm]. In het incrementele model wordt het watervalmodel herhaaldelijk toegepast om telkens delen van de functionaliteit te ontwikkelen. Het Spiral model lijkt op het watervalmodel. Bij dit model worden de requirements steeds verder uitgewerkt aan de hand van prototypes.

Naast deze methoden kan ook de uit DSDM (Dynamic Systems Development Method) afkomstige techniek van timeboxing worden gehanteerd [DSDM]. Hierbij wordt het budget voor een projectfase vastgesteld, maar nog niet het resultaat. De eisen en wensen van de klant worden vooraf op prioriteit geordend. Bij het ontwikkelen worden deze van hoogste- naar laagste prioriteit ontwikkeld totdat het budget op is. De prioriteiten voor nog niet ontwikkelde onderdelen kunnen hierbij nog worden veranderd gedurende het proces.

Een vergelijkbare methode is de op dit moment populaire Scrum aanpak [Scrum]. Hierbij wordt telkens in een periode van 30 dagen (een zogenaamde Sprint) een stuk functionaliteit ontwikkeld. De klant maakt de keuze welk deel van de functionaliteit hierbij belangrijk is. Voor elke sprint maakt de klant opnieuw keuzes en kan nieuwe functionele requirements introduceren.
Voor deze methoden en technieken geeft onderstaande tabel wat eigenschappen:

Vooral bij de timeboxing en Scrum aanpak ligt de focus op een voortdurende communicatie met de klant over de prioriteiten binnen een project. Hierdoor ontstaan een hoge mate van flexibiliteit en wordt de focus gehouden op de doelstelling van de klant. Omdat bij beide vooraf een budget wordt vastgesteld leidt deze flexibiliteit niet tot ontsporende projecten.

Scrum en timeboxing lijken een klant meer onzekerheid te geven over de functionaliteit van het uiteindelijke eindproduct. Dit is echter niet het geval wanneer de IT-leverancier vooraf een realistische inschatting geeft voor de functionele wensen van de klant op dat moment. Hiermee kan een budget worden vastgesteld waarbinnen in principe de wensen van de klant kunnen worden gerealiseerd. Omdat niet wordt vastgelegd dat het eindresultaat persé uit de op dat moment bekende wensen bestaat geeft het de vrijheid om gedurende het project, binnen het budget, de scope van het project te veranderen. Hierdoor kan er zorg voor worden gedragen dat het resultaat beter aansluit op het doel dat de klant heeft met het product.

Conclusie
Persoonlijk zou ik graag zien dat we het watervalmodel zo snel mogelijk achter ons laten. Het is gewoon niet geschikt om in te spelen op de behoefte van de klant. Daarnaast zijn er uitstekende alternatieven die een hoge mate van flexibiliteit geven, met behoud van de budgetvastheid voor de klant. Met name Scrum en timeboxing zijn interesante ontwikkelmodellen omdat de klant hier constant bij het ontwikkeltraject wordt betrokken. Door de 30 dagen iteraties van Scrum is deze aanpak voor de wat grotere projecten geschikt. Voor kleinere projecten kan het principe van timeboxing ook eenvoudig worden toegepast. Dit laatste heb ik zelf ook bij Finalist met succes zien gebeuren, met een tevreden klant! Met beide methoden wordt een project veel meer een joint-effort met de klant. Ik weet zeker dat dit een positief effect heeft op het eindresultaat voor klant én leverancier.

Non-internet referentie:

• Blum, Bruce I., Software Engineering: A Holistic View, 1992.