Scrum geeft inzicht in de voortgang en risico’s van een softwareproject. Maar de Scrum-aanpak kan worden versterkt. In acht punten bespreekt M&I/Partners de mogelijkheden. Iedere vorm van afstand bemoeilijkt de samenwerking.
Het realiseren van goede softwarekwaliteit is niet eenvoudig. De vele mislukte software-ontwikkelprojecten zijn daarvan het bewijs. In dit artikel echter geen horrorverhalen, maar praktische handreikingen. We gaan uit van een agile software-ontwikkelaanpak, in dit geval Scrum. Bij Scrum wordt de software ontwikkeld in ‘sprints’ van een vaste lengte, meestal twee of drie weken.
De opdrachtgever, in Scrum ‘product owner’ genoemd, bepaalt waar het team elke sprint aan werkt. Hij selecteert kleine stukjes werk (‘user-stories’) die op een ‘product-backlog’ staan en wijst die aan de sprints toe. Het team werkt deze uit gedurende de sprint, maakt geautomatiseerde tests en houdt de dagelijkse ‘stand-up meeting’. Aan het eind van elke sprint is er een nieuwe versie van de software die klaar is voor gebruik.
Het gebruik van Scrum zorgt ervoor dat er eerder dan bij een traditionele aanpak zicht is op de voortgang, dat risico’s eerder inzichtelijk worden en dat de opdrachtgever eerder kan beschikken over werkende software. Onderstaande handreikingen kunnen de Scrum-aanpak verder versterken. Deze handreikingen zijn ontstaan bij de ICTU. Deze uitvoeringsorganisatie ontwikkelt elektronische dienstverlening voor de overheid. Zij gebruikt sinds 2010 Scrum voor grootschalige softwareontwikkel- en onderhoudsprojecten.
Het is moeilijk het belang van fysieke nabijheid te onderschatten. Mensen werken beter samen als ze elkaar kunnen zien en ontmoeten. Iedere vorm van afstand bemoeilijkt samenwerking. Zeker binnen de overheid zijn er vaak veel verschillende organisaties betrokken bij een softwareproject die bovendien op verschillende locaties zijn gehuisvest. Denk aan ministerie(s), uitvoeringsorganisatie(s), gemeenten en organisaties die verantwoordelijk zijn voor het functioneel beheer en het applicatiebeheer. Door betrokkenen zo veel mogelijk letterlijk bij elkaar te brengen, wordt de samenwerking effectiever en efficiënter. Dat geldt voor de teamleden van een Scrumteam, maar ook voor de overige betrokkenen.
Scrumteams bestaan naast de product-owner en Scrummaster over het algemeen uit ontwerpers, ontwikkelaars en testers. Alle benodigde expertise is zoveel mogelijk in het team aanwezig. Vaak is er daarnaast echter specifieke expertise nodig, maar niet op fulltime basis. Denk aan DBA-support, technisch beheer van ontwikkelomgevingen, kwaliteitsmanagement en releasemanagement. Als deze expertise in meerdere projecten nodig is, kan deze worden gebundeld in een supportteam. Dit supportteam werkt voor meerdere Scrumteams, zodat alle Scrumteams over ondersteuning en expertise beschikken die ze zelf niet fulltime nodig hebben. Op die manier is ook meteen de 'achtervang' goed geregeld.
Uiteraard bevindt het supportteam zich fysiek zo dicht mogelijk bij de Scrumteams die het ondersteunt, zodat de communicatie zo direct mogelijk verloopt. Bij ICTU bijvoorbeeld ondersteunt het supportteam zes tot zeven Scrumteams.
Het starten van een nieuw ontwikkeltraject is intensief. Medewerkers moeten aan elkaar wennen. Ontwikkelomgevingen moeten worden ingericht. Mensen moeten vertrouwd raken met het proces. Als u het nieuwe team in dezelfde ruimte laat beginnen als het supportteam, bevordert u een vliegende start van het project. Het supportteam is direct beschikbaar voor de beantwoording van vragen en kan bovendien uit eigen beweging advies geven als er problemen zijn. Dit voorkomt dat het nieuwe team zelf problemen oplost die al eerder zijn opgelost. Het zorgt er ook voor dat het nieuwe team zich het standaardproces en het gebruik van tools veel sneller eigen maakt. Een ‘kraamkamer’ voor nieuwe projecten dus. Als het nieuwe team op stoom is, kan het verhuizen naar een ruimte die iets verder van het supportteam is gelegen. Zo maakt het plaats voor het volgende startende project.
Om iedere twee à drie weken een nieuwe versie van de software te kunnen uitbrengen, is het essentieel dat testen voor het overgrote deel geautomatiseerd zijn. Een geautomatiseerde regressie-testset die in een uurtje alle functionaliteit test, maakt het mogelijk de software met vertrouwen uit te brengen. Dat betekent echter dat er grofweg net zoveel testcode zal zijn als productiecode. Of die testcode geschreven is in de vorm van Java of executeerbare scripts, maakt niet eens zoveel uit. De testcode moet net als de productiecode ook goed te wijzigen zijn. Een probleem daarbij ontstaat als tests te veel testen. Dat gaat misschien tegen uw gezond verstand in: hoe meer functionaliteit een test controleert, hoe beter toch? Maar in de praktijk blijkt dat niet zo te zijn. Het symptoom is dat bij een schijnbaar eenvoudige wijziging in de software tweehonderd testgevallen falen en allemaal moeten worden aangepast. Dit kan gebeuren als bijvoorbeeld het formaat van een bericht verandert doordat er een veld bijkomt. Als testgevallen naar het hele bericht kijken om te beoordelen of de test slaagt, zullen ze in dit geval dus falen. Zelfs als ze eigenlijk helemaal niets met dat extra veld doen. Het is dus belangrijk dat testgevallen slechts een ding testen en zo ongevoelig mogelijk zijn voor andere wijzigingen.
Overigens, als dit probleem zich voordoet weersta dan de verleiding om de geautomatiseerde regressietest direct aan te passen. Tijdens het aanpassen werkt de regressietest niet en kunnen er geen andere wijzigingen worden getest. Beter is om te noteren welke testgevallen onterecht omvallen, de wijziging terug te draaien en eerst de tests ongevoelig voor de wijziging te maken die daar ongevoelig voor zouden moeten zijn. Ondertussen kan het team verder gaan met andere wijzigingen.
Kost het maken, testen, documenteren van een release te veel tijd? Is het team twee dagen per sprint van drie weken bezig de release samen te stellen? Doe het dan vaker! Wij horen u denken: 'Vaker de release maken zorgt er toch juist voor dat de overhead toeneemt? Twee dagen per drie weken is beter dan twee dagen per twee weken, toch?' Dat klopt. Maar de praktijk is toch anders. Door dingen vaker te doen, kost het per keer minder tijd: de mensen worden er beter in, er worden minder fouten gemaakt en fouten die toch optreden, zijn makkelijker te herstellen. Bovendien loont het om te automatiseren en veel tijd te winnen. Een manier om dingen vaker te doen, is bijvoorbeeld de sprintlengte verkorten. Een andere manier die goed werkt, is om taken niet eenmaal per sprint te doen, maar bij elke user-story. Denk aan het bijwerken van release-notes: dat kan een keer per release, maar is dan veel werk. Het kan ook als taak bij iedere user-story. Of nog beter, het kan ook door de release-notes automatisch te genereren uit de sprint-backlog.
Ieder zichzelf respecterend ontwikkelteam heeft SonarQube ingericht voor het bewaken van de complexiteit van de broncode en andere kwaliteitsaspecten. Echter, zonder een duidelijke norm en signalering van overschrijding ervan is het lastig voldoende aandacht aan die metingen te geven. Door dergelijke metingen te relateren aan een expliciete norm, wordt het duidelijk wanneer de kwaliteit goed genoeg is. Het voldoen aan die norm is uiteraard onderdeel van de definition of done. Heeft een organisatie eenmaal een aantal van deze normen afgesproken? Dan is het de moeite waard deze geautomatiseerd te meten en beschikbaar te stellen aan de teams, in de vorm van een stoplichtenrapportage. Is er eenmaal een systeem om metingen uit verschillende systemen samen te vatten in zo'n stoplichtenrapportage, dan wordt het makkelijk om elke keer als er iets fout gaat een stoplicht toe te voegen. Zo verandert een eenvoudige stoplichtenrapportage in een hulpmiddel voor procesverbetering.
Op het moment dat een team zowel de userstories als de logische testgevallen heeft vastgelegd in een tool, bijvoorbeeld Jira, en het heeft een geautomatiseerde testset, dan ontstaat er een interessante mogelijkheid. De fysieke testgevallen in de geautomatiseerde testset kunnen gelinkt worden aan de logische testgevallen in Jira, bijvoorbeeld door bij elk fysiek testgeval het Jira-nummer van het bijbehorende logische testgeval op te nemen. De logische testgevallen kunnen weer worden gelinkt met de user-stories die zij testen. Zo ontstaat de mogelijkheid geautomatiseerd een rapportage te generen bij het draaien van de testgevallen die precies laat zien welke testgevallen slagen of falen en welke user-stories dus gerealiseerd zijn en welke nog niet.
Technische schuld is een metafoor voor werk dat aan de software moet worden gedaan voordat de software echt klaar is of voordat er makkelijk nieuwe wijzigingen kunnen worden gemaakt. In een ideale wereld komt technische schuld niet voor, want aan het eind van elke sprint is de software helemaal af. In de praktijk zijn er helaas allerlei redenen waarom technische schuld toch optreedt. Heeft een ontwikkelteam een stoplichtenrapportage met expliciete normen, dan is het makkelijk technische schuld te identificeren: elk rood stoplicht dat niet binnen een sprint kan worden veranderd in een groen stoplicht is dan technische schuld. Die technische schuld aflossen is een kwestie van afspraken maken met de productowner over welk deel van de sprint kan worden gebruikt om welke technische schuld af te lossen. Zo blijft de winkel tijdens de verbouwing open. En met behulp van de stoplichtenrapportage kan het team de voortgang van de aflossing bewaken.
De afgelopen weken is er veel aandacht besteed aan de begrotingstekorten waar gemeenten mogelijk mee te maken krijgen na 2026, ook wel bekend als het 'ravijnjaar'.
Lees verderGemeenten moeten steeds meer wet- en regelgeving met een digitaal component implementeren, waarbij kennis van primaire processen cruciaal is voor succesvolle integratie. Is jouw gemeente al klaar voor de digital decade?
Lees verder
