Voor een doorsnee automatiseerder is het een bekend ritueel: voor het bouwen van een informatiesysteem dienen we het gehele ontwikkelingstraject op te splitsen in fasen. We beginnen het traject bijvoorbeeld met de analysefase, vervolgen met de ontwerpfase en sluiten af met een bouw- en implementatiefase.
Uiteraard zijn door de jaren heen modieuzere namen voor de fasen gekozen en zijn er nieuwe technieken ontwikkeld. Desondanks is de behoefte aan faseren altijd gebleven. Echter, zijn we er veel wijzer van geworden? We kunnen niet echt concluderen dat tegenwoordig elk project binnen het budget blijft en op de geplande datum afgeleverd wordt. Zitten we niet op een dood spoor met deze faseringsaanpak die gebaseerd is op een klassieke verdeel-en-heers-aanpak?
Eén van de eerste automatiseringsboeken die ik als student, zo’n twintig jaar geleden, moest aanschaffen ging over sdm (‘system development methodology’). Sommigen kunnen zich dat dikke, lichtblauwe boek nog wel herinneren. Buiten dat ik het een duur boek vond, was het ook niet mijn favoriete boek. Niklaus Wirths boek over Pascal lag vaker open op mijn tafel en had aanzienlijk meer notities en ezelsoren. Voor iemand die programma’s van maximaal enkele duizenden regels moest schrijven, was het allemaal een beetje overdreven complex. Het nut van bijvoorbeeld ‘management commitment’ ontging me volledig als ik op mijn zolderkamertje het spelletje boter-kaas-en-eieren zat te programmeren.
Later, na mijn studieperiode, begon ik de waarde van fasering en het opleveren van ‘deliverables’ aan het einde van elke fase wel te realiseren. En het maakte mijn baas altijd zo blij als ik weer een ‘deliverable’ afleverde. Hem gaf het duidelijk een gevoel van controle. Hij dacht dat het voltooien van een ‘deliverable’ ons weer wat dichter bij het voltooien van het project bracht. Dan had hij ook weer wat positiefs aan zijn baas te melden. Voor ons op de werkvloer waren sommige ‘deliverables’ alleen maar lastige hinderpalen op weg naar het echte werk.
Nu nog met sdm werken, kunnen we niet meer als hip betitelen. Maar gelukkig zijn er voor de fans van fasering moderne varianten beschikbaar, zoals rup (‘rational unified process’) en Catalysis. Deze methodieken hanteren enkele nieuwere technieken en hebben de fasering wat aangepast. Beide maken intens gebruik van de vele uml-technieken (‘unified modeling technique’), maar het thema blijft hetzelfde: probeer een project te managen met een verdeel-en-heers-aanpak.
Uiteraard sluit deze fasering prima aan bij de afdelingsstructuren van it-afdelingen. We hebben afdelingen met onder andere analisten, ontwerpers, beheerders en programmeurs. Men kan zich afvragen of de afdelingsstructuren zijn afgeleid van de fasering of andersom.
Een groot nadeel van de fasering is het kennisverlies. Niet alle kennis die analisten opdoen tijdens hun gesprekken met gebruikers komt bijvoorbeeld op papier terecht. Als een bepaalde specificatie niet in één van de technieken past, wordt ze vaak vergeten. En daarmee gaat er een specificatie verloren. Het zou beter zijn als automatiseerders vanaf het begin tot aan het einde bij een project betrokken zijn, zodat vergaarde kennis niet verloren gaat.
Een vraagrondje bij een aantal bekende softwareleveranciers levert het volgende resultaat op: bijna niemand hanteert een aanpak gebaseerd op faseringen. Niemand gebruikt rup of Catalysis en sdm heb ik al helemaal niet meer gevonden. Alleen niam (voor de oudjes) heb ik nog teruggevonden bij Microsoft, maar dat heeft daar dan ook een commercieel belang bij. Misschien dat Rational wel rup gebruikt voor de ontwikkeling van zijn eigen adviezen, omdat die onderneming voor een groot deel ‘leeft’ van deze markt, maar bij bekende tool- en databaseleveranciers wordt het niet gehanteerd. Zij gebruiken allemaal minder formele aanpakken.
Het is dan ook verklaarbaar dat de teleurstellende resultaten van de klassieke methodieken verantwoordelijk zijn voor het ontstaan van nieuwe, enigszins anarchistische varianten, zoals ‘Extreme Programming’ en ‘Agile Modeling’. Zeker in de VS is hier veel belangstelling voor en zijn ze reeds in vele projecten succesvol ingezet. Al verschillen deze aanpakken onderling, ze hebben ook zeker overeenkomsten. Uitgangspunten zijn onder andere dat technieken niet plichtmatig hoeven te worden ingezet, maar alleen wanneer noodzakelijk. ‘Eerst testen en dan ontwikkelen’ is één van de andere basisprincipes. ‘Programmeren in koppels in plaats van autistisch’, is eveneens een fenomeen dat vaak terugkomt. Belangrijk is ook dat bij deze nieuwe methodieken de ontwikkelaars het gehele traject uitvoeren, waardoor ze er zeer intens bij betrokken zijn.
Diegenen die deze vernieuwende ideeën nog geheel niet hebben bestudeerd, raad ik aan hier spoedig tijd in te gaan steken. De haast militaristische – ‘na ons de zondvloed’ – in fasen opgedeelde methodieken hebben al twintig jaar bewezen geen panacee te zijn. Het is tijd dat we eens wat anders gaan proberen.
