Een standaard Scrum-backlog biedt in een groot, complex ontwikkelproject onvoldoende overzicht. In dit artikel beschrijven Roger Jacobs van Mutracx en Jan-Mathijs Wijnands van Sioux hoe in een complex machinebouwproject de User Story Mapping-techniek is toegepast om een tweedimensionale storymap te creëren die een beter overzicht geeft om tot zinvolle releases te komen.
Het Lunaris-project maakt ‘s werelds eerste industriële ets-resistprinter, die met inkjettechnologie rechtstreeks ets-resistpatronen kan spuiten op binnenlagen van PCB‘s. Het project is een samenwerking van Océ-spin-off Mutracx en een aantal partnerbedrijven, die elk hun eigen expertise inbrengen. Sioux is hierbij verantwoordelijk voor het bouwen van de software. Dat doen we met een team van tien tot twaalf personen en Scrum als ontwikkelmethodiek.
Scrum is erg eenvoudig in zijn opzet. Dat is zeker ook een kracht: door de eenvoud is het gemakkelijk om mee te starten. Het is wel erg geënt op kleinere teams en kleinere projecten. Bij Sioux hebben we al jaren ervaring met Scrum in kleinere projecten (tot maximaal acht personen), waarbij we meestal alleen software ontwikkelen.
Lunaris is duidelijk van een andere categorie: in drie jaar tijd hebben we in een multidisciplinair projectteam een complexe printer van de grond af aan opgebouwd, met onder meer nauwkeurige motion control, realtime besturing, beeldverwerking, geavanceerde algoritmes en remote control. De software voor de processing en de besturing is gedistribueerd over acht pc‘s. Om een idee te geven van de grootte: alleen al in de softwareontwikkeling van de alfamachine zit ongeveer dertig manjaar effort.
Eendimensionaal
De complexiteit en daaruit volgende omvang maakten duidelijk dat enkele basisbeginselen van Scrum niet meer toereikend zijn. Een van de zaken waar we tegen aanliepen, was dat een complete backlog voor een dergelijk project zo groot wordt dat je door de bomen het bos niet meer ziet. Je praat al gauw over honderden story‘s.
De Scrum-methodiek heeft maar één mechanisme om de grootte van de backlog te beperken: het gebruik van zogeheten epics of themes. In feite zijn dat verzamelingen gerelateerde story‘s die te groot zijn om in een sprint te passen maar als totale set op de backlog worden gezet. Pas als de epic bijna aan de beurt is om te worden geïmplementeerd, wordt hij opgedeeld in kleinere brokstukken, de story‘s.
Dit clusteren heeft als grote nadeel dat de afzonderlijke story‘s binnen een epic vaak totaal verschillende prioriteiten hebben. Zo moet elke complexe machine kunnen opstarten. Onder het thema ’opstarten‘ kun je echter de volgende story‘s of features bedenken: handmatig opstarten, volautomatisch opstarten na een power-up, een zelftest uitvoeren, ontwaken uit een energiebesparende modus, firmware automatisch downloaden, enzovoorts.
Voor elk thema geldt dat je een absoluut minimum kunt bedenken voor de benodigde functionaliteit en die telkens verder kunt verfraaien, totdat je uit economisch oogpunt beter kunt stoppen. In het begin moet je altijd een zekere basis bouwen voordat je iets werkends op kunt leveren. Dan is er een aantal features die veel toegevoegde waarde hebben. Vervolgens neemt het nut echter langzamerhand af.
Bovendien moet je voor een release een consistent geheel hebben. Er is altijd een basisset van functionaliteit die je product moet bezitten om zinvol te zijn. Een eendimensionale backlog geeft dan onvoldoende inzicht om makkelijk te kunnen bepalen welke features nodig zijn voor een zinvolle release.
Tweedimensionaal
Om deze tekortkomingen het hoofd te bieden, hebben we in het Lunaris-project een tweedimensionale versie van de backlog gemaakt. Daarin is eenvoudiger af te lezen hoe een release de essentiële basisfunctionaliteit afdekt. De techniek die we hebben toegepast, is gebaseerd op de concepten van User Story Mapping, maar specifiek aangepast op context.
De eerste stap is een raamwerk opzetten met elementaire gebieden die allemaal moeten worden afgedekt om tot een zinvolle machine te komen. We hebben gekozen voor de volgende gebieden: start-up/shutdown, print job preparation, printing, calibrations en error handling. De preparatie bestaat uit een voorbewerking van het patroon, nodig om tot een kwalitatief goede print te komen. Daarnaast moeten we de koppen schoonvegen. Het printen, de kernfunctie van de machine, omvat zowel het transport van de te bewerken panelen als het jetten zelf.
In de tweede stap verdelen we alle geïdentificeerde story‘s en features over deze aandachtsgebieden. Je zou kunnen zeggen dat we voor elk gebied een eigen backlog creëren. Figuur 1 laat een sterk vereenvoudigde weergave zien.
Stap drie is het samenstellen van de verschillende releases. Figuur 2 geeft er drie weer op de horizontale as, gescheiden door stippellijnen. Elke release bevat functionaliteit in de thema‘s die samen een doelstelling realiseren. Om een eerste ’crappy‘ print te kunnen maken, moeten we het systeem met de hand kunnen starten en met zes koppen (een subset van de uiteindelijke zestig heads) kunnen printen. Het systeem hoeft nog niet gekalibreerd te zijn en de preprocessing gebeurt nog offline. Om de printkoppen te beschermen, moet er wel rudimentaire errorafhandeling zijn.
Door expliciet de gebieden te onderkennen, wordt het een stuk eenvoudiger om te zien of je iets vergeten bent en of er sprake is van een coherente release. Je kunt veel gemakkelijker features terugvinden in een map die op thema‘s is geordend dan in een ellenlange eendimensionale lijst. En dat vereenvoudigt de interactie tussen de verschillende disciplines en stakeholders die nodig is om tot een optimaal plan te komen.