Digital Customer Experience Blog

Digital Customer Experience Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

Sprint 0: het fundament van elk Agile project

Categorie: Digitale strategie

Het begin van het ontwikkel traject in een project, oftewel de zogeheten sprint 0 in SCRUM, is het uitgelezen moment om de eerste wensen voor het nieuw te realiseren systeem in kaart te brengen en te vertalen naar hoe dit technisch kan worden opgelost. Mensen met de SCRUM bril op zullen het voorgaande uiteraard direct vertalen naar het refinen van user stories op de backlog en ze zo 'ready' te krijgen, om deze tijdens de planningssessie voor sprint 1 goed in te kunnen schatten. Deze user stories, wat eigenlijk korte beschrijvingen van wensen van de eindgebruiker zijn, zullen door middel van functionaliteit ingevuld moeten worden. Al deze wensen bij elkaar worden ondergebracht in de backlog, oftewel een overzicht van al de user stories die nog op gepakt moeten gaan worden. Wat echter vaak niet direct wordt ondergebracht op de backlog zijn de zogeheten ‘non-functionals’, oftewel de fundamentele eisen aan elk systeem, daar dit vaak eisen zijn die aan de functionals kleven.

Functionals beschrijven, zoals de naam doet vermoeden, vooral de functionaliteit die het uiteindelijke systeem in zijn totaliteit moet gaan uitvoeren. Dit gaat vrijwel altijd volgens een vast stramien, namelijk input die wordt verwerkt tot een gewenste output. Een non-functional daarentegen beschrijft vooral criteria waaraan het systeem moet voldoen. Voorbeelden1 hiervan zijn eisen die gesteld worden aan de portabiliteit, onderhoudbaarheid, robuustheid, schaalbaarheid en beveiliging. Dit maakt non-functionals direct een set requirements die niet voor een stukje functionaliteit geldt, maar voor het hele systeem zal gelden. Om deze reden zullen de non-functionals gewaarborgd moet worden tijdens elk op te leveren user story. Voor een bepaald aantal fundamentele non-functionals, bijvoorbeeld performance, robuustheid en beveiliging, spreekt het voor zich dat ze voor het hele systeem zullen gelden, gezien zij zich op het gebied van systeem architectuur afspelen.

Het is geen toeval dat de termen architectuur en fundament hier in één adem genoemd worden. Bouwvakkers kunnen zonder fundering gerust een huis opleveren, maar dan zakt het geheel uiteindelijk alsnog in elkaar. Dit is waarom, mijn inziens, sprint 0 een dergelijk cruciale positie binnen het SCRUM proces bekleedt. Deze sprint is het aangewezen moment om het fundament te leggen voor het te bouwen systeem. Mocht dat niet lukken, dan zullen er vroeg of laat ook ‘verzakkingen’ optreden in de toekomstige user stories. Hierdoor zullen ze minder toegevoegde waarde leveren dan oorspronkelijk is bedoeld. Binnen de kaders van het in sprint 0 op te leveren raamwerk zullen de user stories uit de toekomstige sprints dus op een efficiëntere manier hun toegevoegde waarde aan het systeem moeten gaan leveren. Dit daar de toekomstige user stories direct bij de oplevering van een user story aan de non-functionals zullen gaan voldoen, en dus passen op het fundament van het systeem. Zo kan er bijvoorbeeld voor een non-functional die iets zegt over de code kwaliteit in sprint 0 al automatische tooling geïnstalleerd worden. Hiermee kan de kwaliteit over het gehele project gewaarborgd worden.

Mocht een non-functional pas later in het traject ten tonele verschijnen dan kan dit een hoop extra moeite kosten om dit nog op te vangen. Bijvoorbeeld het voorgaande scenario waarbij er controle op de code kwaliteit moet worden uitgevoerd. Mocht deze tooling tijdens een ‘echte’ sprint geïnstalleerd moeten worden, dan zal dit ten kosten gaan van de ontwikkeling aan andere user stories. Tevens zal de kwaliteit van de eerder opgeleverde user stories ook moeten voldoen aan deze eisen, wat op zijn beurt weer rework kan gaan opleveren. Een ander simpel voorbeeld is ondersteuning voor een verouderde browser. Idealiter pak je per user story dit stukje optimalisatie mee. Als dit later blijkt, betekent dit dat het stukje voorbereiding hiervoor (bijvoorbeeld het opzetten van een geschikte test omgeving of het inrichten van je project op het optimaliseren voor deze browser) nog gedaan moet worden. Dit met als resultaat dat de optimalisatie slag voor al de eerder opgeleverde user stories in zijn geheel moet worden ingehaald. Dit is een pure portabiliteitskwestie, waar je als het ware nog iets ‘nieuws’ oplevert in de vorm van ondersteuning voor een browser waar het systeem eerst niet werkte. Er zijn echter andere vormen die minder tot zelfs geen nieuwe waarde voor de klant leveren, bijvoorbeeld het waarborgen van de code kwaliteit zoals hij eerder genoemd is. Een ander voorbeeld is een beveiligingseis die niet gehaald wordt. Dit zou kunnen betekenen dat een groot deel van de code moet worden herzien zonder ook maar enige nieuwe functionaliteit voor het systeem te bieden. In het ergste geval kan dit als gevolg hebben dat het gehele ontwikkelteam alle oude opgeleverde user stories moet herzien, waarvoor weer de nodige inspanning is vereist.
 

Een te lange sprint 0, waarin teveel wordt gerefined, bootst nog steeds de waterval methode na.

Deze non-functionals zullen derhalve in een vroeg stadium van het project al duidelijk moeten zijn, om de nodige voorbereidingen te kunnen treffen en zodergelijk rework te voorkomen. Maar is dit niet in strijd met de hele filosofie achter Agile projectmanagement? Vooraf alle non-functionals beschreven hebben is een ouderwetse stap uit een waterval proces (zie bovenstaande illustratie). De weg die bewandeld dient te worden ligt ergens in het midden. Met gezond vooruitstrevend inzicht van zowel de product owner als een solution designer zal een heleboel vooraf al kunnen worden opgevangen. Verder zou een developer ook de stakeholders moeten uitdagen om ze verder te laten denken over het fundament van het systeem. Niet alles is op te vangen, elk systeem wat een langere tijd blijft draaien krijgt op een gegeven moment additionele eisen waar het aan moet gaan voldoen. Het is dan ook logisch en niet uit te sluiten dat rework en refactoring op een bepaald moment plaats zal gaan vinden. Dit gaat bovendien hand in hand met emergent design2, een concept wat omarmt dient te worden binnen Agile projecten. Simpel gezegd houdt emergent design in dat het ontwerp van een systeem zichzelf ontvouwt. Dit kan betekenen dat bepaalde functionaliteit overlapt en daardoor dubbel wordt ontworpen, tijdens de ontwikkeling wordt dit dan glad gestreken, waarvoor wat rework en refactoring nodig zal zijn.

Kort gezegd zal bij het opzetten van de fundering in sprint 0 door het ontwikkelteam in acht moeten worden genomen dat alles flexibel moet worden opgezet en dat er ruimte is in de architectuur voor veranderingen. Hierbij is het belangrijk dat op dit moment de dingen die veel invloed hebben op het systeem alvast in de agenda worden gezet, zodat dit vroeg in het project kan worden getackeld. Deze fase moet echter niet te lang worden doorgezet. De crux zit hem namelijk in het vinden van balans tussen het vooraf definiëren van het systeem en het starten zonder enige vorm van houvast. Een grote valkuil bij het blijven definiëren van eisen is dat er een te lange sprint 0 zal zijn waar in alle beslissingen gemaakt worden en we dus terugvallen op de waterval methode. Door niets te definiëren zijn we wel Agile, maar dit komt niet ten goede van de kwaliteit van de op te leveren backlog items in de verschillende sprints.

Een best practice voor dit conflict is er helaas niet, daar er teveel factoren zijn die hier in mee spelen. Ondanks dat de efficiëntie van het ontwikkelteam, in mijn ogen, voor een groot deel afhankelijk is van de balans die in deze fase word gevonden, kan de volgende vuistregel wel worden gehonoreerd: ‘Sprint 0 moet niet te lang duren, maar anderzijds moet er ook aan de slag worden gegaan zonder fundering.’  - Maar ook dit is een van de facetten die het spel genaamd SCRUM zo interessant maakt.
 


1 Link naar Wikipedia artikel over non-functionals
2 Link naar Wikipedia artikel over emergent design

Over de auteur

Gabriël Moawad
Gabriël Moawad
Gabriël is een creatieve front-end developer met kennis van user experience design. Hij weet niet alleen de koppeling tussen design en back-end soepel te leggen, maar heeft ook oog voor de gebruiksvriendelijkheid van applicaties. Sinds de opkomst van het ‘mobile web’ kijkt Gabriël tegenwoordig verder dan alleen het ontwikkelen voor de traditionele desktop. Hij stort zich nu dan ook enthousiast in de uitdagingen die het mobiele platform met zich mee brengen.

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.