Event Storming – ein pragmatischer Ansatz

Das Event-Storming ist ein extrem leichtgewichtiges Workshop-Format und kommt aus dem Domain-Driven-Design. Mit diesem können wir herausfinden, was eigentlich in der Domäne unserer Software passiert und das bereits innerhalb von Stunden.

Dabei konzentriert sich das Event-Storming auf die Geschäftsprozesse. Im Gegensatz zur komplexen UML-Modellierung werden die einzelnen Abschnitte mit simplen Begriffen umrissen und auf Post-its geschrieben, die auch für Nicht-Techniker verständlich sind. In der Modellierung inkludiert das Event-Storming alle relevanten Stakeholder, diese tragen in gleichen Teilen dazu bei, das Zielbild zu formen. Auf die Frage, wer genau teilnimmt, lassen sich drei Typen von Stakeholdern definieren. Jene, die gut darin sind, die richtigen Fragen zu stellen, wie beispielsweise Entwickler oder Tester. Dann die, die gut darin sind, diese Fragen zu beantworten, wie die Domänen Experten, Kunden und Product Owner. Zuletzt noch einen guten Moderator, wobei grundsätzlich jeder diese Stelle besetzen kann. Wir haben gemerkt, dass es durchaus möglich ist, Moderator und Teilnehmer zu sein, solange sich diese Rollen für denjenigen trennen lassen.

Das gemeinsame Modellieren und die pragmatische Dokumentation sind es, was diese Methodik so effizient macht. Noch sinnvoller lässt sich das Ganze gestalten, wenn mindestens der Geschäftsprozess steht, sodass alle Teilnehmer eine gemeinsame Ausgangslage haben. In der Literatur werden Domänen auch durchaus ohne Geschäftsprozess durch das gemeinsame Verständnis der Teilnehmer entdeckt, allerdings verliert sich eine Gruppe dann sehr schnell in prozessualen Detail-Diskussionen. Daher ist unsere klare Empfehlung, erst den Prozess festzusetzen.

‍

VORBEREITUNG

Viel mehr Vorbereitung braucht es dann auch fast nicht. Eine große weiße Wand (circa 10 Meter) mit Papier beklebt oder ein entsprechendes Tool (wir nutzen hierzu Miro), Post-its in verschiedenen Farben (Orange, Blau, Gelb, Pink, Lila und Grün sind Pflicht) und 4-6 Stunden Zeit, je nach Umfang der Domäne.

Wir haben in diesem Format wie bei jeder Software nicht den Anspruch der Vollständigkeit, da wir wissen, dass Software nie fertig ist. Zudem beschränken wir uns entgegen der Literatur auf vier Schritte.

‍

SCHRITT 1 – DOMÄNEN-EVENTS SAMMELN

Im ersten Schritt sammeln wir alle Events, von denen wir glauben, dass sie im System relevant sind. Hierfür nutzen wir ausschließlich orange Post-its. Ein Event steht dabei auf einem Post-it. Jedes Event enthält ein Verb in der Vergangenheit. Dieser Schritt ist reines Brainstorming. Dabei sollte nur versucht werden, die Events chronologisch zu sortieren, um es später leichter zu haben, die Events zusammenzuführen. Parallele Events stehen dabei untereinander. Hier empfiehlt es sich, dass alle Teilnehmer zunächst in die Stillarbeit in einem eigenen Bereich gehen. Der Zeitrahmen hierfür beträgt circa 30-45 Minuten. Das fördert gerade die introvertierten Teilnehmer. Wir gehen grundsätzlich von 30 Minuten aus und lassen die Teilnehmer entscheiden, ob sie noch Zeit brauchen. Das Zielbild jedes Einzelnen nach diesem Schritt sollte ähnlich dem Bild 1 sein.

‍

SCHRITT 2 – DOMÄNEN-EVENTS VERFEINERN

Als Nächstes bestimmt der Moderator einen Teilnehmer. Dieser beginnt, sein Ergebnis vorzustellen und die Events zu erklären. Am besten eignet sich ein Teilnehmer mit einem sehr elaborierten Zielbild aus Schritt 1. Alle anderen Teilnehmer achten dabei auf syntaktische Korrektheit und entfernen die Duplikate oder Synonyme aus ihrem eigenen Zielbild. Hier ist es im Sinne der Dokumentation natürlich deutlich schöner, den Workshop in einem digitalen Tool zu machen, da sich Kopien von Schritt 1 einfach machen lassen.

Am Ende dieses Schrittes sollten wir ein gemeinsames, chronologisch korrektes Zielbild erhalten, ähnlich Abbildung 2. Zusammengehörige Events lassen sich hier schon gruppieren. Natürlich gilt auch hier, sollten wir Events vergessen haben, lassen sich diese in jedem Schritt ergänzen.

SCHRITT 3 – URSACHEN VERFOLGEN

Jetzt schauen wir uns an, woher die gesammelten Events eigentlich kommen. Dazu betrachten wir, welche Ursache das jeweilige Event hat. Nutzer-Aktionen werden durch den jeweiligen Nutzer (helles Gelb), also in diesem Beispiel generisch der User, und dem Kommando (Blau), gekennzeichnet. Dabei verzichten wir an dieser Stelle darauf, jedem Event ein Kommando anzuheften, wie es in manchen Beispielen gezeigt wir. Dadurch halten wir das System so sauber wie es auch wirklich umgesetzt wird. Häufig ist es ein Schritt Kommandos zu definieren, die das jeweilige Event triggern würden, um sie dann wieder herauszustreichen wenn es sich beispielsweise um eine automatische Abfolge handelt. Zudem kann hier noch markiert werden, in welcher Ansicht (Grün) der Nutzer das Kommando geben kann. Events können darüber hinaus auch durch den Faktor Zeit (Lila) entstehen oder durch externe Systeme (Pink), wie hier beispielsweise das Offer System, ausgelöst werden. Zudem verbinden wir die Post-its jetzt mit Pfeilen, um die Richtung anzuzeigen.

SCHRITT 4 – UMSORTIEREN & ERGEBNIS

Im letzten Schritt bestimmen wir jetzt die Aggregate (dunkles Gelb). Da Aggregate für manche Teilnehmer schwer zu greifen sind, können wir auch Objekt oder Datum sagen. In diesem Beispiel lässt sich gut gut erkennen, was damit gemeint ist. Ein Auftrag (=Order) stellt ein Objekt dar. Der wichtigste Punkt an dieser Stelle ist darüber hinaus das Identifizieren der Kontexte (=Bounded Context), hier durch die grauen Kreise dargestellt und benannt. Diese Kontexte helfen uns im Weiteren, unser System so modular wie möglich zu schneiden. Dabei achten wir darauf, fachlich zusammenhängende Einheiten zu schaffen.

ERKENNTNISSE

Das Event-Storming hilft uns dabei, unsere Domäne besser kennenzulernen und unser gemeinsames Wissen in ein System zu gießen. Als Ergebnis erhalten wir ein sehr elaboriertes Modell, das uns hilft, unser Team und die weiteren Schritte zu bestimmen. Dadurch, dass alle Projektmitglieder Teil dieses Prozesses waren, sorgt das Event-Storming für eine sehr hohe Akzeptanz im Team, auch wenn wir gemerkt haben, dass es starke Unterschiede darin gibt, ob dieses Format jemandem liegt oder nicht. Grundsätzlich stellt der initiale Schritt des Schreibens von Events “Nicht-Techies” eher vor größere Herausforderungen als “Techies”. Das Event-Storming ist keine Methode, die ausschließlich zu Beginn eines Projektes durchgeführt wird, sondern beliebig zur Bewertung bestehender Architektur oder zur Einschätzung neuer Features genutzt werden kann.

‍