This article is also available in English

In diversen Communities haben sich in den letzten Jahren zahlreiche Methoden zur kollaborativen Modellierung von fachlichen Anforderungen etabliert. Bekannte Beispiele hierfür sind EventStorming oder Domain Storytelling. Diese Ansätze setzen darauf, dass wir skillübergreifend ein besseres gemeinsames Verständnis über die Fachlichkeit erlangen. Was ist aber mit den Anforderungen an die Qualität der zu erstellenden Software? Gerade hier ist eine kollaborative Vorgehensweise immens wichtig, um nicht perfekten Idealvorstellungen hinterherzulaufen, die Kosten und Komplexität von Produkten explodieren lassen. An dieser Stelle setzt das Workshop-Format Quality Storming an, welches ich im Laufe dieses Artikels vorstellen möchte.

Es kommt drauf an! Auf was?

In unserer Arbeit als Consultants erleben wir immer wieder Situationen, in denen Teams mit viel Leidenschaft über Vor- und Nachteile bestimmter Lösungsoptionen diskutieren. Populär sind bei diesen Diskussionen technische Themen, wie zum Beispiel HTTP Feeds vs. Apache Kafka. Allerdings kommen solche Diskussionen auch immer häufiger bei fachlichen Schnitten von Software zum Vorschein. Eine beliebte Antwort auf die Frage “welche Lösung ist die Beste” lautet dann häufig “es kommt drauf an”. Diese Antwort deutet darauf hin, dass wir es hier mit einer Entscheidung zu tun haben, die eine Abwägung impliziert. Es stellt sich somit automatisch die zweite Frage “auf was kommt es an”. Mögliche Faktoren können dabei sein:

Die ersten drei Treiber für solche Entscheidungen werden in den meisten Organisationen mehr oder minder sehr ernst genommen. Beim letzten Punkt stelle ich jedoch regelmäßig fest, dass es hier den meisten Teams an belastbaren Anforderungen mangelt. Meist sind diese so vage definiert, dass man sie nicht als Basis für eine Entscheidungsfindung nutzen kann. Typische Beispiele hierfür sind “das System muss skalierbar sein”, “es müssen alle gängigen Browser unterstützt werden” oder “alle Eingaben müssen immer überall sofort sichtbar sein”. Selbstredend haben sich im Laufe der Zeit Best Practices etabliert, die Vorschläge machen, wie die Anforderungen an die Qualität eines Software Produkts idealerweise dokumentiert werden sollen. Ein Beispiel hierfür ist die Formulierung in Form von Qualitätsszenarien, die auch im ATAM-Prozess (Architecture Tradeoff Analysis Method) [1] zur Bewertung von Softwarearchitekturen verwendet werden. Im ATAM-Prozess gibt es zwei Schritte, welche die Definition von Qualitätsanforderungen an eine Softwarearchitektur adressieren: “5. Generate quality attribute utility tree” und “7. Brainstorm and prioritize scenarios”. Es stellt sich somit die Frage, wie wir im Team zu diesen Anforderungen kommen. An dieser Stelle gibt es immer wieder ähnliche Herausforderungen in zahlreichen Organisationen:

Die Folge davon sind zu oberflächliche Qualitätsanforderungen, die primär dazu dienen interne Governance Checklisten zu erfüllen. Echte Design-Entscheidungen können Software-Architekt*innen und Entwickler*innen auf dieser Basis selten treffen.

Somit trifft auch im Hinblick auf die Qualitätsanforderungen das folgende Zitat von Alberto Brandolini voll zu:

it is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production

Alberto BrandoliniErfinder EventStorming

Quality Storming: Collaborative Modeling für Qualitätsanforderungen

Das eben genannte Zitat war nicht zufällig gewählt. Alberto Brandolini ist der Erfinder einer kollaborativen Modellierungsmethode namens EventStorming [2], die in der Domain-driven Design Community für viel Aufsehen gesorgt hat und inzwischen weit über diese Community hinaus bekannt ist. EventStorming basiert, wie die meisten Methoden im Umfeld des Collaborative Modeling, auf folgenden Prinzipien:

Motivation

An dieser Stelle setzt auch Quality Storming an, indem versucht wird eine möglichst heterogene Menge an Stakeholdern eines Produkts oder Projekts zusammenzubringen um Qualitätsanforderungen zu sammeln. Das Ziel ist es, ein gemeinsames Verständnis über die wirklichen Anforderungen an die Qualitätsmerkmale eines Produkts zu erlangen. Um dieses Ziel zu erreichen, nutzt Quality Storming einige Techniken aus dem vielbeachteten Buch “Game Storming” von Dave Gray [3], welches auch einen erheblichen Einfluss auf EventStorming hatte.

Es ist nicht der Anspruch, perfekt ausformulierte Qualitätsszenarien mit Hilfe von Quality Storming zu produzieren. Die Methode zielt eher darauf ab, eine fundierte, priorisierte und vor allem über unterschiedliche Stakeholder-Gruppen hinweg verstandene Basis für eine spätere Formalisierung zu schaffen. Je öfter Teams mit der Methode arbeiten, desto besser wird im Laufe der Zeit die Qualität dieser Basis. Fortgeschrittene Teams sind durchaus in der Lage sehr gut formulierte Szenarien im Rahmen eines solchen Workshops zu kreieren.

Vorbereitung

Wie bei vielen anderen Methoden im Bereich des Collaborative Modeling ist eine zielgerichtete Vorbereitung eine nicht zu unterschätzende Basis für den Erfolg des eigentlichen Workshops. Hierbei sind folgende Aspekte zu berücksichtigen:

Das Wichtigste ist sicherlich die Auswahl der Teilnehmer*innen. Hierbei ist strikt darauf zu achten, dass eine möglichst heterogene und diverse Gruppe an Personen ausgewählt wird. Alle relevanten Stakeholder eines Produkts oder Projekts sollten präsent sein, um ein ganzheitliches Meinungsbild zu bekommen und, um vor allem eine Verbindlichkeit für die Ergebnisse zu erzielen. Nichts wäre fataler, als dass eine einflussreiche Gruppe nicht teilnimmt und nach einer Woche das Gesamtergebnis in Frage stellt. Denken Sie bei der Auswahl des Kreises der Teilnehmer*innen beispielsweise an folgende Personengruppen:

Ideal sind erfahrungsgemäß 16 oder 24 Personen, vor allem wenn man mit dem weit verbreiteten ISO/IEC 25010 Qualitätsmodell arbeitet. Hierzu werde ich weiter unten noch ein paar Anmerkungen hinterlassen.

Bei der Einladung der Teilnehmer*innen ist darauf zu achten, dass keine falsche Erwartungshaltung geschürt wird. Es ist wichtig zu betonen, dass am Ende des Workshops eine verbindliche Basis für die Qualitätsanforderungen steht. Die Empfänger*innen der Einladung sollten verstehen, dass auf Basis der erarbeiteten Ergebnisse künftig Design-Entscheidungen in den Bereichen Software-Entwicklung und -Architektur, User Experience und Betrieb getroffen werden. Allerdings darf nicht der Eindruck entstehen, dass am Ende eines Quality Stormings ein perfekt ausformuliertes Dokument oder ein formell perfekter Qualitätsbaum steht. Die Erstellung solcher Artefakte geschieht bedarfsorientiert im Nachgang. Achten Sie darauf, dass die Teilnehmer*innen des Workshops ca. 4 bis 6 Stunden anwesend sind. Die eingeladenen Personen sollten die Zeit exklusiv für die Anwesenheit einplanen, eine Telefonkonferenz oder ein Meeting zwischendurch sind kontraproduktiv und stören den Ablauf unnötig.

Bereits während der Vorbereitung sollte man sich als Organisator*in eines Quality Stormings Gedanken über die Auswahl eines Qualitätsmodells machen. Ein Qualitätsmodell kann man, salopp formuliert, als Grobgliederung für einen Qualitätsbaum bezeichnen. Letzteren kann man einfach in Form einer Mindmap aufzeichnen.

In einigen Unternehmen liegt ein solches Modell für die Beschreibung von Software-Qualitätsanforderungen bereits vor. In diesem Fall ist es natürlich eine sehr gute Ausgangsbasis und es ist zu empfehlen, damit zu beginnen. Existiert noch kein Qualitätsmodell besteht glücklicherweise kein Anlass sich ein eigenes einfallen zu lassen, denn es gibt mit ISO/IEC 25010 einen standardisierten Vorschlag für ein Qualitätsmodell.

ISO/IEC 25010 als Qualitätsmodell
ISO/IEC 25010 als Qualitätsmodell

ISO 25010 sieht in Summe acht Oberkategorien vor: Übertragbarkeit, Funktionalität, Effizienz, Kompatibilität, Benutzbarkeit, Sicherheit, Wartbarkeit und Zuverlässigkeit. Diese Kategorien haben wie in Abbildung 2 gezeigt wiederum Unterpunkte.

Die Auswahl des Qualitätsmodells ist deshalb wichtig, weil sie einen Einfluss auf die Menge der Teilnehmer*innen haben sollte. Ich präferiere immer folgende Formel für die Bestimmung der perfekten Personenanzahl: Menge der Oberkategorien des Qualitätsmodells x 2 oder 3. Im Falle von ISO 25010 wären wir bei 16 oder 24 Personen, beide Zahlen hatte ich bereits weiter oben mit Verweis auf diesen Absatz erwähnt.

Bei der Raumauswahl sind Räumlichkeiten zu präferieren, die entweder keine oder bewegliche Tische haben. Klassische Meeting-Räume mit verkabelten Tischen sind eher kontraproduktiv. Der Raum sollte groß genug für die vorhin bestimmte Anzahl der teilnehmenden Personen plus 1–2 Facilitators sein und bei der Platzierung von zwei Flipcharts und bis zu acht beweglichen Pinnwänden noch ausreichend Bewegungsfreiheit für die Teilnehmer*innen bieten. Sind nicht ausreichend bewegliche Pinnwände verfügbar, sollte der Raum zwei möglichst lange, freie Wände aufweisen, auf die man Plotterpapier kleben kann.

Die letzte vorbereitende Maßnahme ist die Organisation der Raumausstattung, des Moderationsmaterials und der groben Dokumentation des Qualitätsmodells. Idealerweise sollte der Raum wie folgt ausgestattet sein:

Im Hinblick auf das Moderationsmaterial hat sich folgende Ausstattung bewährt:

Abschließend empfehle ich noch die Vorbereitung von Schildern für die Ober- und Unterkategorien des zugrundeliegenden Qualitätsmodells. Für die Oberkategorien nutze ich gerne DIN A4 und für die Unterkategorien DIN A5 als Format. Jedes Schild enthält den Namen der Kategorie in großer, gut lesbarer Schrift und eine kurze Beschreibung der jeweiligen Kategorie. Bitte achten Sie bei der Beschreibung der Kategorien auf eine Wortwahl, die wirklich jede Person im Raum verstehen kann. Zudem empfehle ich die Formulierung ein paar einfacher Beispiele für die jeweiligen Kategorien. Eine ausführliche Sammlung solcher Beispiele findet man in einem Subprojekt von arc42 auf GitHub.

Kurz vor dem eigentlichen Workshop muss der Raum noch vorbereitet werden. Jede der Oberkategorien des Qualitätsmodells bekommt eine eigene Pinnwand. Diese wird wie folgt präpariert:

Vorbereitung einer Pinnwand für eine Oberkategorie des Qualitätsmodells
Vorbereitung einer Pinnwand für eine Oberkategorie des Qualitätsmodells

Oben wird die Oberkategorie samt einer kurzen Beschreibung platziert und seitlich links werden die Unterkategorien des Qualitätsmodells vertikal nach unten aufgereiht. Vor allem bei den Unterkategorien ist es ratsam auf gute Beschreibungen zu achten. Weiterhin ist es vor allem bei den ersten Durchführungen eines Quality Storming Workshops zu empfehlen für jede Unterkategorie ein oder zwei Beispiele für Qualitätsanforderungen oder -szenarien zu platzieren. Die in Abbildung 3 verwendeten Farben sind nicht als verbindlicher Farbcode zu verstehen.

Im Anschluss werden die mobilen Pinnwände gleichmäßig im Raum platziert. Bitte achten Sie darauf, dass bis zu sechs Personen an den Pinnwänden stehen und diskutieren können. Zudem sollten mittig im Raum zwei Flipcharts und idealerweise Stehtische mit Moderationsmaterial platziert werden. Das Raum-Setup sollte in etwa wie folgt aussehen:

Vorbereitung des Raums für das Quality Storming
Vorbereitung des Raums für das Quality Storming

Durchführung

Ist der Raum fertig vorbereitet, kann es an die eigentliche Durchführung des Workshops gehen. Ein Quality Storming besteht aus den folgenden Phasen:

  1. Einleitung und Einführung
  2. Sammlung in der Breite
  3. Konsolidierung
  4. Priorisierung
  5. Ausblick
Phase 1: Einleitung und Einführung

Diese Phase kann in der Regel sehr kurz ausfallen und sollte nicht länger als 10 - 15 Minuten in Anspruch nehmen. Wichtig ist, dass von Seiten der Workshop-Facilitation noch einmal kurz die Motivation und der grobe Ablauf skizziert werden. In der Regel stelle ich dort auch noch einmal kurz das zugrundeliegende Qualitätsmodell vor und liefere ein paar praktische Beispiele für mögliche Qualitätsanforderungen. Insbesondere Teams, die ein Quality Storming zum ersten Mal durchführen, profitieren von der eben erwähnten Vorstellung samt Beispielen ungemein. Achten Sie als Facilitator darauf, dass die teilnehmenden Personen eine grobe Vorstellung davon haben, wie man Qualitätsanforderungen formuliert und welche Aspekte dabei zu beachten sind. Weiterhin sollten sie als Facilitator noch kurz einen Code Of Conduct vorstellen. In diesem Rahmen verweise ich beispielsweise auf erbetene und nicht erbetene Verhaltensweisen.

Stellen Sie als Facilitator sicher, dass Sie folgende Punkte adressiert haben:

Phase 2: Sammlung in der Breite

Nach der Einleitung findet das erste Teambuilding für die Sammlung in der Breite statt. Je nach der Anzahl der Teilnehmer*innen und der Anzahl der Oberkategorien des Qualitätsmodells sollte man 2er oder 3er Gruppen bilden. Bitte achten Sie darauf, dass die Personen in den einzelnen Teams zu unterschiedlichen Stakeholder-Gruppen gehören. Es ist zu vermeiden, dass sich beispielsweise zwei Software-Entwickler*innen zu einem Team zusammenfinden. Die Teams werden schlussendlich so aufgeteilt sein, dass an jeder Pinnwand eine heterogene Gruppe von zwei bis drei Personen steht.

Nach dem Teambuilding geht es an die Sammlung von Qualitätsanforderungen. Jedes Team steht an einer Pinnwand, die eine Oberkategorie des Qualitätsmodells repräsentiert. Es gilt im ersten Schritt, Anforderungen in der Breite für diese Oberkategorie zu sammeln. Die Teams sammeln Ideen, schreiben diese auf die bereitgelegten Haftnotizen und kleben diese zu den jeweiligen Unterkategorien auf die Pinnwand.

Sammlung von Anforderungen in Phase 2
Sammlung von Anforderungen in Phase 2

Nach zehn Minuten ist es Zeit für die Zweier- bzw. Dreiergruppen, die Oberkategorie des Qualitätsmodells und somit auch die Pinnwand zu wechseln. Nach dem Wechsel werden wieder zehn Minuten lang Anforderungen gesammelt, auf Haftnotizen geschrieben und an die Pinnwand geklebt. Diesen Prozess wiederholen wir so lange, bis jede Gruppe an der Reihe war. So stellen wird sichergestellt, dass jede anwesende Person die Gelegenheit hatte zu jeder Oberkategorie Anforderungen zu stellen. Des Weiteren kann auf diesem Wege eine Vielzahl von möglichen Anforderungen gesammelt werden. Die Facilitatoren des Workshops sollten zudem mehrfach betonen, dass es absolut in Ordnung ist widersprüchliche Anforderungen an die Qualität der Software zu stellen. In dieser frühen Phase wollen wir explizit unterschiedliche Auffassungen dokumentieren. Um zu einem Konsens zu kommen ist es anfangs wichtig zu verstehen an welchen Stellen unterschiedliche Meinungen wie stark differieren.

Die folgende Grafik stellt noch einmal das Rotationsmodell der zweiten Phase dar:

Team-Rotation in Phase 2
Team-Rotation in Phase 2

Zum Ende der zweiten Phase haben sich alle Teilnehmer*innen eine ausführliche (20 - 30 Minuten) Pause verdient. Der Workshop sollte inzwischen ca. zwei Stunden gedauert haben. Während der Pause bereiten die Facilitatoren die dritte Phase vor.

Phase 3: Konsolidierung

Die eben erwähnte Vorbereitung der dritten Phase besteht in der Identifikation von doppelten oder konkurrierenden Qualitätskriterien. Echte Duplikate werden von den Facilitatoren von den Pinnwänden genommen und zur Seite gelegt bzw. an den Rahmen der jeweiligen Pinnwand geklebt. Konkurrierende Qualitätskriterien werden zusammen gruppiert. Unter einem konkurrierenden Kriterium versteht man unterschiedliche Anforderungen an den identischen Sachverhalt. Anbei ein Beispiel:

All diese Anforderungen beziehen sich auf den identischen Sachverhalt, die geforderte Anzahl von Berechnungen des Beleihungswerts einer Immobilie. Allerdings unterscheiden sich die geforderten Mengengerüste. All diese Haftnotizen werden wie folgt dargestellt gruppiert:

Übergang von Phase 2 auf Phase 3
Übergang von Phase 2 auf Phase 3

Wenn die Teilnehmer*innen aus der Pause zurückkommen, werden neue Gruppen gebildet, die größer sind. Idealerweise sollten die neuen Teams aus vier bis sechs Personen bestehen. Auch hier ist, wie bei der Gruppenbildung in Phase 2, darauf zu achten, dass möglichst heterogene Teams im Hinblick auf die Stakeholder entstehen. Bei acht Pinnwänden für die Oberkategorien des Qualitätsmodells sind beispielsweise vier Gruppen ideal.

Nach der Gruppenbildung geht es an die eigentliche Konsolidierung der bisher identifizierten und von den Facilitatoren gruppierten Qualitätsanforderungen. Jeder Vierer- bzw. Sechsergruppe positioniert sich an einer Pinnwand und diskutiert dort die gruppierten, konkurrierenden Anforderungen mit dem Ziel eine Entscheidung bzw. einen Kompromiss zu finden. Hierbei kann es sich um eine bereits an der Wand klebende Anforderung handeln oder um einen Mittelweg aus den bestehenden Anforderungen. Es ist allerdings in jedem Fall empfehlenswert, die getroffene Entscheidung zu markieren. Dies kann beispielsweise durch eine neue Haftnotiz in einer anderen Farbe oder durch das Markieren mit einem anderen, kleineren Post-It geschehen.

Auswahl von Qualitätsanforderungen in Phase 3
Auswahl von Qualitätsanforderungen in Phase 3

Erfahrungsgemäß benötigt jede Gruppe ca. 15 - 20 Minuten für die Konsolidierung der Ergebnisse. Nach dieser Zeit zieht jedes Team zur nächsten Pinnwand weiter und beginnt von vorne mit der Konsolidierung. In der Regel reicht es aus, wenn jede Pinnwand von nur einer Konsolidierungsgruppe besucht und bearbeitet wurde. Es kann allerdings durchaus vorkommen, dass bei der Konsolidierung in einzelnen Gruppen hitzige Diskussionen entstehen. An dieser Stelle gibt es mehrere Möglichkeiten zur Konfliktlösung:

  1. Man markiert mehrere Haftnotizen als potentielle Kandidaten im Hinblick auf die Qualitätsanforderungen und lässt Ende der Phase 3 darüber im gesamten Plenum per Mehrheitsbeschluss abstimmen. Dies ist mit Sicherheit die schnellste und zeitsparendste Variante aber man läuft Gefahr, dass berechtigte Bedenken von einzelnen Personen übergangen werden.
  2. Die zweite Variante ist die Möglichkeit, weitere Gruppen auf die Pinnwände mit divergierenden Meinungen schauen zu lassen. Dies ist eine Variante, welche mehr Meinungen berücksichtigt aber diese Variante kann den Workshop zeitlich in die Länge ziehen.
  3. Die dritte Variante greift primär dann, wenn eine der beiden anderen Möglichkeiten kein Ergebnis erzielt: man markiert den entsprechenden Bereich als “wir benötigen mehr Informationen” und datiert die Entscheidung nach hinten. Erfahrungsgemäß zeigt sich allerdings, dass diese Option nach einiger Zeit Tür und Tor für politische Hinhaltetaktiken öffnet und somit mit viel Vorsicht zu genießen ist.
  4. Als Alternative zur dritten Variante ist es weitaus besser mit einer Hypothese aus dem Workshop zu gehen und diese danach durch geeignete Metriken zu verifizieren. Ich definiere an dieser Stelle immer gerne die Messpunkte, die erfasst werden müssen um später eine bessere Entscheidung treffen zu können.
Team-Rotation in Phase 3
Team-Rotation in Phase 3
Phase 4: Priorisierung

In den vorhergehenden Phasen wurden zahlreiche Anforderungen an die Qualität einer Software gesammelt. Allerdings besteht jedoch bei Architekturentscheidungen häufig die Möglichkeit, dass diese zwischen unterschiedlichen Qualitätsanforderungen abgewogen werden müssen. So kann eine Architekturentscheidung bestimmte Qualitätsanforderungen positiv beeinflussen aber auf der anderen Seite auch einen negativen Effekt auf andere Qualitätsanforderungen haben. Eine Priorisierung der Anforderungen gibt den Software Architekt*innen und -Entwickler*innen eine fundiertere Entscheidungsbasis. Diese Priorisierung ist der letzte Schritt im eigentlichen Quality Storming.

Vor der Durchführung der Priorisierung können die in der Konsolidierung aussortierten Qualitätsanforderungen gerne zur Seite geklebt werden. In dieser Phase zählen nur die in Phase 3 markierten Anforderungen.

Für die Durchführung der Priorisierung hat sich ein Dot-Voting bewährt: In Abhängigkeit der Menge der gesammelten Qualitätsanforderungen bekommt jeder Teilnehmerin des Quality Storming Workshops eine bestimmte Menge an kleinen Klebepunkten. Die Menge der ausgehändigten Klebepunkte pro Person sollte in etwa 15 - 25% der konsolidierten Qualitätsanforderungen betragen. Danach werden die Workshop-Teilnehmer*innen gebeten, ihre wichtigsten Anforderungen mit Hilfe der Klebepunkte zu markieren. In der Regel sollte eine Person nur einen Punkt auf eine in der Konsolidierung markierte Haftnotiz kleben. Eine Variante wäre aber noch die Möglichkeit, dass man den Teilnehmer*innen erlaubt bis zu zwei Punkte auf Anforderungen zu kleben, die ihnen besonders wichtig sind.

Dot-Voting zur Priorisierung der Anforderungen in Phase 4
Dot-Voting zur Priorisierung der Anforderungen in Phase 4

Zum Ende der vierten Phase haben wir eine nennenswerte Anzahl von priorisierten Qualitätsmerkmalen gesammelt.

Phase 5: Ausblick

Die letzte Phase, der Ausblick, ist primär eine Zusammenfassung der erarbeiteten Ergebnisse. Es ist immer ratsam, den Teilnehmer*innen ins Gedächtnis zu rufen, dass man nun eine Menge an Anforderungen hat, die Stakeholder-übergreifend erfasst und diskutiert wurden. Wahrscheinlich hat der Workshop den meisten Personen auch Spass gemacht. Nun gilt es von Seiten der Facilitatoren und der technischen Teilnehmer*innen noch einen kurzen Ausblick darauf zu geben, wie künftig mit den Ergebnissen des Workshops gearbeitet wird. Des Weiteren sollten man auch kurz aufzeigen, welche greifbaren Artefakte im Rahmen der Nachbereitung auf Basis der Workshop-Ergebnisse erstellt werden und wo die Teilnehmer*innen diese finden können.

Nachbereitung

Prinzipiell ist es zu empfehlen, die erarbeiteten Ergebnisse in Richtung der Architekturdokumentation zu übertragen. Mögliche Optionen sind:

Zusammenfassung

Quality Storming ist eine Workshop zur Identifikation von Qualitätsanforderungen auf Basis eines Qualitätsmodells, beispielsweise ISO 25010, bei dem Methoden und Ideen des in der Domain-driven Design Community beliebten Collaborative Modeling verwendet werden. Wichtig ist hierbei eine Silo-übergreifende Kollaboration unterschiedlicher Stakeholder und Skillsets.

Quality Storming setzt hierbei auf drei zentrale Phasen:

Diese Phasen werden durch eine Vorbereitung / Einführung und einen Ausblick bzw. einer Nachbereitung eingerahmt.

Gesamtüberblick Quality Storming
Gesamtüberblick Quality Storming

Leser*innen dieses Artikels können das Buch “Hands-on Domain-driven Design - by example” von Michael Plöd mit folgendem Rabatt-Coupon vergünstigt unter diesem Link kaufen.

  1. https://en.wikipedia.org/wiki/Architecturetradeoffanalysis_method  ↩

  2. https://leanpub.com/introducing_eventstorming  ↩

  3. https://www.amazon.com/Gamestorming–Playbook–Innovators–Rulebreakers–Changemakers/dp/0596804172  ↩

  4. https://arc42.org  ↩

TAGS