Wir zeigen, warum man Collaborative Modeling (CoMo) braucht, und beschreiben den gemeinsamen Kern verschiedener CoMo-Methoden. Vier solche Methoden stellen wir vor und geben Handlungsanleitungen: Welches Problem lässt sich mit welcher Methode anpacken und wie kombiniere ich Methoden sinnvoll in einem agilen Entwicklungsprozess?

Gemeinsam mit allen Beteiligten Anwendungssoftware zu entwickeln – das charakterisiert agile Softwareentwicklung im Allgemeinen und Methoden der Softwareentwicklung wie Domain-driven Design (DDD) und Behaviour-driven Design (BDD) im Besonderen. Es ist ein großer Schritt in die richtige Richtung, verglichen mit dem früher üblichen „Über-den-Zaun-werfen“ von Spezifikationsdokumenten. Doch im konkreten Projekt benötigen wir zusätzlich zu Agile und DDD noch Techniken, um das fachliche Verständnis unter den Beteiligten einfach und schnell zu erreichen und festzuhalten. Diese Vorgehensweisen mit den dahinterstehenden Ideen und Konzepte fassen wir unter dem Etikett Collaborative Modeling zusammen.

Weshalb Collaborative Modeling?

CoMo steht hinter vielen erfolgreichen Methoden, die traditionell unter „Anforderungsermittlung“ fallen würden. Denn die IT-Experten müssen die Domäne, also die Aufgaben und Arbeitsabläufe der AnwenderInnen, verstehen, um eine gute Anwendung entwickeln zu können. Umgekehrt sollen Fachexperten und Anwender verstehen, welche Möglichkeiten durch Software geschaffen werden und welche Auswirkungen die Digitalisierung auf ihre tägliche Arbeit haben wird. Entwickler und Fachexperten benötigen eine gemeinsame Sprache, um über die Domäne und die daraus erwachsenden Anforderungen an die Software sprechen zu können. Nur so wird die Software das widerspiegeln, was die Entwickler von den Anforderungen aus der Domäne verstanden haben und was Anwender und Fachexperten von einer Digitalisierung der fachlichen Prozesse erwarten. CoMo soll das Fachwissen aus den Köpfen der Anwender in die Köpfe von Entwicklern, Testern, Product Owners, Produktmanagern, Businessanalysten etc. transportieren – also zu jedem, der an der Softwareentwicklung beteiligt ist. Entscheidend ist hier die direkte Rückkopplung zwischen allen Beteiligten. Das unterscheidet CoMo-Ansätze z. B. von einer klassischen Requirements-Technik, bei der Interviews geführt und daraus Szenarien abgeleitet werden.

CoMo hat einen hohen Stellenwert im Domain-driven Design, der wohl aktuell erfolgreichsten Methode, die die Fachlichkeit ins Zentrum der Softwareentwicklung stellt. Fachsprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne bilden das sogenannte Domänenmodell, das die Entwickler in der Software abbilden. Ein valides Domänenmodell lässt sich nur gemeinsam von Entwicklern und Fachexperten erstellen. DDD-Experten wie Paul Rayner sehen CoMo mittlerweile als eine Säule des DDD an (Abb. 1). In diesem Artikel charakterisieren wir CoMo und stellen einige wichtige darin enthaltene Ansätze vor, mit denen sich die verschiedenen Aspekte eines Domänenmodells gemeinschaftlich erarbeiten lassen.

Grundlegende Konzepte des CoMo

Die verschiedenen Techniken des CoMo verbindet folgende gemeinsame Konzepte:

• Gruppenarbeit aller Beteiligten: Grundlegend ist, dass die verschiedenen Beteiligten auf Anwender- und Entwicklerseite gemeinsam Arbeitsprozesse und Anforderungen klären und nicht einzelne Spezialisten auf der Basis von Interviews und Dokumentanalysen diese Themen spezifizieren. Alle Ansätze sehen gemeinsame Workshops vor, manchmal in großen Gruppen, manchmal mit wenigen Vertreter der jeweiligen Gruppen.

• Geschichten erzählen: In den Workshops kommunizieren die Beteiligten nicht über abstrakte Beschreibungen, sondern mittels konkreter Szenarien. Diese werden wie Geschichten erzählt. Aus dem fundierten Verständnis der Szenarien werden dann die für die Softwareentwicklung nötigen Abstraktionen und eine vollständige Abbildung von Regeln und Fallunterscheidungen aufgebaut.

• Über eine gemeinsame Sprache ein wechselseitiges Verständnis aller Beteiligter anstreben: Oft wird beklagt, dass die Fachabteilungen und die IT in ihren eigenen Welten leben und aneinander vorbeireden. Alle CoMo-Ansätze stellen daher die Sprache der Anwender in den Vordergrund; die verschiedenen Workshoptechniken sollen helfen, dass sich die Beteiligten besser verstehen.

• Gemeinsame Modelle des Anwendungsbereichs erstellen: Unsere Erfahrungen mit CoMo zeigen, dass die gemeinsame Arbeit ein gegenständliches Ergebnis haben sollte. Die verschiedenen Modelle aus Zeichnungen, Karteikarten oder Post-its sind mehr als ein Nebenprodukt. Sie zeigen allen Beteiligten den Stand der Diskussion, geben durch ihre grafische Darstellung eine neue Sicht auf das Thema und markieren am Ende eines Workshops ein handfestes Ergebnis, das oft in der weiteren Arbeit genutzt werden kann.

CoMo-Ansätze

Sehen wir uns nun kurz einige ausgewählte Ansätze des CoMo an, die aktuell in der Praxis erfolgreich eingesetzt werden. Diese Auswahl ist nicht vollständig und orientiert sich an unserer persönlichen Erfahrung. Außerdem sind die Ansätze so gut im Internet beschrieben, dass Sie sich dort als Leser leicht ein eigenes Bild machen können.

Event Storming

Beim Event Storming [2] erarbeiten sich Entwickler und Fachleute aus verschiedenen Bereichen mit Hilfe von Klebezetteln (Stickies) und Stiften ein Bild komplexer Geschäftsprozesse. Das Bild entsteht bottom-up aus einer Folge von fachlichen Ereignissen (sogenannte Domain Events), die eine konkrete Ausprägung des zu modellierenden Geschäftsprozesses beschreiben. Die Stickies erzählen also eine Geschichte. So werden Inkonsistenzen und Reibungspunkte zuverlässig entdeckt. Das Bild ist die Repräsentation des kollektiven Verständnisses der Domäne und ein guter Ausgangspunkt für Design und Implementierung nach DDD.

Namensgebend für Event Storming ist, dass im Workshop zunächst alle Teilnehmer (wie im Brain Storming) unkoordiniert herausstürmen, was in der Domäne passiert. Dazu schreiben sie, ohne sich abzusprechen, Domain Events auf orangefarbene Stickies und kleben sie auf eine Wand (Abb. 2). Je nach Ziel des Workshops werden schrittweise weitere Farben eingeführt, z. B. pink für Hot Spots (Probleme, Konflikte, Fragen) und lila für Policies (Geschäftsregeln).

Domain Storytelling

Domain Storytelling hat sich über Jahre als graphische Modellierungsmethode von Aufgaben und Geschäftsprozessen entwickelt [3]. Die Methode nutzt eine einfache Bildsprache, um Geschichten über den Anwendungsbereich zu erzählen und zu dokumentieren (Abb. 3). In gemeinsamen Workshops von Vertretern der Fachabteilung und des Entwicklungsteams unter Leitung eines Moderators werden Geschichten über ausgewählte Geschäftsprozesse erzählt und in Bildern festgehalten. Normalerweise reichen wenige Domain Stories aus, um einen Geschäftsprozess zu verstehen.

Domain Storytelling funktioniert auch für das Design von neuen, softwaregestützten Prozessen. Veränderungen zwischen Ist- und Sollprozessen lassen sich damit anschaulich darstellen.

User Story Mapping

User Story Mapping [4] kommt aus der agilen Community. Eine User Story Map strukturiert Anforderungen (grob festgehalten als User Stories) in einer zusammenhängenden Geschichte aus Sicht der Benutzer der zu entwickelnden Anwendung. Kurze Sätze aus der Interaktion mit der Software werden aus Benutzersicht mit Stickies in eine zeitliche Abfolge gebracht (die horizontale Dimension der Map). In der vertikalen Dimension werden User Stories auf die Zeitachse „gemappt“ (Abb. 4).

Story Mapping wird häufig in drei Phasen unterteilt, in denen verschiedene Aspekte mit unterschiedlichen Personen erarbeitet werden: Produktfindung, Versionsstrategie und Backlog Grooming.

Example Mapping

Auch beim Example Mapping [5] sind User Stories der Ausgangspunkt, um den Problembereich genauer zu verstehen. Anhand von Beispielen sollen vor allem Vertreter der Fachabteilung, Entwickler und Tester die fachlichen Regeln oder Randbedingungen einer User Story identifizieren, um daraus Akzeptanztests abzuleiten. User Stories, Regeln mit Beispielen und offene Fragen werden jeweils auf verschiedenfarbigen Karten notiert (Abb. 5).

Example Mapping wird oft zu Beginn eines Sprints genutzt, um User Stories auf eine implementierbare Größe zu reduzieren und offene Fragen zu identifizieren.

Unterschiede der CoMo-Ansätze

Die gemeinsamen Konzepte der verschiedenen Ansätze haben wir schon herausgearbeitet. Für den praktischen Einstieg in das Collaborative Modeling geben wir jetzt eine kleine „Gebrauchsanweisung“ für die Auswahl der passenden Methode. Dafür gehen wir auf die Unterschiede der Ansätze ein. In Tabelle 1 betrachten wir folgende Aspekte:

• Zielsetzung, d. h. wozu ist der Ansatz gut?

• Welcher Gegenstandsbereich wird betrachtet?

• Welche Elemente werden bei der Modellierung verwendet?

• Welche Ergebnisse (Modelle, Gegenstände, Artefakte) werden bei der CoMo erzeugt?

• Welche Aktivitäten im Entwicklungsprozess werden durch den Ansatz unterstützt?

• Welche Verbindungen zu anderen Entwicklungsmethoden und Modellierungsansätzen bestehen?

Eine solch kompakte Übersicht ist zwangsläufig vereinfachend und nicht ganz trennscharf. Außerdem decken die Ansätze eine Bandreite von Einsatzzwecken ab und können mit etwas Erfahrung flexibel an die eigenen Gegebenheiten angepasst werden.

Die Verbindungen zu anderen Methoden haben wir in Abbildung 6 grafisch als eine Art Wegweiser durch die CoMo-Landschaft aufbereitet.

Abschließend geben wir noch einige persönliche Erfahrungen weiter, anhand derer wir abwägen, welche Methode wir wann einsetzen.

Event Storming

Event Storming spielt seine Stärken in der fachlichen Prozessmodellierung dann aus, wenn

• der Anwendungsbereich schwach strukturiert ist,

• wenn die Domäne von zeitlichen Abläufen und Statuswechseln geprägt ist

• oder schon vorab klar ist, dass es wenig gemeinsame Sichtweisen und Ziele, aber viel Konfliktpotenzial gibt.

Die Ergebnisse der Prozessmodellierung können durch zusätzliche Notationselemente in kleineren Workshops zu einem Softwaredesign ausgearbeitet werden. Eine solche Modellierung passt gut, wenn Software nach DDD gebaut werden soll.

Domain Storytelling

Domain Storytelling nutzen wir gerne, wenn

• wir kooperative Prozesse betrachten und dadurch verstehen wollen, wie menschliche (und technische) Akteure zusammenarbeiten,

• wir softwaregestützte Sollprozesse entwerfen und dann über den Weg vom Ist zum Soll diskutieren,

• wir funktionale Anforderungen an die Prozessunterstützung ableiten wollen

• oder Prozesse dokumentiert werden müssen.

User Story Mapping

User Story Mapping setzen wir dann ein, wenn die Sollprozesse bereits eine gewisse Reife haben und die daraus abgeleiteten Anforderungen in ein Backlog überführt werden. Die User Story Map wird zum Planungsinstrument für cross-functional Scrum-Teams, um

• mit einem Product Owner über Prioritäten und Inkremente zu sprechen,

• den fachlichen Kontext einer User Story nicht aus den Augen zu verlieren

• und um zu veranschaulichen, welche Anforderungen als nächstens detailliert ausgearbeitet werden müssen.

Example Mapping

Mit Example Mapping arbeiten wir weiter an den Zwischenergebnissen der anderen Methoden, um

• die im Event Storming oder Domain Storytelling identifizierten Stellschrauben für Prozessvarianten (meist sind das Geschäftsregeln) zu analysieren,

• Anforderungen auf ein implementierbares Niveau zu detaillieren

• oder wenn bei der Planung klar wird, dass Anforderungen kleiner geschnitten werden müssen.

Wo finde ich mehr zu Collaborative Modeling?

Die internationale CoMo-Community, meist Vertreter der DDD- und BDD-Szenen, schreibt gerade ein Buch über Collaborative Modeling. Darin werden viele Methoden vorgestellt, ihre Einsatzzwecke erläutert und gezeigt, wie man Methoden miteinander kombinieren kann [6]. Ein ähnliches Projekt ist die Open Practice Library [7]. Sie enthält nützliche Methoden für die Softwareentwicklung und einige CoMo-Methoden.

Wenn wir Sie für DDD interessieren konnten, empfehlen wir Ihnen als ersten Einstieg das Buch „Domain-Driven Design kompakt“ [8].

Danksagung: Wir bedanken uns bei Martin Schimak für das Foto von Paul Rayners „Säulen des DDD“.