TransformerenSommige requirementsanalisten beweren dat de veranderingen in hun werk door agile en Scrum wel meevallen. Ik denk dat deze analisten het onderschatten of dat ze nog steeds in een traditioneel project werken. Agile en Scrum hebben de wijze waarop we systemen ontwikkelen veranderd. De verschillen tussen een traditionele en een agile aanpak zijn groot. Dit heeft gevolgen gehad voor alle ICT-disciplines.

Ik heb de 5 grootste gevolgen die agile voor ons vakgebied heeft op een rij gezet.

1. Brugfunctie

We zeggen vaak dat requirements de brug vormen tussen business en ICT. Traditioneel is het de taak van de requirementsanalist om de requirements uit te vragen bij de business stakeholders en deze eenduidig vast te leggen. Vervolgens gaan ontwerpers, ontwikkelaars en testers op basis van de requirementsdocumentatie aan het werk.

In agile is het achterhalen van requirements geen taak meer van een analist, maar van het volledige ontwikkelteam. De analist faciliteert hooguit de kennisoverdracht van business naar ontwikkelteam. De ontwikkelaars vernemen zelf direct van de stakeholders wat hun wensen zijn en hoeven daarvoor geen uitgebreide requirementsdocumenten te lezen.

2. Kennisoverdracht

Requirementsanalisten waren altijd verantwoordelijk voor de requirements. Zij hadden een dagtaak aan het opstellen van de requirements. Hierdoor bezaten zij de kennis van de requirements en droegen die kennis voornamelijk schriftelijk over aan de andere projectleden.

Gezamenlijk gesprek

In agile hoeft een requirementsanalist zijn kennis niet over te dragen aan het ontwikkelteam, maar gaat het team zelf rechtstreeks in gesprek met de business. Iedereen verneemt de requirements uit de eerste hand en kennisoverdracht achteraf is niet nodig (voor het ontwikkelen van de software).

3. Oplossing

Requirementsanalisten zijn gewend om een strikte scheiding aan te houden tussen het WAT en het HOE, oftewel tussen requirements en (technische) oplossingen. We zeggen altijd dat de business gaat over het WAT en de IT’ers over het HOE.

In agile geldt nog steeds dat direct over oplossingen praten, zonder dat de behoeften van de business helder zijn, onverstandig is. In de requirementsmeetings (backlog refinement) worden de requirements en de oplossingen in samenhang besproken en hebben over en weer invloed op elkaar. De business stakeholders en ontwikkelaars wisselen ideeën uit en denken met elkaar mee. Ze zijn sparringpartners geworden met ieder hun eigen expertise én een gezamenlijk doel.

4. Business value

Bij traditionele systeemontwikkeling is alles gericht op de opgestelde en goedgekeurde requirements. Zo stuurt een projectmanager, implementeert een ontwikkelaar en test een tester de opgestelde requirements. Afhankelijk van de kwaliteit van de requirements levert het systeem meer of minder business value.

Growing up

Zoals ik heb toegelicht in Het verschil tussen requirements-gedreven en business value-gedreven ontwikkelen is iedereen in een agile project gefocust op het maximaliseren van de business value. Dit gebeurt door binnen enkele sprints een systeem op te leveren dat toegevoegde waarde heeft en door daar vervolgens iedere sprint meer waarde aan toe te voegen. Het systeem groeitzo van een zeer eenvoudig systeem dat maar beperkte business value heeft voor een subgroep van de gebruikers, naar een volwassen systeem dat de gewenste business value voor alle gebruikers heeft.

5. Kwaliteit

De volledigheid, juistheid en eenduidigheid van de requirements was altijd enorm belangrijk. Requirementsanalisten besteden daar veel aandacht aan en passen allerlei methoden en technieken toe om de kwaliteit van de requirements te verhogen.

Door de business value-gedreven manier van ontwikkelen is dat in agile projecten niet meer nodig. Het systeem en dus ook de requirements hoeven niet in 1 keer goed en niet van hoge kwaliteit te zijn. Sterker nog, je laat de requirements en het systeem als het ware geleidelijk ontstaan. Het ontwikkelteam én de business ontdekken gaandeweg de echte behoeften van de stakeholders.

Natuurlijk zijn er nog veel meer verschillen te noemen. Dit zijn de 5 belangrijkste die ik je mee wil geven. Welke verschillen zou je daar aan toe willen voegen? Zet je aanvullingen of opmerkingen in het reactieveld hieronder. Ik kijk ernaar uit.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book Vliegende start als agile analist

Met 25 do's en dont's 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:

Share This