Selecteer een pagina

PREVIEW

Hoever je agile requirements ‘moet’ uitwerken

 

Over het complete programma

Dit is een preview van het online programma ‘Agile requirements tot op het gewenste detailniveau uitwerken’.

Het is een gloednieuw trainings- en coachingsprogramma van vier maanden. Speciaal ontwikkeld voor analisten die te maken hebben met traditioneel denkende stakeholders.

Het complete programma bestaat uit acht webcolleges met opdrachten en mijn persoonlijke coaching.

Over deze preview

In deze preview getiteld ‘Hoever je agile requirements moet uitwerken’ laat ik je alvast een deel van het eerste webcollege zien.

Klik hieronder de rode balken open om de inhoud te lezen.

De tekst achter de grijze balken krijg je te zien als je deelneemt aan het trainings- en coachingsprogramma.

Lees hier wat het online programma precies inhoudt.

Preview van het eerste webcollege

Onderdeel van het programma Agile requirements tot op het gewenste detailniveau uitwerken

Nicole de Swart

Reguirementstechnieken expert & auteur Handboek Requirements

Het is mijn missie om het voor alle analisten mogelijk te maken om hun vak goed uit te oefenen.

Inhoud van dit webcollege

Bestudeer de hoofdstukken hieronder en maak de opdrachten

Ga naar ‘mijn opdrachten’ pagina

HOOFDSTUK 1. WAT ZIJN REQUIREMENTS?

Wat zijn agile requirements?

De term ‘agile requirements’ duidt op het gebruik van requirements in een agile omgeving. Net zoals ‘traditionele requirements’ aangeeft dat het om requirements in een traditionele (waterval) omgeving gaat. Niets meer en niets minder.

Agile requirements zijn dus nog gewoon de oude vertrouwde requirements, maar het proces, de werkwijze en de requirementstechnieken zijn veranderd.

Daardoor is ook de verschijningsvorm veranderd. In dat opzicht zijn agile requirements niet meer te vergelijken met traditionele requirements.

Bij traditionele requirements probeer je de behoeften van de business eenduidig en volledig te specificeren. Via die specificaties breng je de requirements over aan de ontwikkelaars (en de andere IT-disciplines). Traditionele requirements moeten daarom aan allerlei kwaliteitscriteria voldoen zoals consistentie, verifieerbaarheid en traceerbaarhied. Daarvoor is onder andere de term SMART requirements (specifiek, meetbaar, acceptabel, realistisch, tijdsgebonden) geïntroduceerd.

Bij agile requirements daarentegen ligt de focus op het mondeling overdragen van de behoeften en is de schriftelijke vastlegging alleen ondersteunend. Daarom zijn er in agile geen formele en uitgebreide specificaties. Tenzij je nog met traditioneel denkende stakeholders te maken hebt. Dan valt er lang niet altijd te ontkomen aan het uitgebreid vastleggen van de requirements.

De praktijk is vaak dat bepaalde stakeholders nog wel om (formele) specificatie vragen.

Dat geeft ze een gevoel van zekerheid. Ze willen weten waar ze aan toe zijn en daar kun je ze geen ongelijk in geven. De opdrachtgever geeft doorgaans pas budget vrij nadat is afgesproken wat hij daarvoor krijgt. Bij het uitbesteden van de softwareontwikkeling aan een traditioneel werkende leverancier, zijn de requirements onderdeel van het contract. En in veel organisaties willen de gebruikers (of vertegenwoordigers daarvan) de requirements graag op papier hebben en goedkeuren alvorens ze geïmplementeerd kunnen worden.

Dat het op voorhand afspreken en vastleggen van (meer dan globale) requirements schijnzekerheid geeft, beseffen deze stakeholders onvoldoende. Bovendien belemmert het tijdrovende wijzigingsbeheerproces (RFC-procedure) je om adequaat op voortschrijdend inzicht in te spelen.

Hoewel vrijwel iedereen de beruchte schommel metafoor onderschrijft, blijkt het voor veel stakeholders bijzonder lastig te zijn om die schijnzekerheid los te laten.

Als analist heb je niet de macht of de middelen om de traditioneel denkende stakeholders op andere gedachten te brengen.

Om ondanks de traditionele krachten in je organisatie toch op een agile manier te werken, is het belangrijk om zelf precies te begrijpen wat agile requirements inhouden.

Mondelinge en schriftelijke overdracht

Opdracht 1

HOOFDSTUK 2. USER STORIES

Wie agile requirements zegt, zegt meestal ook user stories. Een vraag die me vaak gesteld wordt, is:

‘Wat is nu eigenlijk het verschil tussen user stories en requirements, of is dat hetzelfde?’

User stories komen van oorsprong uit de agile aanpak eXtreme Programming (XP). Daar zochten ze naar een manier om snel software te realiseren die ze aan gebruikers konden voorleggen. Daartoe elimineerden ze alle onnodige overhead en zochten ze zelf, als ontwikkelaars, contact met gebruikers. Ze lieten de gebruikers hun verhaal vertellen, hun verhaal over het proces dat ze wilden uitvoeren. Hierdoor gingen de ontwikkelaars de wensen van de gebruikers beter begrijpen. Hier komt ook de naam ‘user story’ vandaan. Ze geven het verhaal weer dat de gebruiker heeft verteld. De ontwikkelaars gebruikten kaartjes om daar geheugensteuntjes op te schrijven, zodat ze tijdens het ontwikkelen van de software het verhaal van de gebruikers nog goed konden herinneren.

Een user story is één van de manieren om een requirement tot uitdrukking te brengen. Iedere user story is een representatie van een requirement. Andere manieren om een requirement tot uitdrukking te brengen zijn use cases, (free format) product backlog items, traditionele requirementszinnen zoals ‘het systeem moet …’.

Iedere user story is een representatie van een requirement, maar niet iedere requirement is een user story.

De omvang van een user story

User stories versus thema’s en taken

Typering van requirements

Opdracht 2

HOOFDSTUK 3. DE USER STORY TECHNIEK

Wanneer je meer informatie over een user story vastlegt

Allereerst wil ik benadrukken dat het hier gaat om de hoeveelheid informatie die je vastlegt. Niet om alle informatie die bekend moet zijn om de software te bouwen. De vraag is dus welk deel je daarvan moet vastleggen.

Uiteindelijk gaat het erom dat de informatie, op het juiste moment, in de hoofden van de teamleden zit.

In de user story techniek zoals Ron Jeffries deze bedoeld heeft, zijn niet veel meer dan geheugensteunen nodig. Maar dat is alleen toereikend als je praktijksituatie aan een aantal voorwaarden voldoet.

Vooral in hybride omgevingen worden er door traditioneel denkende stakeholders nogal eens obstakels opgeworpen. Meestal onbedoeld en onbewust, maar toch moet je daar rekening mee houden.

Zo is het detailniveau van de beschrijving van de user stories vaak een heikel punt. Traditioneel opererende stakeholders hebben specificaties van de requirements nodig en denken dat user stories gewoon een andere manier zijn om de requirements te specificeren. Logisch dus dat ze uitgebreide en nauwkeurige user story beschrijvingen verwachten. Een post-it is dan bij lange na niet voldoende.

Het ligt dan voor de hand om in excel of in een tool een uitgebreide beschrijving van de user story op te nemen.

De behoefte aan systeemdocumentatie is in een hybride organisatie groter dan in een puur agile organisatie. De user story techniek is uitsluitend bedoeld voor het afstemmen van de requirements die nog niet geïmplementeerd zijn. User stories zijn dus niet bedoeld en niet geschikt als systeemdocumentatie.

Kies daarom voor het opstellen van systeemdocumentatie een andere (traditionele) techniek die daar wel geschikt voor is.

User stories als geheugensteun gebruiken, zonder uitgebreide beschrijving, is alleen mogelijk als iedereen die de informatie nodig heeft, betrokken was bij het verfijnen van de requirements. Dat geldt in de eerste plaats voor het voltallige ontwikkelteam. En dat is nu juist ook een van die heikele punten in een hybride omgeving.

Vaak is het zo dat of de ontwikkelaars zelf of het management vinden dat ontwikkelaars vooral achter hun computer moeten zitten, en niet met de business mogen praten of meetings mogen bijwonen. Zij hebben daarbij de klassieke ineffectieve, saaie en veel te lang durende vergaderingen voor ogen. Logisch dat ze die niet willen bijwonen. Een geheugensteun voor een gesprek waar ze niet bij waren, raakt dan kant noch wal.

Er zit dan niets anders op dan de requirements die je met de business afgestemd hebt vast te leggen en schriftelijk over te dragen.

Je zou nog kunnen overwegen om, als analist, de user stories mondeling met het ontwikkelteam te bespreken. Maar zolang het eenrichtingsverkeer is en de ontwikkelaars niet actief participeren bij het helder krijgen van de requirements, blijft daarnaast een behoorlijk uitgebreide beschrijving noodzakelijk.

Een andere situatie waarin een geheugensteun niet toereikend is, is wanneer er teveel tijd verstrijkt tussen het moment waarop de requirements verfijnd worden en de sprint waarin het ontwikkelteam de user story oppakt. Er moet dan meer informatie vastgelegd worden om hetgeen mondeling afgesproken is te kunnen onthouden.

Als je met het opstellen van de user stories dus een paar sprints op het ontwikkelteam vooruit loopt, zijn geheugensteunen alleen niet afdoende. De kans dat het team over twee of meer sprints nog precies weet wat er besproken is, is klein. Logisch want ondertussen zijn ze in de lopende sprints met hele andere user stories bezig geweest.

Hoe verder je op het ontwikkelteam vooruit loopt, hoe uitgebreider je de user story voor hen moet beschrijven.

De meest voorkomende redenen dat je met het uitwerken van user stories meerdere sprints op het ontwikkelteam vooruit moet lopen, liggen bij de business. Bijvoorbeeld dat de product owner over te weinig mandaat beschikt en de stakeholders tijd nodig hebben om het eens te worden. Of dat de (vertegenwoordiger van de) gebruikers te weinig tijd hebben of niet actief participeren in het traject.

Opdracht 3

Ga naar het totaal overzicht