do's en dont's voor agile analistenAnalisten die in een agile omgeving werken, kortweg agile analist, kunnen een belangrijke rol in het scrum team vervullen. Ze helpen de product owner vaak met het helder maken van de user stories en requirements.

Vaak zie je dat agile analisten in het begin vaak maanden en soms jarenlang zoekende zijn naar een goede werkwijze.

Misschien voel jij ook aan dat het nog niet helemaal lekker loopt, maar weet je de vinger niet op de zere plek te leggen. Of misschien heb je al van alles geprobeerd om je werkwijze en de requirements te verbeteren, maar boek je daar nog onvoldoende resultaten mee.

Omdat dat nergens voor nodig is én ik je die zoektocht wil besparen, heb ik 25 cruciale do’s and don’ts gebundeld in het e-book ‘Vliegende start als agile analist’. En het mooie is dat je hem gratis kunt downloaden. Mijn doel is namelijk om het voor alle analisten mogelijk te maken hun vak goed uit te oefenen. Dan zorgen we er samen voor dat gebruikers de systemen krijgen waar ze blij van worden.

Hier is mijn e-book ‘Vliegende start als agile analist’ gratis te downloaden.

Als voorproefje volgen hieronder alvast 5 do’s and dont’s.

1. De rol van een agile analist

In agile is de rol van analist niet expliciet belegd. Binnen agile en vooral scrum worden bewust zo min mogelijk rolnamen gebruikt. Dat is om de samenwerking binnen het multidisciplinaire team te bevorderen. De unieke kennis en vaardigheden van ieder teamleden is belangrijk, niet het label of rolnaam die hij heeft gekregen.

  DO   Je toegevoegde waarde als analist laten zien

Gelukkig biedt de agile werkwijze ons volop gelegenheid om toegevoegde waarde te leveren. De typische vaardigheden van een analist, zoals luisteren, doorvragen, overzicht houden en prioriteren, zijn bij een agile werkwijze erg belangrijk en zouden eigenlijk alle agile teamleden moeten bezitten.

2. Product backlog met user stories

Bijna elk agile team maakt gebruik van een product backlog met daarin user stories. Uitgebreide kennis en vaardigheden om hier goed mee om te gaan, zijn voor een agile analist onontbeerlijk. Het is bijvoorbeeld goed om je te realiseren dat een user story een beperkte scope heeft, omdat je in sprints werkt. Een gevolg daarvan is:

  DON’T   De user stories als systeemdocumentatie gebruiken

Een user story omvat namelijk alleen een gewenste wijziging op de, op dat moment, reeds gerealiseerde software. Een user story weerspiegelt daarom niet de eisen die aan de uiteindelijk op te leveren software gesteld worden!

En dat is precies wat je wel wilt vastleggen in systeemdocumentatie.

3. Requirements achterhalen

Binnen agile is er veel aandacht voor het achterhalen van requirements. Agile heeft een heldere en onderscheidende visie op de beste manier om dat te doen. Het belangrijkste daarbij is dat je tijdens de rit de requirements steeds verder uitwerkt. Je past ze voortdurend aan de laatste inzichten aan.

  DON’T   Er van uit gaan dat gebruikers precies weten wat hun requirements zijn

Ook niet als de gebruikers(vertegenwoordigers) zelf denken te weten wat voor systeem ze nodig hebben. In agile heb je volop mogelijkheden om de gebruikers te laten ontdekken hoe hun ideale systeem eruit ziet. Dat gebeurt geleidelijk gaandeweg het ontwikkeltraject.

Voor jou als agile analist is het ook een stuk relaxter dat de requirements niet in één keer helemaal goed hoeven te zijn.

4. Requirements detailleren

Vroeg of laat moeten we concreet en tot in detail aangeven wat de requirements zijn. Agile heeft uitgesproken ideeën over hoe en wanneer je dat het beste doet. Overbodig werk wordt zoveel mogelijk vermeden. Bijvoorbeeld het onderhouden van te vroeg vastgelegde requirements.

  DON’T   Voorkomen dat er een grote voorraad aan requirements ontstaat

Hoe meer requirements uitgewerkt zijn, hoe langer ze ‘op voorraad’ liggen te wachten totdat ze geïmplementeerd worden. De kans dat ze aangepast moeten worden doordat inzichten wijzigen, neemt dan toe.

Bovendien hebben requirements nauwelijks waarde zolang ze liggen te wachten, totdat het ontwikkelteam ze in een sprint oppakt.

5. Het werkproces van een agile analist

Requirements maken integraal onderdeel uit van elk agile proces. Agile is echter geen methode met voorgeschreven activiteiten en producten. Om het werk in goede banen te leiden, geeft scrum wel een raamwerk. Maar elk project moet dat zelf concretiseren. De 3 pijlers van agile kunnen je daarbij helpen.

  DO   De 3 pijlers van agile omarmen

Agile is bij uitstek geschikt om complexe projecten en slecht voorspelbare processen in goede banen te leiden. Daarvoor is inspelen op de actuele situatie en continu blijven meebewegen, essentieel.

De 3 pijlers van agile maken dat mogelijk en zijn:

  1. Transparantie
  2. Feedback
  3. Bijsturen

Tot zo ver het voorproefje met een beknopte beschrijving van een vijftal do’s and dont’s uit mijn GRATIS e-book ‘Vliegende start als agile analist’.

Dan ben ik nu benieuwd naar jouw ervaringen. Wil je de volgende 2 vragen beantwoorden in het reactieveld hieronder:

  1. Hoe volwassen met betrekking tot agile is de omgeving waarin je werkt?
  2. Wat is op dit moment het belangrijkste punt waar je met agile requirements tegenaan loopt?

Dank je wel voor je antwoorden!


Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap