Im letzten Artikel (hier) ging es darum, wie du ein virtuelles Brainstorming durchführen kannst. Im heutigen Teil erfährst du wie wir Eventstorming durchführen, welche Vorbereitung es benötigt und bekommst jede Menge Erfahrungen. Am Ende wirst du noch ein praktisches Fallbeispiel erfahren.
Eventstorming ist eine Kreativtechnik die wir einsetzen, um unsere Software zu entwerfen und um ein gemeinschaftliches Big-Picture auf unsere Produkte zu bekommen. Die Technik kann auch für andere Problemstellungen als Softwareentwicklung genutzt werden z.B. für die Herleitung von Geschäftsprozessen, was aber nicht Teil dieses Artikels ist. Ziel von Eventstorming ist es eine (Programm-) Vision soweit zu detaillieren, dass konkrete Entwicklungsaufgaben abgeleitet werden können. An dieser Stelle möchten wir noch einmal darauf hinweisen, dass wir in diesem Artikel unsere Erfahrungen mit einer für uns passenden Adaption der Eventstorming Methode beschreiben. Zum Beispiel verwenden wir Skizzen für die Visualisierung und spielen aus Benutzersicht Arbeitsabläufe mit dem Programm durch. Diese Methode funktioniert für uns sehr gut und wir möchten unsere Erfahrungen daher mit dir teilen.
Jede Interaktion mit einem Programm kann als Auslöser für ein Event verstanden werden und das Event beschreibt die Änderung, die durch die Interaktion entstanden ist. Ein Event beschreibt Fakten in einem System. Klickst du z.B. in deinem Textverarbeitungsprogramm auf den „speichern“ Button, wird durch die Aktion das Dokument gespeichert und das Event „Textdokument wurde auf Festplatte gespeichert“ dadurch erzeugt. Das Event beschreibt die Änderung des Zustands durch eine Aktion. Das „Textdokument wurde auf Festplatte gespeichert“ Event ist schon sehr konkret. Um es ausführen zu können, brauchst du zum Beispiel einen Button. Aufgrund dieser Änderung können eine Vielzahl von weiter Aktivitäten entstehen, es können Prozesse gestartet und Aktionen ausgeführt werden. Durch das durchspielen von Aktionen und Events bekommst du ein umfangreichen Bild dessen, wie dein Programm verwendet werden könnte. Das klingt jetzt erstmal nicht neu denn es gibt schon länger die Herangehensweise, Anforderungen zu formulieren, beispielsweise als User-Story: „Ich als Nutzer möchte mein Textdokument auf Platte speichern können“. Der Unterschied hierbei ist, dass du jetzt nur die Sicht des Nutzers betrachtest und auch bei dieser Sicht aufhörst. Was ist aber mit dem Softwareentwickler, dem Designer und all den anderen Interessensgruppen, was sollen sie jetzt genau tun? Braucht es ein Interface, einen Button? Im Eventstorming wird ein umfangreicheres Bild für dein Programm gezeichnet und alle Interessensgruppen miteingeschlossen. Eventstorming ist also eine Methode die du gerade dann einsetzen, wenn Menschen mit vielen verschiedenen Ansichten und Expertisen in deinem Workshop zusammenkommen. Und nach deinem Workshop hat jeder die Möglichkeit, seine konkreten Arbeitsaufgaben abzuleiten.
Im Eventstorming werden drei Phasen unterschieden. Im ersten Schritt geht es darum, dass ihr euch einen Überblick erstellt und ihr euch über Menschen und deren Ziele klar werdet. In Phase zwei setzt ihr den Fokus auf Prozesse, Interaktionsmöglichkeiten, Kommandos und ähnliches. Also auf die konkrete Anwendung. Und in der letzten Phase behandelt ihr eher das Systemdesign durch Hinzufügen von Aggregaten und der Ableitung einer Kontextmap (externer link). Die letzte Phase nennen wir nur der Vollständigkeitshalber. Wir nutzen Eventstorming derzeit, um ein tieferes Verständnis für unser Software Design und die Systemlandschaft zu generieren. Für uns ist wichtig ein gemeinsames Verständnis zu schaffen, was wir bereits nach Phase 2 ausreichend für die Weiterarbeit darstellen können. Wir behandeln daher Phase 3 auch nicht in diesem Artikel.
Für jede dieser Phasen werden farblich unterschiedliche Klebezettel verwendet. Als wir das erste Mal Eventstorming durchgeführt haben, brauchten wir eine riesige Wand und hundert Klebezettel. Mittlerweile machen wir Eventstorming online. Dafür gibt es gute Whiteboard Lösungen, in welchen du viele bunte elektronische „Klebezettel“ hast. Eine große Auswahl an Open Source Whiteboards findest du hier. Und wenn du weitere Informationen oder Tools für Eventstorming benötigst, dann wirst du hier fündig.
Für Phase 1 verwenden wir folgende Klebezettelfarben:
Orange für Events, Gelb für Aktoren z.B. Personen und Rosa für externe Systeme. Dabei stellen externe Systeme Bereiche dar, mit denen das zu entwerfende Programm interagiert, was aber nicht Bestandteil des Programms ist z.B. ein externer Cloudspeicher.
Konzentriert euch in dieser Phase darauf, wie ihr euer System verwendet und welche relevante Events sich daraus ableiten. Diese Events schreibt ihr auf die orangenen Klebezettel. Oft entsteht beim Nachdenken über eine Aktion automatisch die nächste und ihr „durchspielt“ so mehrmals euer Programm. Nehmen wir noch einmal das Beispiel mit der Textverarbeitungssoftware und dem Speichern-Befehl. Der Benutzer hat auf den Speichern-Button gedrückt, dadurch öffnet sich die Oberfläche zum Speichern. In Events (orange) ausgedrückt könnte es wie folgt aussehen (Achtung Beispiel enthält Fehler, Auflösung folgt):
Ähnlich dem Brainstorming (link) gilt es auch hier viele Event Ideen zu sammeln. Wir machen Eventstorming allerdings zielgerichtet d.h. Funktionalität, welche wir im ersten Schritt nicht umsetzen wollen, nehmen wir nicht mit auf. Ihr könnt es aber auch so halten wie beim Brainstorming und alle Ideen durchdenken. Dadurch können sich auch Ideen ergeben, welche ihr nicht berücksichtigt hattet und ggf. leicht umzusetzen sind. Aber verzettelt euch nicht, die Übersicht wird schnell sehr groß.
In dieser ersten Phase können auch externe Systeme vorkommen. Wenn ihr z.B. das Textdokument nicht auf die Festplatte, sondern auf einen Onlinespeicher schreiben wollt, ist dieser nicht Teil eueres Systems und wird daher auf einen rosa Zettel geschrieben. Ihr nehmt aber die Events mit auf, die vom externen System an euer System übergeben werden und für euch relevant sind, wie z.B. „Datei wurde durch einen anderen Benutzer gesperrt“.
Wenn ihr alle Funktionsmöglichkeiten eueres Programms durchgedacht habt, dürften sich schon etliche Klebezettel auf eurer (hoffentlich virtuellen) Wand befinden.
In der zweiten Phase verwenden wir grüne Klebezettel für Eingaben bzw. Ansichten. Blaue Klebezettel werden für Kommandos genutzt und lila Klebezettel für Regeln. Das Ziel dieser Phase ist es, die Schritte zu modellieren, die zu einem Event führen. Ihr werdet sehen, dass ihr am Ende eine sehr konkrete Vorstellung von dem Programm, dass ihr entwickeln wollt, haben werdet.
Zieht den Klebezettel für den Benutzer und das folgende Event auseinander. Nach dem Benutzer platziert ihr den grünen Klebezettel. Dort schreibt ihr das Interface auf, dass der Benutzer sieht und mit welchem er interagiert. Uns hilft es das Interface mit den relevanten Interaktionsmöglichkeiten zu skizzieren. Dadurch bekommen alle Teilnehmer sofort eine Vorstellung davon, über was gerade diskutiert wird. In dem Fall der Textdokumentation könnte es wie folgt aussehen.
Wenn euch bei diesem Schritt noch weitere Events einfallen, notiert diese. Es kann auch sein, dass Events obsolet werden, dann entfernt einfach den entsprechenden Klebezettel.
Dem grünen Klebezettel folgt der Blaue. Auf diesem notiert ihr das Kommando, dass zu einem Event führt. In diesem Fall das „speichere Dokument auf Platte“ Kommando.
Die Klebezettel könnten nun wie folgt aussehen:
Wie ihr seht ist das Event „Speicher Button gedrückt“ entfernt worden. Das Drücken des Buttons selbst war noch keine Änderung im Programmsystem, sondern führt vielleicht nur zu einer visuellen Änderung. Wenn ihr mit Phase 2 beginnt werdet ihr sicherlich feststellen, dass sich mehrere solche falschen „Events“ eingeschlichen haben. Mit der Zeit werdet ihr diese falschen Events gleich erkennen und nicht mit aufnehmen. Überlegt euch immer, ob eine Änderung im Programmsystem stattfindet oder nicht.
Ansichten müssen nicht immer Bildschirmfüllend sein. Auch ein Bereich einer Seite wie z.B. ein Warenkorb oder eine Produktseite im Onlineshop kann eine Ansicht im Sinne der grünen Klebezettel sein. Es gibt daher oft eine Vielzahl von Ansichten, die einem Benutzer zugeordnet werden können. Jedes Event benötigt aber immer ein Kommando, dass das Event auslöst und meistens auch eine zugehörigen Ansicht, durch welche das Kommando ausgelöst werden kann. Wir ordnen daher einer Person mehrere grüne, blaue und orange Klebezettel zu, welche wir untereinander anordnen. Durch jedes Event, dass ihr so bearbeitet, kommen weitere Teilansichten, Buttons oder Listen in eurer Oberflächenskizze hinzu. Am Ende habt ihr nicht nur alle Events, Aktionen, Ansichten und Personen, sondern auch eine Skizze eures Programms.
Moment, fehlt nicht noch etwas? Richtig, die lila Klebezettel. Diese stellen Regeln dar. Wenn ihr nun auf Speichern klickt. Wird euch eine Programmregeln daran hindern, zu speichern, wenn das Dokument geschützt ist. Diese Regel schreibt ihr auf einen lila Zettel. Platziert wird dieser zwischen dem Kommando (blauer Zettel) und dem Event (orangener Zettel). Wenn ihr das Kommando ausführen wollt, wird die Regel geprüft und nur wenn die Regel zustimmt, wird das Kommando ausgeführt und das Event erzeugt.
Dann würde sich dies wie folgt darstellen:
Ab und zu modellieren wir ein System auch als „Person“, wenn dieses selbständig Kommandos ausführen kann und sich damit verhält, wie ein normaler Benutzer. Eine Oberfläche benötigt das System in der der Regel nicht. Wenn das der Fall ist, notieren wir das System auf einen gelben Zettel, kleben das dazugehörige Event daneben und dazwischen die jeweilige Aktion (also die Farben Gelb, Blau, Orange). Vorstellen kannst du dir z.B. ein Agentensystem, was andere Systeme überwacht und ggf. eingreift.
Wie bereits angesprochen verzichten wir an dieser Stelle auf Phase 3. Unserer Meinung nach ist das Programm durch die Phasen 1 und 2 bereits ausführlich beschrieben und durch die Skizze der Oberfläche ausreichend detailliert. In folgenden Schritten kann nun jeder Bereich seine Arbeitspakete ableiten. Zur Detailplanung mehr in einem späteren Artikel.
Mia, Peter und Zou haben sich im letzten Artikel mit Brainstorming befasst (link) und daraus alle Funktionen abgeleitet, die sie gerne umsetzen möchten. Heute möchten sie mit Eventstorming ihre Idee konkretisieren, um Arbeitspakete erstellen zu können. Mia hat sich vorab schon ein Whiteboard ausgesucht (link) und verschieden farbige Klebezettel erstellt. Analog zum Brainstorming beginnen die drei Events zu sammeln. Sie benennen Personen und beschreiben externe Systeme. Ein Ausschnitt daraus ist wie folgt.
Sie gruppieren die Events gleich logisch zueinander, dadurch entdecken sie immer mehr Events und eine erste Vorstellung von ihr Videochat entsteht. Nach ca. einer Stunde haben sie alle relevanten Events zusammen, einige externe Systeme identifiziert und Personen beschrieben. Es hat sich ein riesiges Whiteboard ergeben, zum Glück sind die Klebezettel elektronisch leicht zu handhaben. Den Dreien fällt auf, dass je nach Person das gleiche Event ausgeführt werden kann. Als Beispiel kann ein Gast Nutzer eine Videochatanfrage annehmen, ebenso wie ein registrierter Nutzer. Die Events dafür sind identisch und werden daher beiden Personen zugeordnet. Daher haben sie sich dazu entschieden die Events zu duplizieren und den verschiedenen Personen zuzuordnen. Aus dem linearen Ablauf erstellen sie nun eine tabellarische Übersicht, indem sie die virtuellen Klebezettel duplizieren und den unterschiedlichen Personen zuordnen.
Mia, Peter und Zou fühlen sich nun bereit für Phase 2. Sie nehmen sich die erste Spalte vor und listen die Events untereinander auf. Links kleben sie nun den Nutzer und rechts die Events. Dazwischen ist Platz für die grünen, blauen und lila Zettel. Für jedes Event überlegen sie nun, über welche Ansicht die Person welches Kommando ausführt, um das Event auszulösen.
Die Zeit vergeht wie im Flug und schnell ist eine weiter Stunde vergangen. Mia schlägt eine kurze Pause vor. Auch wenn es allen gerade viel Spaß macht, finden sie den Vorschlag gut, denn das konzentrierte Arbeiten ist trotzdem anstrengend. Nach 15 Minuten geht es weiter. Zou hat sich bereit erklärt die Ansichten zu skizzieren, da sie einen elektronischen Stift besitzt. Die Kontaktverwaltung hat schon eine erste Form angenommen.
Mia, Peter und Zou brauchen für alle Events noch mehrere Stunden und viele Pausen. Am Ende haben sie drei Ansichten definiert, die Kontaktverwaltung, die Besprechungsplanung und die Besprechungsdurchführungsansicht. Damit sind sie erstmal zufrieden und beenden das Eventstorming. Da es Mittlerweile schon spät geworden ist, entscheiden sie sich dafür den Workshop für heute zu beenden und den Abschluss des Workshops auf den kommenden Tag zu verlegen.
Wie du einen Workshop richtig abschließt und wie Mia und ihre Freunde damit umgehen, erfährst du im nächsten Artikel.
<< blogs