Wat is de rol van de informatieanalist bij agile ontwikkelen? Hij heeft een groot aandeel in het succes van het ontwikkelingstraject, concluderen Stefan de Lange en Roy Wasse. Zij laten zien wat zijn vaardigheden zijn en hoe die kunnen worden toegepast, met als gevolg: simpele en snelle verbindingen tussen business en IT.

De informatieanalist voorziet in een brug tussen business en IT. In traditionele systeemontwikkelingstrajecten heeft de analist altijd een vaste positie ingenomen. Nu heeft agile ontwikkeling zich de afgelopen jaren gemanifesteerd als de standaardbenadering voor het ontwikkelen van software. De voorspelbaarheid van trajecten is er door verbeterd en de resultaten sluiten beter aan bij de verwachtingen. De aanpak is inmiddels bekend: het ontwikkelen en testen vindt plaats in het Scrum-team, de Scrum-master bewaakt het proces en de product owner bepaalt de koers. Maar wat is dan nog de rol van de informatieanalist?

Bij de realisatie van een informatiesysteem zijn veel verschillende mensen betrokken. In de beginjaren van systeemontwikkeling waren dat alleen programmeurs. Maar met het toenemen van de omvang en de complexiteit van softwaresystemen ontstond al snel een noodzaak voor diverse vaardigheden. Programmeurs zijn niet gespecialiseerd in het achterhalen van de behoeften van gebruikers en in het vastleggen van de functionele eigenschappen. Bij een groot systeemontwikkelingstraject zijn technische, organisatorische, analytische, sociale en ethische vaardigheden nodig en de persoon die over al deze vaardigheden moet beschikken is de informatieanalist. De analist heeft dan ook een groot aandeel in het succes van het systeemontwikkelingstraject; dat had hij vroeger en dat heeft hij, in de huidige agile-projecten nog steeds. De informatieanalist is dus nog steeds nodig. Maar hoe past hij in het Scrum-team?

Taken

Om die vraag te beantwoorden moeten we eerst wat verder inzoomen op de werkzaamheden van de analist. Een analist werkt nauw samen met toekomstige gebruikers, projectmanagers, product owners, ontwerpers, architecten en businessanalisten. De verschillende visies en ideeën van deze mensen worden door de analist bij elkaar gebracht en vormen gezamenlijk de specificaties van het te bouwen informatiesysteem. Deze specificaties bewaart de analist niet in zijn hoofd maar legt ze vast waardoor hij ze kan delen met alle betrokkenen. Dat vastleggen kan de analist doen door de specificaties uit te drukken in de juiste taal. Geen ellenlang proza in natuurlijke taal en ook geen exacte wiskundige notaties in algebra, maar heldere en eenvoudige grafische modellen. Deze modellen zijn nodig om de specificaties te kunnen valideren en om ze te kunnen overdragen aan de programmeurs. De vraag is echter hoe de analist het modelleren het beste kan uitvoeren in het ritme van de opeenvolgende sprints.

De analist moet er rekening mee houden dat de modellen een statische weergave van het inzicht zijn van dát moment. Als een analyse maanden van tevoren wordt uitgevoerd, is zij vaak al verouderd voordat zij door de programmeur is opgepakt. Dat komt omdat de omgeving waarin de huidige systeemontwikkelingstrajecten worden uitgevoerd, complex en veranderlijk zijn. De omgeving is complex door het al bestaande applicatielandschap dat gedurende decennia is gegroeid, en zij verandert snel door veranderingen in de markt en regelgeving. Het is daarom niet mogelijk om ervan uit te gaan dat het inzicht van de mensen waarmee de analist samenwerkt compleet en toekomstvast is. Dit geldt dan ook voor het model dat dit inzicht vertegenwoordigt en daar moet de analist rekening mee houden.
Dit kan de analist doen door zijn model mee te laten bewegen met de veranderende inzichten. Hij dient af te stappen van de traditionele informatieanalyse waarin het volledige informatiesysteem wordt uitgewerkt voordat er ook maar één regel code is geschreven. De analist moet zijn model op een agile manier laten groeien, dat wil zeggen door alleen de belangrijkste modellen op het juiste moment uit te werken. Het meest actuele inzicht van de betrokkenen wordt daarmee snel overgebracht naar de programmeurs. Zij kunnen dit inzicht meteen omzetten in werkende software zodat het inzicht ook meteen gevalideerd kan worden.

Sprint 0

De analist mee laten werken in de sprints is echter niet genoeg; een korte maar gedegen voorbereiding is ook belangrijk. Voordat een project in doelgerichte sprints naar een succesvolle afronding holt, is er een belangrijke rol voor de analist in de voorbereidingsfase. Deze fase, ook wel sprint 0 genoemd, is geen klassieke informatieanalyse die maanden in beslag neemt. De voorbereiding duurt maximaal vier werken en alleen de stories waarmee het Scrum-team in de eerste sprints mee aan de slag moet, worden verder uitgewerkt.
De informatieanalist heeft dus een heel belangrijke rol in een agile-traject. Hij werkt niet langer aan één grote, brede brug tussen business en IT, waarbij je heel lang moet wachten totdat je naar de overkant kan. Maar met zijn analyse zorgt hij ervoor dat er razendsnel, simpele en smalle verbindingen tussen de business en IT worden gelegd, waardoor snel de juiste software kan worden ontwikkeld.

Stappenplan analist

Voorafgaand aan een agile-traject wordt in een korte periode, bij voorkeur niet langer dan een paar weken, de eerste versie van de backlog opgesteld. De analist speelt hierin een centrale rol, waarbij hij een aantal stappen doorloopt.

Stap 1. Visie

Een project kan op verschillende manieren van start gaan. Het is van belang om te borgen dat de scope, het doel en de uitgangspunten voor het project duidelijk zijn en dat alle belanghebbenden een gezamenlijk beeld hebben. Deze aspecten komen terug in de visie. De visie wordt gezamenlijk opgesteld en het is de verantwoordelijkheid van de analist om dit te faciliteren. Deze visie helpt om gedurende het project keuzes te maken; er wordt bij onduidelijkheden tijdens het project op teruggevallen.

Stap 2. Actoren en functies

Tijdens het opstellen van de visie brengt de analist de actoren in kaart. De actoren kunnen rollen, organisaties of andere systemen zijn. De vraag die centraal staat is: ‘Wie zijn de beoogde gebruikers van het systeem?’ Nadat de actoren zijn onderkend, inventariseert de analist de interactie van deze actoren met het systeem. De analist werkt dit uit in een use-casemodel.

Stap 3. Processen en domein

In het use-casemodel zijn de interacties van de buitenwereld met het systeem uitgewerkt. De volgende stap is het uitwerken van het gedrag aan de binnenkant van het systeem. Hierbij is aandacht voor de processen en het domein
(de data) waarvoor de analist UML als modelleringstaal kan gebruiken. Het is belangrijk om hierbij in de beginfase niet te gedetailleerd te werk te gaan. Eenvoudige processen en functies hoeven wellicht helemaal niet verder uitgewerkt te worden.

Stap 4. Optionele designstappen

Als aanvulling op het domein- en procesmodel kan de analist besluiten om de schermen te visualiseren, bijvoorbeeld in de vorm van wireframes. Andere mogelijke deliverables zijn interfacebeschrijvingen van services, verder uitgewerkte use cases of een vocabulaire. Het is echter belangrijk om alleen datgene te doen wat op dat moment ook echt nodig is en ook niet meer dan dat. De artefacten moeten bijdragen aan die eerste versie van de backlog waarmee de ontwikkeling van start kan gaan.

Stap 5. Opstellen van de eerste ruwe backlog

Na de uitvoering van voorgaande stappen kan een eerste versie van de backlog worden opgesteld. De analist kan hiervoor gebruik maken van het volgende stappenplan:

1. Haal de user stories uit de gemaakte artefacten. Hierbij gelden de volgende vuistregels. Maak een aparte user story van: elke functie van een actor, van elke stap uit het activiteitendiagram en van elk wireframe.
2. Groepeer de user stories op een logische manier.
3. En let ook op het verwerken van non-functional requirements.

Het is in deze fase van groot belang dat de backlog overzichtelijk blijft. Een backlog met honderden stories is te groot. Beperk de omvang van de backlog en groepeer de user stories door bijvoorbeeld labels te gebruiken. In het algemeen geldt: hoe groter het project, des te minder gedetailleerd zullen de stories zijn. Het belangrijkste is: just in time, just enough; specificeer niet meer dan nodig om een eerste sprint goed uit te kunnen voeren.
De eerste versie van de backlog is nu gereed. Het is de bedoeling dat alle stappen worden uitgevoerd in een periode die niet langer is dan vier weken.