Was ist Domain Storytelling?
Wer seid ihr und was macht ihr?
Stefan: Wir arbeiten und leben in Hamburg und sind seit fast 14 Jahren Kollegen bei der WPS - Workplace Solutions GmbH (https://www.wps.de/).
Henning: Bei der WPS entwickeln wir “Business-Software, die Spaß macht”, und zwar den Anwendern und uns Entwicklern. Wir haben ein Faible für Software-Architektur, User Experience, Domain-Driven Design (DDD) und Agilität. Zu diesen Themen sind wir auch als Trainer, Coaches und Berater unterwegs.
Stefan: Domain Storytelling passt da super dazu. Die Methode hat, so wie auch die WPS, ihre Wurzeln an der Uni Hamburg. Als wir 2005 unser erstes WPS-Projekt für ein Bundesamt gemacht haben, lernten wir die fachlichen Abläufe anhand von Domain Stories kennen. Auch wenn wir sie damals noch nicht so genannt haben.
Henning: Den Namen hat Stefan der Methode vor 2 Jahren gegeben. Danach haben wir angefangen, auf Konferenzen darüber zu sprechen. Insbesondere die stark wachsende DDD-Community hat Domain Storytelling für sich entdeckt.
Aus der agilen Softwareentwicklung sind vor allem die “User Stories” bekannt. Sie formulieren kurz und in Alltagssprache fachliche Anforderungen. Weiter sind aus dem Requirements Engineering die sogenannten “Use Cases” bekannt, die in einfacher Sprache sämtliche Szenarien einer Anforderung beschreiben. Wie ordnet ihr in diesem Umfeld das Domain Storytelling ein?
Stefan: Zunächst muss ich sagen, dass Domain StoryTELLING wichtiger ist als die Domain Story, die am Ende dabei herauskommt. Domain Storytelling hilft Fachexperten und Entwicklern dabei, eine Konversation über fachliche Abläufe führen. Die fertige Domain Story ist eher als Gedächtnisstütze zu sehen - ein Bild kann aber nicht die Konversation ersetzen, aus der es entstanden ist.
Nehmen wir ein Kino als Beispiel. Wenn wir eine App für den Kartenverkauf entwickeln wollen, müssen wir erst verstehen, wie das Kino heute funktioniert. Dafür brauchen wir aber nicht gleich jeden Sonderfall, nicht jede Eventualität zu berücksichtigen. Für das Verständnis reicht es aus, eine Hand voll konkreter Beispiele als Domain Story zu erzählen, z.B. “Kinokarte an der Kasse kaufen”. Dann können wir uns über Soll-Prozesse unterhalten, also wie die App in die Verkaufsprozesse integriert werden soll. Die Konversation endet nicht, wenn wir die Prozesse als Domain Story visualisiert haben, sondern wir führen sie mit anderen Mitteln fort.
Aus den Domain Stories ergeben sich fast von selbst grobe User Stories und Ideen, die wir als Mock-Ups visualisieren. Anhand derer vertiefen wir die Konversation und gehen in die Details.
Use Cases (nicht zu verwechseln mit Use Case Diagrammen) erzählen ebenfalls eine Geschichte, aber in Textform. Das Haupt-Szenario eines Use Case kann man sich als verschriftlichte Domain Story vorstellen. Man kann Use Cases und Domain Storytelling gut kombinieren: Domain Storytelling als Interviewtechnik, Use Cases zur Dokumentation. Früher haben wir das öfters gemacht, heute arbeiten wir mehr mit User Stories und Mock-Ups.
Klingt sehr vielversprechend. Ich würde es gerne mit euch ausprobieren und ein Storytelling zum Thema “Wie findet ein(e) ITler(in) eine passende Tätigkeit mit Hilfe von Jobpushy.de”. Wie würde das Modell aussehen?
[ Die Antwort auf diese Frage haben Stefan und ich per Skype im direkten Austausch erörtert. Stefan hat während des Gesprächs eine Domain Story aufgezeichnet. Per Screensharing konnte ich sehen, wie das Bild entsteht. Das Interview dauerte ca. 15min. ]
Könnt ihr die grafischen Elemente kurz erklären?
Henning: Wir unterscheiden zwei Arten von Piktogrammen - Akteure und Arbeitsgegenstände (engl. Work Objects) - und eine Art von Pfeil, der Aktivitäten darstellt. Außerdem gibt es textuelle Annotationen. Akteure stoßen Aktivitäten an und können sowohl menschlich (z.B. eine Person oder eine Gruppe) als auch technisch (z.B. ein Softwaresystem) sein.
In dem Beispiel, das Stefan und du modelliert habt, sind der ITler und der Job-Anbieter menschliche Akteure und Jobpushy und “das Web” technische Akteure. Außerdem gibt es zwei textuelle Annotationen, eine an der zweiten und eine an der dritten Aktivität.
Welche Piktogramme wir genau verwenden, hängt von der Domäne ab. Wenn wir z.B. im Bereich Logistik und Hafen unterwegs sind, kann es sinnvoll sein, ein Schiff als Akteur und einen Container als Arbeitsgegenstand zu verwenden. Die Piktogramme sollen eine kompakte, wiedererkennbare Bildsprache ergeben.
Stefan: Wobei wir die Piktogramme nicht nur verwenden, weil sie hübsch aussehen. Ein Arbeitsgegenstand kann im Lauf einer Geschichte durch unterschiedliche Piktogramme visualisiert werden. In dem Beispiel sehen wir z.B. dass ein Angebot als Link per Mail verschickt wird (4) und anschließend das gleiche Angebot auf Jobpushy in Form eines Formulars oder Dokuments bewertet wird (6). Dito beim Bewerbungsformular bei den Aktivitäten 8 und 9.
Im obigen Fall haben wir nur den “Gut-Fall” modelliert. Wie werden die anderen Szenarien betrachtet? Beispielsweise kann der Jobsuchende die vorschlagende Stelle via Knopfdruck ablehnen, wodurch das Jobpushy-System die Vorlieben des Users lernt. Muss für jeden dieser Fälle ein eigene Domain-Story erzählt werden oder sind Fallunterscheidung in der Modellierung möglich?
Stefan: Domain Storytelling verzichtet bewusst auf Fallunterscheidungen. Jede Geschichte behandelt nur einen konkreten Fall. In unserem Beispiel haben wir die Annahme getroffen, dass Jobpushy mindestens ein passendes Angebot findet. Wenn wir im Workshop auf mögliche Varianten treffen, halten wir sie in einer Notiz fest. Später fragen wir die Fachexperten: Ist uns diese Variante eine eigene Domain Story wert? Meist läuft es darauf hinaus, dass wir Varianten gut durch kurze textuelle Annotationen abdecken können, beispielsweise haben wir bei Aktivität 8 (“ITler füllt Bewerbungsformular aus”) festgehalten, dass das auch direkt auf der Webseite des Job-Anbieters passieren kann. Du hast aber gesagt, dass das eher die Ausnahme ist. Man kann sich ganz gut vorstellen, wie das läuft, auch wenn es nicht im Bild ist. Aber wenn wir wirklich einen interessanten Fall haben, der deutlich anders abläuft, verdient er eine eigene Domain Story. Im Fall von Jobpushy würden wir vermutlich auch modellieren, dass ein Jobsuchender die Stelle ablehnt. Letzten Endes kommt es immer auf den Zweck an, wofür man modelliert. Meist beginnen wir beim “Happy Path” und schauen uns dann noch wichtige Varianten und Fehlerfälle an.
Im Regelfall reicht ja ein Whiteboard oder Flipchart aus, um eine Domain Story festzuhalten. Ihr habt ein Tool entwickelt, welches die Modellierung online erlaubt. Sehr hilfreich für Leute, die digital arbeiten wie z.B. für das Skype-Interview mit Stefan. Wie funktioniert es und was kostet die Nutzung?
Stefan: Wir haben den Modeler entwickelt, weil wir gemerkt haben, dass man mit analogen Werkzeugen schnell an Grenzen stößt, nicht nur wenn man mal remote modellieren will. Am Whiteboard zusammen zu modellieren macht zwar Spaß, aber wenn man zwei, drei Domain Stories hintereinander aufzeichnen und vielleicht sogar vergleichen möchte, hat man schnell Platzprobleme. Generische Modellierungswerkzeuge wie Glyphy und yEd fühlen sich irgendwie zu sperrig an. Also haben wir im Sommer ausprobiert, ob wir eine bessere Lösung finden. Heraus kam der Modeler. Die Software ist open source (https://github.com/WPS/domain-story-modeler), basiert auf dem BPMN-Modeler von Camunda und läuft als Webanwendung im Browser (auch offline). Wie man den Modeler nutzt, steht in der readme.md auf GitHub. Wer den Modeler ausprobieren möchte, ohne irgendwas herunterzuladen, kann das auf http://wps.de/modeler tun. Damit erstellte Domain Stories können als JSON-Datei (mit der Dateiendung .dst) oder SVG gespeichert werden. Das Beispiel, das oben als Bild zu sehen war, kann man hier als .dst-Datei herunterladen und dann in den Modeler importieren. Ich empfehle, die “Replay”-Funktion zu nutzen, um die Story Satz für Satz zu visualisieren.
Henning: Wenn man Software zum Modellieren verwendet, darf man eines nicht vergessen: Alle Teilnehmer des Workshops müssen die Domain Story ständig vor Augen haben - also einen Beamer bzw. Screen Sharing verwenden! Nur so können alle Feedback geben, ob sie richtig verstanden wurden. Und: Der “Modeler” ist nur eine Möglichkeit von vielen. Ich bin auch ein großer Fan von Smartboards wie dem Surface Hub.
Wo kann man euch im Netz folgen? Wo können weitere Informationen zum Domain Storytelling gefunden werden? Gibt es ein Buch (bzw. kann man eures vorbestellen?)
Henning: Wir sind auf Twitter als @hofstef und @hschwentner unterwegs. Natürlich hat Domain Storytelling auch eine eigene Webseite (www.domainstorytelling.org) und einen Twitter Hashtag: #DomainStorytelling
Außerdem sind wir und weitere Kollegen der WPS auf Konferenzen und Meetups präsent, besonders zu den Themen Software-Architektur und Domain-Driven Design. Am 29.01.2019 geben wir in Amsterdam einen 1-Tages-Workshop im Rahmen der DDD Europe (https://training.dddeurope.com/domain-storytelling-stefan-hofer-henning-schwentner/). Das ist die Konferenz für Domain-Driven Design und selbst dann eine Reise wert, wenn man nicht in unseren Workshop kommt.
Stefan: Und wir schreiben ein Buch über Domain Storytelling. Bis das rauskommt, wird es aber noch eine Weile dauern. Ein Grund mehr, zu unseren Workshops und Vorträgen zu kommen. Ein paar davon findet man übrigens auf Youtube. Einfach nach Domain Storytelling suchen.
