Event Storming – ett effektivt sätt att utforska affärsprocesser

Upplever du att det finns ett glapp mellan de som förstår verksamheten och de som utvecklar mjukvaran? Genom en enkel övning kan ni utforska er affär, underlätta dialogen mellan de inblandade och samtidigt förbättra kvaliteten på er mjukvara.

Att nå en gemensam förståelse av affären

När ny funktionalitet ska utvecklas behöver ett team tid till att förstå vad de förväntas skapa, även om det föreligger en omsorgsfullt skriven kravtext som tycks beskriva problemet i detalj. Oundvikligen skapar sig varje teammedlem först en egen bild av problemet. Denna bild är oftast antingen mer eller mindre komplex än det egentliga problemet. Under systematisering av ett affärsflöde behöver utvecklare plocka isär och i detalj analysera de affärsprocesser som systemet avser att stödja. Under denna process dyker det upp frågor som teamet antingen kan ta beslut kring själva, baserat på deras nuvarande förståelse för affären, eller så ställer de frågan till någon som har svaret. De som sitter inne med svaren är dessvärre inte alltid så lätta att få tag i och därför finns det en risk att utvecklare tar beslut som inte stämmer överens med affären.

Börjar det låta som en omöjlig situation? Vi kan förstås försöka få mer tid med domänexperten men troligtvis är schemat fullt med ärenden som har gjort att vederbörande har blivit just expert. För att skapa förutsättningar för teamet att ta beslut som bättre överensstämmer med affären kan vi istället utforska domänmodellen tillsammans med domänexperten. Det är viktigt att domänmodellen bygger på delad förståelse och inget lämnas åt fri tolkning. Teamet kan inte själva skapa en tillfredställande domänmodell utan den bör växa fram under diskussioner mellan samtliga inblandade. Det är av största vikt att man nyttjar tiden med domänexperten maximalt och lär sig så mycket som möjligt under kortast möjliga tid. En övning för att effektivt utforska domänmodellen kallas Event Storming.

Event Storming

Event Storming är en övning i workshop-format för att få ut så mycket som möjligt av tiden med domänexperten. Övningen är utvecklad av Alberto Brandolini och har djupa rötter i domändriven design, CQRS och Event Sourcing. Målet med övningen är att tillsammans utforska affärsflödet och visualisera det. En bonus är att vi får chans att upptäcka komplexitet i affären i ett tidigt skede.

Innan vi sätter igång behöver vi vara väl förberedda och se till att vi skapar rätt förutsättningar för en lyckad workshop:

• Förbered en obegränsad modelleringsyta. Alltför ofta analyseras inte komplexa problem till fullo eftersom det helt enkelt inte finns tillräckligt med fysiskt utrymme för att visualisera hela problemet. Vi vet inte hur stort problemet är innan vi har utforskat det i sin helhet. Problemet är ofta större än en whiteboard men varför ska detta stoppa oss? En pappersrulle från IKEA är en billig lösning!
• Bjud in rätt personer till workshopen. Förlägg helst övningen i ett stort rum med rätt blandning av personer. Bjud in de som vet vilka frågor som ska ställas och de som har svaren. För få deltagare kan leda till att man börjar spekulera om saker som ingen i rummet kan svara på och för många kan innebära att man inte utnyttjar varje domänexpert till fullo. Det är med andra ord viktigt att få med alla nyckelpersoner och ta till vara på deras tid under workshopen.
• Ta bort stolarna. Ju längre vi sitter, desto mindre mottagliga blir vi för nya idéer och infallsvinklar. För att hålla kreativiteten vid liv kan man undanröja frestelsen att sätta sig och undvika att workshopen förvandlas till ytterligare ett kravmöte. Se till att turas om att sitta om benen börjar värka.

Nu kan vi sätta igång!

• Börja utforska domänen med händelser som utgångspunkt. Be domänexperten ge ett exempel från affärsprocessen. Avsikten är att locka fram nyckelord, facktermer och formuleringar som ni kan diskutera utifrån. Lyssna noga på exemplet och extra noga efter ordet “när” – det är ofta ett tydligt exempel på en meningsfull händelse som vi bör utforska närmare. Exempelvis: “… och när lånetiden har gått ut vill vi skicka en påminnelse till låntagaren”. I detta fall kan vi skriva ”Lånetiden gick ut” på en post-it och sätta upp den så att alla ser. Utgå sedan från denna lapp och diskutera vad som medförde att detta inträffade, samt vilka följder det får. Placera alla post-it-lappar med händelser i förhållande till varandra längs en tidslinje på modelleringsytan. Detta gör att det bli lätt att följa affärsflödet från start till slut allt eftersom fler lappar kommer upp.
• Utforska ursprunget till dessa händelser. Vissa händelser är konsekvenser av en direkt handling av någon inblandad. Representera även dessa handlingar på tidslinjen och se till att använda en färg som skiljer sig från lapparna med händelser på. En del händelser behöver däremot inte komma till följd av en aktiv handling. Andra händelser är följden av något som har hänt i externa system eller på grund av att tid passerat. Markera dessa händelser med en egen färg. Detta är en utmärkt chans att upptäcka beroenden till andra team.

Det är viktigt att formulera händelser i dåtid, eller preteritum, och handlingar som uppmaningar (imperativ) i presens. Detta underlättar dialogen märkbart när man följer en serie av handlingar och händelser, till exempel: “När en låntagare vill låna en bok så lånades boken ut eller så nekades lånet.”

Var noga med att använda det språk som framträder i era diskussioner. Det är lätt att uttrycka sig vagt: “… och så tjoffar någon in beställningen i systemet.” Be då personen att fundera om det inte finns ett annat, bättre och mer entydigt sätt att uttrycka sig. Det är inte säkert att det finns ett bra ord för just detta, men utnyttja då tillfället till att enas om ett sätt att uttrycka er på som alla förstår.

Ovanstående är de grundläggande stegen för Event Storming. Är man lyhörd kan man dessutom uppnå några bonusmål längs vägen. Beroende på vart diskussionerna leder er kan det finnas ett värde i att addera nyvunna insikter till modelleringsytan i form av post-it-lappar, för att klargöra tvetydigheter.

• Utforska subdomäner. En del domänexperter kan mer om vissa delar av affären än andra. Detta kan vara ett tecken på att det finns flera affärsområden i domänen. Olika ansvarsområden kan ofta motsvara subdomäner i domänmodellen. Vissa subdomäner är kärnan i verksamheten, utan dessa är vi inte längre konkurrenskraftiga. Andra subdomäner är nödvändiga men inte lika viktiga.
• Utforska avgränsade kontexter. Under diskussionerna kan konflikter uppstå. Den som lyssnar noga märker när en term används omväxlande med olika betydelser. Utforska huruvida det rör sig om olika kontexter och ringa in dessa på modelleringsytan.
• Definiera personas. När man talar om handlingar tenderar diskussionen att styras mot den kontext där handlingen gjordes, såsom vilken användare som utförde handlingen och vad som var syftet. I exemplet ovan nämnde domänexperten även vem som utförde handlingen: låntagaren. Utnyttja detta och introducera en ny lapp, Låntagare, i anslutning till handlingen.
• Definiera acceptanstester. Om diskussionen börjar handla om undantagsfall eller tvetydiga scenarion, definiera tydliga acceptanstester. Alla scenarion behöver inte definieras på detta sätt under modelleringsövningen men det finns ingen anledning att inte fånga dessa om de dyker upp (gärna i formatet “Givet att [händelser], när [handling], så [händelser]).
• Definiera viktiga vyer. I vissa situationer är det viktigare vad användaren ser än vad systemet gör. Om en graf, tabell eller speciell vy är nödvändig för att användaren ska kunna ta ett beslut, skriv upp det på en lapp och placera den vid handlingen den är associerad med.

Det är inte alltid dessa punkter dyker upp, men om de väl diskuteras, utnyttja detta och komplettera er modell med den nyvunna kunskapen. Syftet med övningen är att låta de inblandade få en djupare insikt i helheten, belysa problemområden och låta idéer träda fram. Låt er inte förledas och tro att målet är att skapa en fullständig specifikation eller dokumentation. Undvik därför att spara era lappar. Med er nyvunna förståelse för affären kan ni lätt återskapa det ni har gjort!

Att tänka på vid Event Storming

Testa först att utforska domänen i utvecklingsteamet för att se om alla i gruppen har samma bild av vad ni försöker skapa. När teamet känner sig bekvämt med formatet, bjud in de personer ni tror kan hjälpa er att svara på de frågor som dyker upp. Fundera även på vilket språk ni vill använda er av när ni skriver lappar. Att skriva affärsflödet på engelska kan underlätta när modellen omsätts i kod men hämma diskussionen om många av termerna är på svenska.

Ofta speglar inte mjukvaran det man kommit fram till under övningen. En färdigstormad modell är inte nödvändigtvis en grund för att skriva om systemet, utan se den snarare som en färdriktning. Sträva inte efter att bli färdiga. Domänmodellen är något som lever och förändras hela tiden, så se till att ni stämmer av med varandra regelbundet och säkerställer att ni är på samma spår.

Vill du prova event storming?

Vill du köra event storming på ditt bolag, men vill ha stöttning? Ta in någon från oss på Citerus som hjälper till med workshopen!

Fyll i formuläret här så hör vi av oss och pratar om vad ni behöver hjälp med.