Bij stapsgewijze ontwikkelmethoden, zoals Scrum en Kanban, wordt de te ontwikkelen functionaliteit gedurende het project in user stories uitgeschreven. User stories zijn microverhalen die vertellen wat een gebruiker met een onderdeel van de software kan doen en wat het doel van die functionaliteit is. De user stories worden samen met de opdrachtgever op volgorde van prioriteit gesorteerd en vervolgens implementeert het development team telkens in een sprint van 1-2 weken een set user stories.

Door deze manier van samenwerken is er veel ruimte voor voortschrijdend inzicht en kunnen nieuwe ideeën snel worden meegenomen. Om te zorgen dat de kwaliteit tijdens het in kleine stappen ontwikkelen van de software gewaarborgd blijft, is het verstandig om met een definition of done te werken. Dat is een set van expliciete afspraken om te bepalen wanneer een user story echt helemaal klaar is en van de lijst gestreept kan worden. Vaak ziet de definition of done er uit als een checklist, met daarop elk van de concrete afspraken.

Of je nu werkt met een eigen development team, één of meerdere freelance developers of een digitaal bureau, het is goed om met elkaar na te denken over wanneer het werk écht af is. Dat klinkt vanzelfsprekend, maar in de praktijk blijkt vaak dat de developers, ontwerpers, testers en eventuele andere disciplines binnen een Scrum team allemaal een net iets andere definitie van ‘af’ hebben. Door met elkaar na te denken over de stappen die genomen moeten worden voor iets écht af is, voorkom je frustratie, scheve verwachtingen en een moeizame samenwerking met je eigen team of het digitale bureau.

Om je een idee te geven van hoe een definition of done er kan uitzien, lopen we die van Inspire met je door. Binnen Inspire houden we over het algemeen onderstaande definition of done als basis aan. Bij elk nieuwe project passen we de definitie aan op de afspraken met de opdrachtgever en de karakteristieken van het project.

We spreken ieder punt uit de definition of done graag met je door.

De functionaliteit voldoet aan dat wat er in de user story is afgesproken
De opgeleverde functionaliteit moet voldoen aan dat wat in de user story staat. Daarnaast is het belangrijk dat de functionaliteit handmatig getest is. De kwaliteit van de code kan nog zo goed zijn, het bewijs is er pas echt als de functionaliteit daadwerkelijk in de browser of op de mobiele telefoon wordt getest. De functionaliteit moet precies zo werken als de bedoeling is. Als er in de user story specifieke acceptatiecriteria staan, dan moet de functionaliteit daaraan voldoen.

De user interface is ‘conform ontwerp’ opgeleverd
Meestal wordt er voor elk onderdeel van de website of app een gedetailleerd interactieontwerp en een visueel ontwerp gemaakt. Als een nieuwe functionaliteit door het team wordt opgeleverd, dan moet de user interface er ‘conform ontwerp’ uitzien. Het is daarbij belangrijk dat de user interface er op alle afgesproken schermresoluties (bijvoorbeeld desktop, tablet en mobiel) goed uitziet.

De code voldoet aan de technische kwaliteitseisen
Binnen Inspire hanteren we een uitgebreide set richtlijnen waarin precies staat welke eisen er aan de kwaliteit van de code worden gesteld. De door developers geschreven broncode moet aan deze eisen voldoen voordat een user story echt af is. Over het algemeen geldt voor code die is geschreven volgens consistente kwaliteitseisen dat er minder fouten in zitten en dat de onderhoudbaarheid hoger is. Code Climate is een tool die we gebruiken om de kwaliteit van de broncode te controleren. De tool controleert nieuwe en gewijzigde broncode op verschillende factoren, waaronder de mate van complexiteit, stijl, veiligheid en betrouwbaarheid.

De broncode is voorzien van softwarematige tests
Bij Inspire maken we gebruik van test-driven development. Bij deze vorm van software ontwikkelen schrijft een developer eerst geautomatiseerde softwaretests voordat zij de eigenlijke code voor het realiseren van de functionaliteit ontwikkelt. De tests worden vervolgens automatisch op de software uitgevoerd zodra een developer een wijziging aan de broncode opslaat. Als één of meerdere tests na het opslaan van de wijziging in de code niet meer slagen, dan krijgt de developer daar direct een seintje van. Deze manier van ontwikkelen zorgt ervoor dat eventuele fouten al in de ontwikkelfase worden ontdekt en niet pas in de live-omgeving naar boven komen.

Peer reviews: de code is door een andere developer gecontroleerd
Bij Inspire wordt elke geschreven regel code door minimaal één andere developer nagekeken. Deze manier van werken wordt ‘peer review’ genoemd en zorgt ervoor dat de kwaliteit van de broncode wordt gecontroleerd en waar nodig wordt verbeterd. Het verschil met het analyseren van de broncode met behulp van Code Climate is dat de developer bij de handmatige peer review vooral kijkt of de code logisch, prettig leesbaar en goed onderhoudbaar is. Dat is grotendeels een menselijke beoordeling. Code Climate kan immers niet bepalen of een developer de juiste technische aanpak heeft gekozen.

De documentatie van de software is bijgewerkt
Bij Inspire proberen we broncode zoveel mogelijk zelfbeschrijvend te laten zijn. Hoe minder documentatie er nodig is, hoe beter. Maar dat betekent niet dat er helemaal geen documentatie is. Zo beschrijven we API’s (technische koppelingen) altijd in gedetailleerde API documentatie. En als er bij het uitrollen van de nieuwe of gewijzigde functionaliteit bepaalde taken uitgevoerd moeten worden, dan noteren we dat in het “Todo’s for release” document.

De code staat in de ‘master branch’
Als de peer reviewer akkoord is met de kwaliteit van de nieuwe of gewijzigde broncode, wordt het in het versiebeheersysteem opgeslagen. Daarmee wordt het onderdeel van de broncode van het product. Hiermee kan de functionaliteit dus echt afgevinkt worden.