Geen functiescheiding in app door agile

Onlangs las ik in het Financieele Dagblad een artikel over de problemen rond de stemapplicatie voor het lijsttrekkerschap bij het CDA. Een it'er en een notaris hadden samen onderzoek gedaan naar de applicatie. De conclusie: de applicatie werkt correct. Maar de it-onderzoeker merkte volgens de krant wel op dat ‘er geen functiescheiding tussen ontwerp, bouw, test en operationele ondersteuning van de applicatie’ was.

Toen ik deze passage las, moest ik terugdenken aan dertig of veertig jaar geleden, toen de meeste projecten nog uitgevoerd werden volgens het watervalmodel. Toen had je aparte functies voor functioneel ontwerp, technisch ontwerp, bouw, test en beheer, met bijbehorende salarisschalen. Al deze functies werden uitgevoerd door verschillende personen met ieder hun eigen takenpakket en verantwoordelijkheden. De reden waarom we dat vandaag de dag niet meer zo doen, is dat dat nogal wat problemen veroorzaakt.

Tegenwoordig bouwen we applicaties via een agile-proces in een multidisciplinair team waarbij ieder teamlid verschillende rollen op zich kan nemen en in principe zowel de analyse als design, bouw, test en delivery voor zijn rekening neemt. In een devops-omgeving is het team ook verantwoordelijk voor de operationele ondersteuning. Die functiescheiding waar de it-onderzoeker het hier over heeft, bestaat dus al zo’n dertig à veertig jaar niet meer.

Betekent dat dan dat er geen enkele controle meer is op wat een teamlid ontwerpt en bouwt? Ja, wel degelijk, want in een agile-proces is een work-item pas af als het gereviewd (verified) is door een ander teamlid. Dat laatste is lastig als je team slechts uit één persoon bestaat en dat is vermoedelijk waar de kritiek van de it-onderzoeker zich in dit geval op richt, al drukt hij zich daarbij wat ongelukkig uit.

Het is wel belangrijk ons te realiseren dat de controle die vroeger uitgevoerd werd door de genoemde functiescheiding, tegenwoordig vervangen is door peer reviews. Ook die worden onder tijdsdruk gemakkelijk overgeslagen en dat is natuurlijk niet de bedoeling, want dat kan leiden tot structurele ontwerp- of ontwikkelfouten.