Story / Impact Mapping – Context, principes en overzicht

Small-Batch-softwareontwikkeling is goed
Er zijn veel voordelen als je bij softwareontwikkeling de Small-Batch-aanpak (veel kleine afzonderlijke stappen) volgt:

• Snellere feedback
• Problemen worden gelokaliseerd
• Verminderd risico
• Meer druk en routine om de inspanning te verminderen

Naïeve Small-Batch-softwareontwikkeling is niet helemaal zo goed

Als je echter op een naïeve manier Small-Batch-softwareontwikkeling aanpakt, is er ook een belangrijk nadeel: het ontbreken van de link met het overkoepelende doel.

Jeff Patton heeft dit fenomeen beschreven aan de hand van het voorbeeld van een boom en een zak vol bladeren:

„Ik stel me een boom voor waarvan de stam bestaat uit de doelen en gewenste voordelen die het systeem voortstuwen. De dikke takken zijn de gebruikers, de dunnere takken en twijgen zijn de capabilities die ze nodig hebben. De bladeren vertegenwoordigen de User Stories die klein genoeg zijn om ze in de iteraties te ontwikkelen.
Na al dat werk, nadat we zoveel gedeeld begrip hebben opgebouwd, heb ik het gevoel dat we alle bladeren van de boom halen en in een grote zak proppen – en dan de boom omhakken."

De "zak vol blaadjes" verwijst naar een contextloze, geprioriteerde lijst van taken in een backlog en weerspiegelt het naïeve begrip van "backlogs" dat naar mijn mening vooral typisch is voor beginners in Agile. Ook al klinkt het in theorie als een small-batch-aanpak, bij de "zak vol blaadjes" wordt de verbinding met de onderliggende principes en doelen verbroken en daarmee de autonomie ondermijnd.

De 5 kenmerken van een effectieve small-batch-aanpak in softwareontwikkeling

Een effectievere aanpak gaat echter nog verder dan het opdelen in kleinere eenheden. Een effectievere aanpak:

• benadrukt de eigenlijke intentie met behulp van doelen.
• benadrukt het logische verband tussen de doelen en de benodigde taken.
• maakt doelen, taken en verbanden zichtbaar om eventuele inconsistenties en misverstanden bloot te leggen.
• is gericht op samenwerking.
• is iteratief, d.w.z. aan het begin is volledigheid niet vereist.
• Story/Impact Mapping vs. small-batch-softwareontwikkeling
  Zowel Jeff Pattons „User Story Mapping" als Gojko Adzics „Impact Mapping" zijn (grotendeels equivalente) antwoorden op de naïeve benaderingen voor het bepalen van de kleinere afzonderlijke stappen in small-batch-softwareontwikkeling (dus voor het opstellen van backlogs). Ik zou het als volgt omschrijven:

Opmerking: Dit Impact Mapping-proces zou iteratief moeten zijn. Het is hier alleen voor een beter begrip sequentieel weergegeven. Het is niet nodig en ook niet aan te raden om elke stap in deze volgorde uit te voeren. In plaats daarvan kun je beginnen op het punt waar je je nu bevindt en de stappen naar behoefte afwisselen.

1) Identificeer doelen
Wat wil je bereiken?

Dat zou iets moeten zijn wat je kunt observeren en dus ook kunt meten. Daarom vind ik de term "impact" zo passend, want dat betekent dat iets meetbaar is. Toch is "doel" gangbaarder en bovendien introduceer ik liever geen nieuwe terminologie als het niet strikt noodzakelijk is.

Er kunnen meerdere doelen zijn.

2) Rollen en activiteiten identificeren
Wie moet er aan een activiteit deelnemen om de doelen te bereiken? Of welke activiteiten moeten door iemand worden uitgevoerd om de doelen te bereiken?

Over het algemeen begin ik het liefst met de activiteiten. In de praktijk is het echter toch eerder een behoorlijk iteratief proces.

Let op: "Rol" betekent niet "persoon". "Persoon" kan verwijzen naar andere rollen die niets te maken hebben met jouw doelen, maar juist met hun eigen doelen. Dat betekent meestal dat je extra doelen moet toevoegen die ondersteund moeten worden.

3) Capabilities identificeren
Wat is de voorwaarde om een rol in staat te stellen een activiteit uit te voeren?
Capabilities hoeven niet per se iets te zijn dat in de software is ingebouwd.

4) Features en stories identificeren
Wat moet er gedaan worden om capabilities te creëren of mogelijk te maken?
Stories zouden uit kleinere werkzaamheden moeten bestaan. Bij features gaat het er meer om discussies op een gedetailleerder niveau mogelijk te maken.

Deze tekst is afkomstig van de blog van Jason Yip en is door ons naar het Nederlands vertaald.