Event Storming

Traditionele aanpak van projecten

Als een ontwikkelaar start aan een nieuw project, dan zijn daar al een heel aantal stappen aan vooraf gegaan. De sales medewerker heeft een lead, een analyst maakt een analyse, een project manager structureert alles in "user stories" en uiteindelijk komt het bij het ontwikkelteam terecht. Kennis over het project moet dus een heel aantal niveau's doorlopen om de ontwikkelaar te bereiken. Als de klant een duidelijk beeld heeft over het project en dat is op een goede manier vertaald naar user stories, dan kan de ontwikkelaar ook daadwerkelijk aan de slag.

Maar het kan gebeuren dat een nieuw project niet zo duidelijk is. Misschien omdat de klant er zelf niet zo'n duidelijk beeld over heeft, of omdat het idee nog aan het groeien is. Als een ontwikkelaar dan moet starten aan het project, dan kunnen er nog veel vraagtekens zijn. Er ontbreekt kennis. Niet enkel bij de ontwikkelaars, maar misschien ook bij de klant zelf. Daar kunnen we bij helpen, met Event Storming.

Wat is Event Storming

Event Storming is een manier om processen te gaan modeleren. De term werd voor het eerst bedacht door Alberto Brandolini, maar werd al snel geadopteerd door software ontwikkelaars over gans de wereld. In één of meerdere Event Storming Workshops gaan alle betrokken partijen, zowel technisch (developers) als niet technisch (klant, project manager, ...), samen gaan uitwerken hoe een project of proces in elkaar zit. Belangrijk hierbij is dat de focus ligt op het domein waar de klant kennis over heeft en niet op de technische uitwerking door de ontwikkelaars. Hoe gaat dit precies in zijn werk?

In een ruimte met een groot beschikbaar muuroppervlak gaan alle betrokken partijen, domain experts, ontwikkelaars, project managers enz. gans het project of proces modeleren door post-it's op de muur te plakken. Er gelden enkele regels:

• de muur is de tijdslijn, van links naar rechts
• er zijn post-it's van verschillende kleuren, elk met hun eigen betekenis
• tafels & stoelen worden aan de kant geschoven, het is geen suffe meeting!
• iedereen in de workshop werkt mee
• behalve een soort facilitator, hoeft niemand enige voorkennis over Event Storming te hebben
• geen technische oplossingen/woordenschat/... Voor alles wordt de taal van het domein gebruikt

Hoe gaat het in zijn werk?

In eerste instantie worden de post-it's gebruikt die de betekenis "Domain Event" hebben. Een Domain Event is "iets wat gebeurd is", een vaststaand feit in een proces. Je kan het vergelijken met hoe je een verhaaltje vertelt: "Ik heb eerst mijn schoenen aan gedaan, dan mijn jas, ben dan naar de krantenwinkel gestapt en heb dan een krant gekocht". De Domain Events zijn dan "Schoenen werden aan gedaan", "Jas werd aan gedaan", "Naar krantenwinkel gestapt" en "Krant werd gekocht". Domain Events vormen dus een natuurlijke manier om een proces te beschrijven.

Iedereen in de workshop schrijft Domain Events neer op de post-it's, ongeacht of het duplicaten zijn, of de juiste termen gebruikt worden en of het event daadwerkelijk bestaat. Alle events worden chronologisch op de muur geplaatst. Na verloop van tijd raakt de muur wat vol en er worden niet meer zoveel events "ontdekt". Er beginnen discussies te ontstaan, vragen worden gesteld aan de Domain Expert, specificaties worden ontdekt.

Zulke specificaties van een Domain Event worden op een ander soort post-it geschreven en rechts van het Domain Event geplakt. Specificaties zijn het onderdeel waar veel vragen over gesteld worden aan de Domain Expert. Hij is de enige die ze kan beantwoorden. Het is dus belangrijk om veel te overleggen en alles vast te leggen. Het Domain Event "Jas werd aan gedaan" heeft de  restricties "Enkel als het koud is", "Enkel de eigen jas", "In de zomer een zomerjas", "In de winter een winterjas".

Een Domain Event kan nooit zomaar uit het niets ontstaan zijn. Er is altijd een aanleiding of actie nodig die het veroorzaakt. Deze acties worden terug op een nieuw soort post-it geschreven en voor een Domain Event gehangen. We kunnen ook specifiëren hoe de actie veroorzaakt wordt: door een gebruiker, een automatisch proces, ... Het Domain Event "Jas werd aangedaan" is het gevolg van de actie "Doe jas aan".

Naarmate de muur vol begint te hangen met Domain Events, Actions, Specifications en zo meer, beginnen bepaalde post-it's logische clusters te vormen omdat ze onderdelen zijn van een groter samenhangend geheel. Alle acties, events, specificaties, ... om contacten aan te maken, te wijzigen, te raadplegen, te exporteren en zo meer zijn allemaal onderdeel van Contactenlijst. Als zoiets gevonden wordt tijdens de Event Storming Workshop, wordt het (uiteraard) terug neergepend op terug een nieuw soort post-it en aan de muur geplakt.

Het uiteindelijke restultaat van de workshop kan er zo uit zien:

Wat is het resultaat?

Een muur volgeplakt met post-it's is enkel maar het tastbare resultaat. Wat veel belangrijker is, zijn de ontastbare resultaten:

• Kennis. Iedereen die mee deed met de workshop, komt op het einde buiten met dezelfde kennis over het project of proces. Doordat het een actief leerproces is, zal die kennis ook veel langer blijven hangen.
• Oplossingen. Wat op het eerste zicht complex leek, is nu mooi gestructureerd. Soms kan iets niet opgelost worden met software, omdat het proces zelf al mank loopt. Ook dat is een oplossing, namelijk proces optimalisatie.
• Klare taal. Software ontwikkelaars en klanten gebruiken andere woorden om over hetzelfde te praten. Event Storming dompelt de ontwikkelaars onder in taalbad van de Domein Expert(s). Iedereen praat nu over hetzelfde.

Een Event Storming Workshop is intensief en kost veel tijd. Maar de kennis die eruit komt is op zich de tijd al meer dan waard. Alles is klaar en duidelijk voor zowel de ontwikkelaars als de klanten. Alle processen zijn gedefiniëerd en de verwachtingen zijn mooi opgelijst. Er is niets meer wat door een ontwikkelaar anders kan geïnterpreteerd worden dan door de klant. De voordelen zijn dus legio.

Neem vrijblijvend contact indien u meer info wenst.