In 2011 lanceerde Ivar Jacobson het boek use case 2.0. Dit boek is gratis te downloaden in ruil voor je e-mailadres. In deze blog probeer ik de aanpak beschreven in dit document samen te vatten.

Use cases staan bekend om toe te passen in de specificatiefase van een systeem. Ze worden gebruikt om de werking van het systeem te documenteren met use case beschrijvingen in templates. Tegenwoordig gebruiken bedrijven steeds meer de agile aanpak in projecten om snel waarde te leveren in de snel veranderende digitale wereld. Met de verandering van een projectaanpak is het essentieel om de specificatiefase op een andere manier aan te pakken.

De use cases worden in slices opgedeeld zodat het team deze eenvoudig en gericht kan inschatten en bouwen.

In het bekende Agile Manifesto wordt gesteld dat klant samenwerking boven documentatie gaat. Er wordt vaak gedacht dat er in agile projecten helemaal geen documentatie wordt geschreven maar dit is zeker niet waar. Ivar Jacobson heeft een belangrijke rol gespeeld in het bedenken van de use case methode en heeft UML ontwikkeld.

 Wat is use case 2.0?

Use case 2.0 is een agile aanpak die gebruik maakt van use cases om requirements te bepalen, de incrementele ontwikkeling van een systeem aan te drijven en uiteindelijk te voltooien. Use case 2.0 is lichtgewicht, schaalbaar, veelzijdig en gemakkelijk te gebruiken. Met deze aanpak worden use cases effectiever gepresenteerd, geadresseerd en gemanaged en worden ze geschikt voor een agile projectaanpak. Er gelden 6 principes die het hart vormen voor het succesvol toepassen van use cases.

1. Houd het simpel door een verhaal te vertellen

In een eerdere blog heb ik het principe van use case narratives uitgelegd. Het vertellen van een verhaal is de meest eenvoudige vorm voor het communiceren over requirements. Het verhaal kan worden geschreven vanuit een persona. Een persona is een archetype van een gebruiker van het systeem. De verhalen vangen samen de doelen van het systeem. Een use case is gefocust op het behalen van een specifiek doel. Door meerdere use case narratives te schrijven van een verhaal wordt de use case ingevuld. Voor iedere use case narrative worden meerdere test cases geschreven. De testcases zijn belangrijk omdat deze vertellen wat het systeem moet doen zodat de use case narratives niet meer vrij te interpreteren zijn.

2. Begrijpen van het grote plaatje

Welk systeem er ook ontworpen wordt, het is belangrijk om het grote plaatje te begrijpen. Zonder dit overzicht is het onmogelijk om keuzes de maken wat er in het systeem betrokken wordt of wat er juist uitgelaten moet worden. Dit betekend niet dat alle requirements op detail vooraf uitgewerkt moeten worden. Er is iets nodig om een opsomming te maken van het gewenste systeem. Een use case diagram geeft een mooi en eenvoudig overzicht van de high level requirements.

3. Concentreer op waarde

Tijdens ontwikkeling is het belangrijk dat er wordt geconcentreerd op de onderdelen die de hoogste waarde bieden aan de eindgebruikers en stakeholders. Waarde wordt alleen gecreëerd als het systeem ook werkelijk kan worden gebruikt. In het project moet er dan ook gefocust worden op de software i.p.v. een enorme gedetailleerde backlog van gedetailleerde requirements. Om de use case simpel te houden wordt er begonnen met het eenvoudigste pad om het doel te halen. Daarnaast worden er alternatieve manieren geïdentificeerd om hetzelfde doel te behalen. Ook worden uitzonderingen geïdentificeerd die in de weg kunnen staan om het doel te behalen. Soms bieden de alternatieve manieren nauwelijks meer waarde dan de basis flow. Een use case narrative is de perfecte manier om te concentreren op de eenvoudigste manier om een doel te halen. Deze additionele flows en uitzonderingen hebben vaak een lagere waarde en belanden dan ook vaak verder op in de backlog van agile projecten. Door de concentratie op waarde is het zeker dat iedere release op de echte waarde concentreert.

4. Bouw het systeem in slices

Een basisflow uit een use case narrative is een goed startpunt om ontwikkeling op te pakken. Vaak is de basisflow nog te groot om als item op te pakken. De use case narratives worden in slices opgedeeld tot kleine gedeeltes zodat het team deze eenvoudig en gericht kan inschatten en bouwen. Een enkele stap uit de basis flow is een voorbeeld van een use case slice. Het team kan in een periode van een aantal weken een aantal slices verwerken. Dit is belangrijk omdat het team op deze manier progressie kan laten zien. Het is niet ondenkbaar dat een basisflow meerdere iteraties in beslag kan nemen.

5. Lever het systeem incrementeel op

Door het systeem incrementeel op te leveren met een aantal slices wordt er geconcentreerd op waarde. Use case diagrammen kunnen aangeven welke onderdelen er worden opgeleverd in het increment van de release.

6. Aanpassen om aan de behoeften van het team te voldoen

Er bestaat niet een alleszeggende methode om systemen te ontwikkelen. Ieder team of iedere situatie heeft een eigen stijl nodig in de aanpak. De factoren in de situatie bepalen welk niveau uitwerking er nodig is van een bepaalde use case slice. Use-Case 2.0 heeft hier een oplossing voor. De meest lichtgewicht versie is om use case narratives op losse notes te schrijven en zo de slices te bepalen. Het team bepaalt zelf of er nog andere uitwerkingen nodig zijn om een werkbare situatie te creëren die waarde oplevert.

Conclusie use case 2.0

Het document use case 2.0 gaat nog verder in op assets die bruikbaar zijn in de visualisatie of management van de use case slices. Ik ga hier verder niet op in met deze blog. Use Case 2.0 is voor mij een effectieve methode om de business te laten concentreren op de waarde en overige wensen te identificeren in additionele user stories of use case slices.

Use cases worden met use case 2.0 geschikt voor agile door het opsplitsen in slices

De lijst requirements groeit mee met het increment maar er wordt wel meteen waarde geleverd. De use case narratives zijn eenvoudig te schrijven en kunnen zelfs door de klant worden opgemaakt na enige oefening. Deze methode werkt voor mij beter dan het stoppen bij user stories omdat user stories alleen de actor en het doel beschrijven. De use cases beschrijven hoe dit doel door de actor wordt gehaald en wat de interactie is met het systeem. Het is zeker de moeite om use case 2.0 een keer goed door te nemen.

Referenties use case 2.0