Een vernieuwde Livits-module in 11 stappen

STAP 1: KIES DE MODULE

Vragen, opmerkingen, suggesties en goedbedoelde kritiek, het komt allemaal terecht bij de productmanager. Onze webdevelopers en functioneel consultants spreken dagelijks met l;anten, dat is een manier waarop deze informatie binnenkomt. Daarnaast krijgen we natuurlijk ook via e-mail de nodige suggesties binnen. Alles slaan we op in een handige tool die Jira heet. De productmanager analyseert al deze input en toetst deze aan de bedrijfsstrategie. Ten slotte kiest hij, naar aanleiding van de analyse, de module uit die opnieuw gaat worden gemaakt of wordt verbeterd.

STAP 2: INTERVIEWS MET KLANTEN

Geen half werk. Het lijkt dubbelop omdat de productmanager een module uitkoos op basis van voornamelijk suggesties van klanten. Toch is deze stap bijzonder waardevol. De aandacht spitsen we hiermee namelijk op een specifieke module. Daarover spreken we met onze klanten. Hierbij laten we bijvoorbeeld de uitkomst van de analyse zien en de nodige suggesties die we al ontvingen als discussiepunten. Al hebben de meeste van onze klanten al vrij snel een lijstje met wensen klaar. Die verzamelen we bij verschillende klanten.

STAP 3: ORDE IN DE CHAOS

Nou ja, chaos. Na alle input uit Jira en de daaropvolgende interviews hebben we een uitgebreide lijst met wensen en suggesties. Maar met welk stukje functionaliteit moet je dan beginnen? Ook hier mogen we gelukkig terugvallen op onze klanten. Alle verzamelde punten komen op een lijst die we aan geselecteerde klanten toesturen. Dit heeft twee redenen. In de eerste plaats mogen de klanten op deze lijst aangeven in welke volgorde ze de gevraagde functionaliteit willen laten bouwen. Daarnaast is het ook een compleet overzicht; zo hebben de klanten ook inzicht in de wensen van andere klanten. Dat levert soms nog leuke, extra suggesties op.

STAP 4: BEESTJES

Tja, we zouden geen software hebben als we niet soms een bug gerapporteerd krijgen. Of moeten we ze ongedocumenteerde features noemen? Helaas, het overkomt ons ook wel eens. Meldingen van bugs komen ook in Jira te staan. Dat kan via klanten, via een van onze technische afdelingen of via de supportafdeling gebeuren. Het is maar net waar het binnenkomt. Het kan overigens heel goed gebeuren dat het alleen maar gaat om een verbetering van de gebruikersvriendelijkheid van de interface. Niet ernstig, wel fijn als er wat mee wordt gedaan. Ook de bugs krijgen een eigen set prioriteiten. Deze komen meestal voort uit een bespreking met de functioneel consultants.

STAP 5: HET DIEPE IN

Van een lijstje alleen kunnen we nog geen software maken. In deze stap gaan we kennis delen en brainstormen hoe we een bepaalde functionaliteit tot stand kunnen brengen. Wat zijn de afhankelijkheden? Waar kunnen we zaken combineren? Zo krijgen we meer inzicht in de taken die ons te wachten staan. We hebben nu een globaal beeld hoe de verschillende gevraagde functionaliteiten samenhangen.

STAP 6: TEKENEN

Bij Livits ontwikkelen we met de ‘Scrum’-methodiek. Binnen ons scrumteam maken we schetsen en tekeningen van de ideeën. Het zijn feitelijk tekeningen van de interface van de module die we straks gaan bouwen. Door de verschillende expertises in het scrumteam weten we zeker hoe al deze functionaliteit samenhangt en wie straks het voortouw moet nemen. Ons scrumteam bestaat typisch uit vier (groepen) deelnemers:

• Backend developer(s): ze verzorgen de dataverwerking. Alles wat niet zichtbaar is, zeg maar. Interactie met de database en gruwelijk moeilijke server dingen.
• Frontend developer(s): alles wat je op je scherm kunt zien noemen we de frontend. Deze developer(s) verzorgen dus alle grafische elementen waarmee je de interface bedient.
• Scrummaster: een typische rol in het scrumteam. In old-school ontwikkeling zou je deze meneer of mevrouw de projectleider noemen. De scrummaster zorgt ervoor dat het team zijn werk kan doen en de targets kan halen.
• Product owner: deze rol noemen we ook wel productmanager. De product owner is verantwoordelijk voor de lijst van zaken die moeten worden gebouwd, in scrum jargon noemen we die lijst de backlog. Hij of zij bepaalt ook de uiteindelijke volgorde en prioriteiten.

Het werken met een scrumteam heeft het voordeel dat alle disciplines bij elkaar zitten. Hierdoor kunnen ze nauw met elkaar samenwerken. Zo ontstaat er een product waarin alles goed op elkaar aansluit.

STAP 7: TAKEN DEFINIËREN

Of eigenlijk moeten we nu in scrumtermen blijven: de backlog samenstellen. Voor de eerste keer. Wie goed heeft opgelet weet ook wie hiervoor verantwoordelijk is binnen het team. De schetsen uit stap zes worden erbij gepakt en omgezet in taken. Per taak schatten we de complexiteit en de benodigde tijd in. De optelsom hiervan vormt de backlog voor de komende sprints.

STAP 8: VERFIJNEN EN PLANNEN

In de backlog worden nu de uiteindelijke prioriteiten vastgesteld. Aan de hand van de inschattingen qua tijd worden nu de eerste sprints gevuld. Een sprint is een periode van twee weken waarin we ontwikkelen. Het mooie van een sprint is dat er aan het einde van die twee weken iets klaar is. Daarmee kunnen we dan intern iets laten zien en weer feedback op ontvangen. Het vullen van de sprintperiode met taken noemen we ‘refinement’.

STAP 9: BOUWEN

Eindelijk is het dan zo ver. We starten daadwerkelijk met bouwen. Het lijkt alsof we hiermee heel lang hebben gewacht, maar in de praktijk valt dat best mee. Afhankelijk van de beschikbaarheid van alle leden van het scrumteam gaan er maar een paar dagen over stap vier tot en met acht. Juist door de goede voorbereiding is stap negen in een zo kort mogelijk tijdsbestek klaar. Waarbij het eindresultaat ook nog eens goed aansluit bij de verwachtingen van onze klanten.

Nog even wat uitleg over scrum. Iedere dag is er een zogenaamde stand-up. Dan vertellen we elkaar geen grapjes, maar bespreken we de voortgang van die dag en eventuele moeilijkheden die we tegenkwamen. De voortgang houden we bij op een scrumbord (of moeten we scrumboard zeggen?). Zo zien we precies hoe ver iedereen is. Daardoor is het ook mogelijk om bijvoorbeeld collega’s die al klaar zijn op te schakelen bij iemand anders. Iedere laatste donderdag van een sprint worden er testscripts doorlopen. De laatste vrijdag volgt een review en demonstratie aan de product owner. De sprint wordt vervolgens geëvalueerd in een retrospective. Daar halen we leerpunten en best practises uit.

STAP 10: PILOT

Hoera! Het is klaar. Tijd om een test uit te voeren in een ‘echte’ omgeving. Bij een of twee klanten dus. Ook hier hebben we eigenlijk altijd het geluk dat er veel klanten zijn die hieraan mee willen werken. De nieuwe module installeren we op een veilig deel van het systeem van de klant en die gaat de module gebruiken. Testen. Hieruit volgt feedback die we vervolgens opnemen in de laatste sprint van het project. Om de laatste puntjes op de i te zetten, zeg maar.

STAP 11: UITROLLEN

Als alle stappen zijn genomen, dan is de module klaar voor gebruik. De distributie van de nieuwe module doen we via een micro release. Dit betekent dat we de nieuwe module automatisch uploaden naar het systeem van de klant. Daarbij blijft de oude module overigens gewoon in tact. De nieuwe module is er, maar staat nog niet aan. Soms is het nodig om klantspecifieke aanpassingen te doen of eerst wat training te geven. Pas als dat is gedaan, wisselen we naar de nieuwe module.

TOT SLOT

Het kan best voorkomen dat het lijkt alsof er met feedback niets wordt gedaan. Met de nadruk op lijkt. Elke vorm van feedback die we van klanten ontvangen is voor ons belangrijk en doen we wat mee. We gaan daar alleen niet lichtzinnig mee om. Met dit ‘kijkje in de keuken’ hebben we hopelijk laten zien dat een module aanpassen niet een avondje werk is. Daar komt veel bij kijken. Onze ontwikkelteams zijn fulltime op deze manier voor onze klanten aan het werk.