26 mei Efficiënte analyse: Just Enough in de praktijk
Rob den Hollander en Dennis Geluk
In het artikel Efficiënte analyse: just in time en just enough beschreef onze collega Selmar van Egmond onlangs waarom de LEAN principes ‘just-in-time’ en ‘just enough’ cruciaal zijn voor het schrijven van goede requirements. Selmar beargumenteerde onder meer dat het efficiënter is om requirements niet te gedetailleerd en niet te ver vooruit te beschrijven.
Elke agilist zal dit standpunt omarmen. Maar hoe stel je vast wat op welk moment de juiste diepgang voor je requirements is? Hoe voorkom je dat je als analist verzandt in het uitschrijven van requirements tot een niveau waarop niemand je meer kan volgen? En hoe voorkom je dat de added value van je extra inspanningen nihil wordt en enkel bijdraagt aan het verhogen van muda (verspilling)?
Kortom, wanneer heb je in de praktijk “Just enough” details in je requirements?
Het nadeel met “Just enough” is dat het ideale detailniveau van requirements in de praktijk per organisatie en per team verschilt. Er valt echter op hoofdlijnen zeker wel iets te zeggen over wat op welk moment een juist detailniveau voor requirements zou kunnen zijn. Dit is het makkelijkst uit te leggen aan de hand van een “standaard project” waarbij de normale projectcyclus van idee tot realisatie wordt doorlopen.
Efficiënte analyse toegepast: de start van een project
Een project begint meestal vanuit een behoefte of een goed idee. Maar al snel ligt de budgetvraag op tafel. Om een eerste schatting van het budget te kunnen maken hebben we een scope of een stip aan de horizon nodig. Dat kan op een aantal manieren.
‘Vroeger’ stelden we eerst een use case model op. We definieerden zoveel mogelijk use cases en we schreven deze wellicht ook al volledig uit. Deze aanpak is echter niet altijd efficiënt. Aanhangers van Agile methodieken stellen dan ook vaak dat use cases en use case modellen niet meer bij software ontwikkeling passen.
Wij vinden dit echter niet helemaal terecht. Onze ervaring leert dat use cases en use case modellen nog steeds een toegevoegde waarde hebben, ook voor software ontwikkeling!
Een use case model zorgt voor overzicht en richting
Een use case model is uitermate geschikt om snel en simpel een “stip aan de horizon” te identificeren. Een simpele “model storm” met de belangrijkste stakeholders kan snel tot een eerste use case model leiden.
Bij een dergelijke “model storm” worden de primaire use cases onderkend en krijgen ze (alleen) een korte omschrijving (Briefly Described). Hiermee wordt de scope van het systeem vastgesteld (Value Established). Door hier ‘just enough’ details te beschrijven blijft het use case model van absolute waarde in elke agile aanpak. Het use case model biedt namelijk snel een overzicht van the big picture van het project.
Een use case model zorgt voor samenhang tussen user stories
Wanneer het budget geregeld is kan u een (agile) team samenstellen om het systeem te realiseren. Dit team heeft een “backlog” nodig: een document waarin beschreven staat waar we met welke prioriteit aan werken. Het use case model dat we eerder aanmaakten om de scope van het project aan te duiden kan hierbij als uitgangspunt dienen om user stories te identificeren en te beschrijven.
Met een duidelijk use case model blijft de samenhang tussen de stories duidelijk en werken zowel de team als de product owner altijd vanuit the big picture.
Een use case model dient als kapstok voor de backlog
Om goede user stories te kunnen onderkennen hebben we per use case een beknopte procesbeschrijving nodig. Deze procesbeschrijving kan per use case beperkt worden tot een puntsgewijs stappenplan en het onderkennen van logische uitzonderingen (Bulleted Outline).
Elke user story kan op een behapbaar deel van het proces gebaseerd worden. Zo implementeert iedere user story automatisch een stukje van een use case en dus ook de scope van het project. Het use case model en de use cases dienen dus als “kapstok” voor de backlog!
Op dit punt hebben we budget en een team en weten we wat we willen realiseren. De vraag is nu of het echt nodig is om meer details per user story toe te voegen.
Efficiënte analyse: down the rabbit hole
Zoals Selmar in zijn artikel Efficiënte analyse: just in time en just enough beschreef is het belangrijk om als team voldoende tijd te besteden aan het doordenken van de documentatiestandaarden. Een goede afstemming van de behoeften en verwachtingen van alle stakeholders is hierbij cruciaal.
Detailniveau van requirements afhankelijk van verschillende aspecten
Binnen de documentatiestandaarden moet voldoende ruimte zijn om per user story een specifieke diepgang van de requirements te kiezen. Hierbij moet u rekening houden met de volgende aspecten:
- Hoe hoog is het gedeelde kennisniveau binnen het team en tussen het team en de stakeholders?
- Hoe mature is het team?
- Hoeveel teams zijn er betrokken bij het implementeren van het systeem en wat is de geografische spreiding van de teams (of teamleden)?
- Hoe makkelijk en frequent heeft het team toegang tot subject matter experts (materiedeskundigen)?
- Hoe strikt dient aan wet- en regelgeving voldaan worden?
- Is er sprake van een nieuwbouw product met korte verwachte levensduur, of van een langlopend product waarop vermoedelijk veel wijzigingen zullen plaatsvinden?
- Werken we met bewezen architectuur?
Hoe ‘ongunstiger’ de antwoorden op deze vragen zijn, hoe verstandiger het is meer details toe te voegen.
Detailniveau van requirements in de bouwfase
Als we met nieuwe architectuur aan de slag gaan, is het noodzakelijk dat de architect samen met de business op basis van de al beschreven stories en beknopte procesbeschrijvingen (use case outlines) vaststelt wat geautomatiseerd moet worden en welke bestaande systemen eventueel gebruikt kunnen worden.
In essentie leidt dit tot een keuze die bepaalt welk systeem verantwoordelijk zal zijn voor welke processtap. Deze keuze kan vastgelegd worden in de reeds gemaakt procesbeschrijvingen: we kunnen eenvoudig een actor bij ieder stap toevoegen (Essential Outline).
Eventuele externe systemen kunnen als supporting of secondary actor toegevoegd worden aan het bestaande UC Model. Hiermee worden ook direct de afhankelijkheden met externe systemen visueel voorgesteld. (System Boundary Established).
Gedurende de gehele bouwfase kunnen we per user story vaststellen hoeveel detail nodig is om de story te kunnen implementeren of over te kunnen dragen aan beheer. Voor de vastlegging van deze details kunnen we kiezen uit verschillende werkproducten: de use case narratives (tekst), test cases, supporting information en zelfs use case realizations.
De ‘lijm’ tussen al die werkproducten is de use case zelf. Elk werkproduct kent zijn eigen doel, en per story kiest u hoeveel detail er nodig is. Op deze manier worden use cases steeds verder verdiept maar enkel wanneer hiervoor een noodzaak of behoefte bestaat. Het eindeloos detailleren van een use case is geen doel op zichzelf!
De UC2.0 methode
Binnen DiVetro wordt bij de keuze van “Just enough” gebruik gemaakt van de handvatten die UC2.0 ons biedt. Binnen UC2.0 wordt per werkproduct een diversiteit aan detailniveaus (states) bepaald. Elk detailniveau dient een specifiek doel.
Door de UC2.0 methode als kapstok te gebruiken kunnen we op elk moment eenvoudig het ideale detailniveau bepalen. De UC2.0 methode is ook herhaalbaar en overdraagbaar naar andere analisten.
Onderstaande diagram komt uit een e-book van Ivar Jacobson en geeft een goed overzicht van de diverse detailniveaus zoals in dit artikel beschreven. U kunt de Nederlandstalige versie van het e-book downloaden. Op de website van Ivar Jacobson kunt u alle UC2.0 whitepapers vinden.
Figuur 1: UC2.0 Werkproducten en detaillevels
Meer weten?
Heeft u vragen over het ideale detailniveau van uw requirements? Of wilt u meer weten over Use Case 2.0 en hoe deze methodiek uw organisatie kan helpen? Wij horen uw vragen graag via het contactformulier onderaan deze pagina, via info@divetro.nl of via +31 (0) 88 000 54 00.
DiVetro is partner van Ivar Jacobson International en verzorgt onder andere trainingen op verschillende niveau’s. Ook staan wij altijd open om als professionals vrijblijvend ervaringen uit te wisselen. Neem gerust contact met ons op als u meer wilt weten!
Blijf op de hoogte
Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan in uw mailbox zodra ze op onze website verschijnen.
Rob den Hollander is senior informatie analist bij DiVetro. Hij heeft ruim 15 jaar ervaring met informatie analyse in systeem ontwikkeling en is gespecialiseerd in UC2.0 en Agile werken. Momenteel helpt Rob verschillende opdrachtgevers met het ontwikkelen/professionaliseren van agile teams.
Dennis Geluk is een senior informatie analist en partner van DiVetro. Hij heeft meer dan 15 jaar IT ervaring. Dennis is een gecertificeerd Use-Case 2.0 coach. Hij heeft bij verschillende organisaties een spilfunctie vervuld bij het implementeren van UC2.0, het invoeren van Agile werken en het verbeteren van requirements standaarden. Momenteel is Dennis als coach en informatie analist voor de NS bezig UC2.0 te implementeren. Lees hier meer over de NS-case.
