© Liashko/Shutterstock.com
Entwickler Magazin
Mehr Dynamik mit Event Storming

Im Rückwärtsgang Domänen erforschen

Traditionelle Anforderungsworkshops ohne Beteiligung der Entwicklung erfüllen den heutigen Time-to-Market-Anspruch nicht mehr. Mit dem vor einigen Jahren eingeführten User Story Mapping wurde das immerhin schon einmal besser. Was ist aber, wenn das Grundverständnis der Fachdomäne im Team noch nicht hergestellt ist, sodass das Storyschreiben schwerfällt? Hier kann Event Storming helfen, eine Workshopmethode aus der Domain-driven-Design-Familie. Fachexperten und IT-Leute verbrauchen dabei enorm viele Post-its, um ein gemeinsames Verständnis einer Fachdomäne zu bekommen.

Matthias Bohlen


Domain-driven Design (DDD), das Eric Evans schon 2004 definiert hat [1], feiert fröhlich Auferstehung, angefeuert durch aktuelle Themen wie Microservices-Architekturen und DevOps-Kultur. Es geht darum, gemeinsam mit Fachexperten eine Domäne mittels DDD zu erforschen, also den Kontext des zu lösenden Problems tiefgreifend zu verstehen, bevor man mit scharfen Messern herangeht und Microservices schneidet. Das sollte eigentlich selbstverständlich sein. Was könnte andernfalls passieren, wenn man dies nicht tut?

Wir lösen ein Problem mit Software, das wir besser organisatorisch gelöst hätten und produzieren so vermeidbare Kosten.Wir schneiden Microservices, errichten harte Remote-­Call-Grenzen dazwischen und handeln uns plötzlich große Refactoring-Aufwände ein, wenn endlich das Domänenverständnis einsetzt.Wir glauben zu verstehen, was gefordert ist, entwickeln los, und merken zu spät, dass wir zu wenig wussten und deshalb teure Iterationsschleifen ziehen müssen.Wir ignorieren den Beitrag mancher Stakeholder, weil es uns anfänglich zu viele waren, und merken später, dass diese Stakeholder ein völlig neues Licht auf die benötigten Funktionen werfen.

Ich bin überzeugt von Lean und Kanban und deshalb kein Fan davon, viel auf Vorrat zu erheben und zu entwerfen. Doch dass Iterationen Geld kosten, ist auch klar. Wie könnten wir also die Sicherheit gewinnen, tatsächlich das richtige Problem zu lösen? Einen besseren Startpunkt zum Iterieren finden und mehr Stakeholder einbeziehen, ohne verrückt zu werden? Außerdem wollen wir die Domänen im Team früh und gemeinsam besser verstehen. Und Risiken, seltsam gestaltete Geschäftsprozesse und mögliche Know-how-Lücken, frühzeitig erkennen und einbeziehen, anstatt davon überrascht zu werden. Dafür gibt es eine Methode, die gute Ergebnisse liefert und auch noch Spaß macht: Event Storming.

Was ist Event Storming?

Event Storming ist eine Methode, um in interaktiven Workshops mit Fachexperten und IT-Leuten gemeinsam eine Domäne so weit zu erforschen und zu verstehen, dass man anschließend locker mit dem Entwurf der ersten Subsysteme loslegen kann. Man sortiert die Unordnung und die seltsamen Dinge aus, bevor Software entwickelt und zu viel Geld ausgegeben wird. Dadurch gewinnt man einen Vorsprung für das spätere Iterieren.

Der italienische Consultant Alberto Brandolini (auch bekannt als @ziobrando, Onkel Brando) hat Event Storming ausführlich beschrieben [2]. Es ist eine Art Brainstorming, bei dem eine Gruppe gemeinsam die wichtigen fa...

Entwickler Magazin
Mehr Dynamik mit Event Storming

Im Rückwärtsgang Domänen erforschen

Traditionelle Anforderungsworkshops ohne Beteiligung der Entwicklung erfüllen den heutigen Time-to-Market-Anspruch nicht mehr. Mit dem vor einigen Jahren eingeführten User Story Mapping wurde das immerhin schon einmal besser. Was ist aber, wenn das Grundverständnis der Fachdomäne im Team noch nicht hergestellt ist, sodass das Storyschreiben schwerfällt? Hier kann Event Storming helfen, eine Workshopmethode aus der Domain-driven-Design-Familie. Fachexperten und IT-Leute verbrauchen dabei enorm viele Post-its, um ein gemeinsames Verständnis einer Fachdomäne zu bekommen.

Matthias Bohlen


Domain-driven Design (DDD), das Eric Evans schon 2004 definiert hat [1], feiert fröhlich Auferstehung, angefeuert durch aktuelle Themen wie Microservices-Architekturen und DevOps-Kultur. Es geht darum, gemeinsam mit Fachexperten eine Domäne mittels DDD zu erforschen, also den Kontext des zu lösenden Problems tiefgreifend zu verstehen, bevor man mit scharfen Messern herangeht und Microservices schneidet. Das sollte eigentlich selbstverständlich sein. Was könnte andernfalls passieren, wenn man dies nicht tut?

Wir lösen ein Problem mit Software, das wir besser organisatorisch gelöst hätten und produzieren so vermeidbare Kosten.Wir schneiden Microservices, errichten harte Remote-­Call-Grenzen dazwischen und handeln uns plötzlich große Refactoring-Aufwände ein, wenn endlich das Domänenverständnis einsetzt.Wir glauben zu verstehen, was gefordert ist, entwickeln los, und merken zu spät, dass wir zu wenig wussten und deshalb teure Iterationsschleifen ziehen müssen.Wir ignorieren den Beitrag mancher Stakeholder, weil es uns anfänglich zu viele waren, und merken später, dass diese Stakeholder ein völlig neues Licht auf die benötigten Funktionen werfen.

Ich bin überzeugt von Lean und Kanban und deshalb kein Fan davon, viel auf Vorrat zu erheben und zu entwerfen. Doch dass Iterationen Geld kosten, ist auch klar. Wie könnten wir also die Sicherheit gewinnen, tatsächlich das richtige Problem zu lösen? Einen besseren Startpunkt zum Iterieren finden und mehr Stakeholder einbeziehen, ohne verrückt zu werden? Außerdem wollen wir die Domänen im Team früh und gemeinsam besser verstehen. Und Risiken, seltsam gestaltete Geschäftsprozesse und mögliche Know-how-Lücken, frühzeitig erkennen und einbeziehen, anstatt davon überrascht zu werden. Dafür gibt es eine Methode, die gute Ergebnisse liefert und auch noch Spaß macht: Event Storming.

Was ist Event Storming?

Event Storming ist eine Methode, um in interaktiven Workshops mit Fachexperten und IT-Leuten gemeinsam eine Domäne so weit zu erforschen und zu verstehen, dass man anschließend locker mit dem Entwurf der ersten Subsysteme loslegen kann. Man sortiert die Unordnung und die seltsamen Dinge aus, bevor Software entwickelt und zu viel Geld ausgegeben wird. Dadurch gewinnt man einen Vorsprung für das spätere Iterieren.

Der italienische Consultant Alberto Brandolini (auch bekannt als @ziobrando, Onkel Brando) hat Event Storming ausführlich beschrieben [2]. Es ist eine Art Brainstorming, bei dem eine Gruppe gemeinsam die wichtigen fa...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang