Event Storming ist ein kollaboratives Workshop-Format, das Teams dabei unterstützt, ein tiefes Verständnis von Geschäftsprozessen und -anforderungen zu entwickeln. Es kann helfen, komplexe Probleme zu identifizieren und Lösungen zu finden. Das Ziel dieses Artikels ist es, Ihnen eine Einführung in Event Storming zu geben, einschließlich der Grundlagen des Formats, wie man eine Session durchführt und bewährte Verfahrensweisen für die Nutzung von Event Storming. Alberto Brandolini ist der Erfinder dieser Methode. Lese weiter, um mehr darüber zu erfahren!
Einleitung, Übersicht & Zusammenfassung
In einem ein- oder zweitägigen Event kommen Menschen zusammen, um fachliche Ereignisse zu modellieren. Also das, was ein System leisten kann (z.B. eine Webseite mit einem Shop System), steht im Mittelpunkt und dazu sprechen alle Menschen mit einer einfachen Notation und schaffen das Verständnis dazu. Damit das im eigenen Kontext gut klappt, braucht es beim Eventstorming eine gemeinsame Sprache und auch eine gemeinsame Notation.
Ist diese Vorbereitung klar, kommen die Menschen zusammen und arbeiten über die festgesetzte Zeit - ohne Tische und ohne Stühle, meist an einer Wand auf der die Events chronologisch festgehalten werden. Der verlauf des Workshops ist sehr geprägt von Interaktion und Diskussion. Durch diesen kollaborativen Ansatz im Domain-Driven-Design (DDD) sprechen die Menschen durch diese Methodik zusammen
Das Ergebnis des Event Storming ist dann ein gemeinsames Bild aller Beteiligten auf das System. Die Vorteile liegen auf der Hand: Ist die Klarheit & das Verständnis vorhanden, lässt sich ein System viel besser entwickeln und Silos werden abgebaut und alle Stakeholder sind eingebunden. In Scrum kann daraus dann das Backlog mit einem Story Mapping erarbeitet werden.
Die Modellierung beim Event Storming
Bei Event Stormings arbeiten wir Post-Its (Klebezettel) und bringen das gesamte Team zusammen. Es geht um die Wissenstransfer zwischen Fachexperten, Stakeholdern, Product Owner und weiteren Menschen, die fachlich auf Geschäftsprozesse zu schauen und denen, die es entwickeln (Entwickler). Es geht immer um das gemeinsame Verständnis. Dazu hast du für deinen Workshop eine Papierrolle (oft brown paper), die mehrere Meter lang ist (10 Meter kann sich als sehr hilfreich erweisen) besorgt und an eine gute Moderation gedacht.
Du musst natürlich nicht zwingend die Farben sein, wichtig ist nur deine Legende, damit alle Teilnehmer wissen wofür die Farben stehen.
Event Storming Workshop: Kollaborativ die Requirements modellieren
Der Ablauf in einem Event Storming Workshop ist oft chronologisch von links nach rechts auf dem Brown Paper. Dabei wird die Wandfläche visuell immer voller und voller. Damit alle Teilnehmer alles gut verstehen eignet sich ein Big Picture, d.h. ein Bild auf dem alle Farben und Begriffe gelistet sind.
Das Unterstützt absolut auch das Ergebnis des Workshops. Das Bild ist oft trivial, der Weg dahin nicht. Neben einer guten Moderation, den richtigen Materialien und natürlich den richtigen Menschen ist das Big Picture ein wichtiger Baustein.
Domain Event
Beginnen wirst du immer mit den sogenannten Domain Events. Diese hast du oben schon kurz kennengelernt. Diese in der Vergangenheit geschrieben Events werden normalerweise auf orangenen Klebezetteln notiert und in der Vergangenheit geschrieben. Das sind Ereignisse, die Menschen aus der Anwendung und dem Fachbereich auf jeden Fall kennen. Mittels Event wird so ausgedrückt, was in der Fachdomäne passiert.
Beispiel: Warenkorb wurde aktualisiert.
Command / Aktion
Die Commands oder Aktionen sind eng zusammenhängend mit den vorherigen Domain Events. Denn das Ergebnis einer Aktion ist immer ein solches Domain Event.
Beispiel: Waren in den Warenkorb legen.
Akteur
Die oft per Strichmännchen gezeichneten User in einem System werden auf gelben Klebezetteln festgehalten. Das sind die Menschen, die mit dem System interagieren. Sie lösen auch ein Kommando und führen Befehle aus.
Beispiel: Webseitenbesucher / Kunde
Aggregate
In der Regel repräsentiert ein Aggregate eine Geschäftsregel oder einen Prozess im System. Das ist eine Gruppe von zusammenhängenden Elementen, die eine Einheit bilden.
Ein Beispiel könnte ein Online-Shop sein. Der “Order”-Aggregate könnte aus den Entitäten “Order”, “Customer”, “Product” und “Payment” bestehen. Diese Entitäten sind eng miteinander verbunden und bilden zusammen einen Bestellvorgang im System ab.
Externe Systeme
Externe Systeme sind alle Systeme oder Prozesse, die außerhalb des betrachteten Systems liegen. Diese können beispielsweise andere Systeme sein, mit denen das betrachtete System kommuniziert oder Schnittstellen hat. In der Event-Storming-Modellierung würden wir dies dadurch darstellen, dass wir ein neues Sticky Note erstellen und es mit einem Pfeil an das Haupthandlungssystem anschließen. Auf dieser Notiz würden wir dann alle relevanten Informationen über das externe System notieren.
Ein Beispiel für ein externes System im Event Storming könnte ein Payment Gateway sein. Wenn wir einen Online-Shop modellieren, würde das Payment Gateway als externes System betrachtet werden. Es interagiert mit dem Online-Shop und erbringt eine wichtige Funktionalität (in diesem Fall Zahlungen), aber es ist nicht Teil des Kernsystems.
Bounded Context, Subdomäne, Kontext
Im Event Storming ist ein “Bounded Context” ein abgegrenzter Bereich innerhalb eines Geschäftsprozesses oder einer Domain. In diesem Bereich existieren bestimmte Regeln und Bedingungen, die von anderen Bereichen abweichen können. Die Idee dahinter ist es, dass komplexe Geschäftsprozesse in kleinere, überschaubare Teile unterteilt werden können. Dadurch wird es einfacher, diese Teile zu verstehen und zu bearbeiten.
Ein Beispiel für einen Bounded Context könnte eine E-Commerce-Website sein. Innerhalb dieses Kontextes könnte es verschiedene Teilbereiche geben, wie z.B. das Bestellmanagement (Warenkorb) oder das Kundenkonto-Management. Jeder dieser Bereiche hat seine eigenen Regeln und Bedingungen.
Policies
Policies dienen dazu, Regeln für den Ablauf der Prozesse festzulegen. Diese entstehen durch Gespräche mit den Stakeholdern über den Tag.
Ein Beispiel: Angenommen, Sie planen ein Online-Shopping-System, bei dem Kunden eine Bestellung aufgeben können. In diesem Fall könnte eine Regel (Policy) lauten, dass eine Bestellung nur dann bearbeitet werden kann, wenn sie vollständige Informationen enthält (beispielsweise Lieferadresse und Zahlungsmethode).
Durchführung einer Event Storming Session
- Bereite den Raum vor und lade die richtigen Menschen ein
- Erkläre, wie der Workshop abläuft
- Starte mit der Erfassung der Domain Events (Brainstorming). Kategorisiere und fasse zusammen
- Finde bzw. grenze Kontexte bereits ab, wenn das möglich ist und bilde erste Aggregates
- Füge nun Aktionen und Benutzer hinzu
- Überlege welche Daten und Informationen benötigt werden (grün)
- Überprüfe die Aggregates und schaue was zusammengehörig ist
- Erstelle das erste Modell
- Verbessere und passe inkrementell und iterativ an
Fazit: Modellierung beim Event Storming
Insgesamt kann man sagen, dass Modellierung beim Event Storming ein äußerst nützliches Werkzeug ist. Durch die visuelle Darstellung von Geschäftsprozessen und -regeln können komplexe Zusammenhänge veranschaulicht und besser verstanden werden. Außerdem ermöglicht es eine effiziente Zusammenarbeit zwischen verschiedenen Abteilungen und fördert so die Innovation im Unternehmen. Wenn du also noch nicht mit dem Event Storming begonnen hast, solltest du es auf jeden Fall in Betracht ziehen!
Online Schulung zu Event Storming
Besuche meinen Kurs Agile Anforderungen für eine Übersicht über agile Anforderungen und Event Storming
