De Agile literatuur erkent het belang van softwarekwaliteit. Want, kwaliteit is belangrijk om flexibel te kunnen doorontwikkelen en om veel ‘rework’ te voorkomen. Een mooie open deur, want kwaliteit vinden we allemaal belangrijk, en rework wil niemand. Maar hoe borg je softwarekwaliteit als de product owner uit de business prioriteert, terwijl hij geen IT-achtergrond heeft? Verloedert de kwaliteit van software bij een Agile aanpak?
Het normenkader voor het duiden van systeemkwaliteit is in de software het de ISO-norm 25010 (2011). De ISO-norm 25010 kent twee hoofdmodellen. Zij beschrijven de systeemkwaliteit in een reeks kenmerken; acht voor het model voor productkwaliteit en vijf kenmerken voor gebruikskwaliteit. Zes kenmerken voor productkwaliteit zijn ‘niet functionele eisen’; het aloude traditioneel specificeren. En hier zit ‘em nu net de kneep…
Haaks hierop lijkt het belang van de product owner. In zijn Agile scrum rol focust hij op direct waarde toevoegen voor de eindgebruikers. Mag van de product owner verwacht worden ook rekenschap te geven aan ‘niet functionele eisen’? Ja, is mijn antwoord hierop. Af en toe klankborden met een architect over dit onderwerp helpt daarbij. De product owner zal immers in de dagelijkse praktijk het sprintresultaat toetsen aan de Definition of Done (DoD). Dit impliceert dat softwarekwaliteit onderdeel is van de DoD. Zeker bij software waarbij doorontwikkeling voorzien is. De DoD bevat dus meer dan de eisen en wensen ten aanzien van functionaliteiten voor gebruikers.
Kan de ISO-norm 25010 hierbij worden toegepast binnen de Agile werkvorm om tot een kwalitatief hoogwaardig systeem te komen? Ja, in mijn ogen wel. De genoemde 13 kenmerken zijn prima controlepunten voor elk backlogitem voorafgaand aan de sprint, Definition of Ready (DoR). Ook kunnen de kenmerken uit de ISO-norm 25010 gebruikt worden om de Definition of Done te verfijnen. De teamleden hebben de norm als handvat om de product owner te vragen naar de ‘niet functionele eisen’. Uiteraard mogen de eisen op gebied van usability, één van de benoemde kenmerken, niet vergeten worden. Op beide momenten, voorafgaand (DoR) en bij oplevering van een sprint (DoD) zijn de kenmerken belangrijke controlepunten.
Verloedert de softwarekwaliteit bij een Agile aanpak? Nee, op het juiste moment met de ISO-norm 25010 in de hand borgt ook de kwaliteit van software in een Agile werkvorm. Op de keeper beschouwd is Agile werken niks anders dan kleine watervalletjes achter elkaar waarbij functionele ontwerpjes worden gemaakt. Daarmee is de kwaliteit van het eindproduct geborgd. Dat brengt mij op de visie dat de traditionele architectuuraanpak of “design before build” nog zo gek niet is, maar daarover in een volgende blog meer.