Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Willkommen zu einer weiteren Episode von Software-Architektur im Stream, diesmal mit Michael.
Hallo Michael, schön, dass du da bist.
Es geht heute um das Thema Quality-Storming und ich will dazu sozusagen vorab zwei, drei Sätze sagen.
Also es ist eben so, dass Qualitäten ein ganz wesentliches Thema im Stream gewesen sind.
Das ist ein Architektur-Treiber und wir waren dann beide, du Michael und ich, auf dem KOMU-Camp in Wien. Übrigens eine sehr schöne Veranstaltung und da hattest du halt diese Episode gemacht zum Thema Quality-Storming.
Und ich fand das ganz spannend, weil das die Frage beantwortet, wie kriege ich eigentlich irgendwie Qualitäten auf die Reihe und das ist so ein bisschen die Motivation.
Und deswegen freue ich mich, dass du hier im Stream das jetzt auch nochmal vorstellen möchtest.
Und die erste Frage, du warst ja schon mehrmals hier, aber die erste Frage, wer bist du und was machst du so?
Ja, also ich bin der Michael Plöd.
Vielen Dank, dass du mich wieder zum wiederholten Male einlädst.
Ich bin der Michael Plöd, ich arbeite als Fellow bei der InnoQ, komme eigentlich sehr, sehr stark, habe einen recht starken Software-Engineering-Background, bin dann irgendwie in das Software-Architektur-Thema abgedriftet und befasse mich aktuell sehr, sehr viel mit so Themen wie Domain-Driven-Design und Team-Topologies.
Und ich glaube, aus gerade der Domain-Driven-Design-Ecke und der Software-Architektur-Ecke ist halt so diese Idee zu dem Quality-Storming entstanden und darüber werden wir heute ein bisschen reden.
Genau, was bedeutet, dass das tatsächlich deine Idee ist?
Also du bist der Erfinder von der ganzen Geschichte.
Magst du erstmal ein paar Worte darüber sagen, was das eigentlich ist?
Also ich sage mal so, Quality-Storming ist eine Methode der kollaborativen Modellierung.
Also das heißt, wir wollen damit verschiedenste Stakeholder an einem Software-Projekt zusammenbringen, sodass die sich gemeinsam unterhalten über die Qualitätsanforderungen.
Und die Motivation dahinter war eigentlich, dass ich immer wieder beobachtet habe, dass Software-Architektinnen, Software-Engineers ziemlich unzureichende Qualitätsanforderungen erhalten haben.
Dass in vielen Projekten Fokus ist auf funktionale Anforderungen, die sind für viele Nutzerinnen und Nutzer sehr greifbar.
Das ist zugänglich, ja klar, wir müssen verstehen, was das System tun muss.
Aber wenn es so darum ging, Qualitätsanforderungen zu formulieren, die auch manchmal unter diesem unsäglichen Begriff nicht funktionale Anforderungen formieren und das ist das letzte Mal, dass ich dieses Wort in dem Stream in den Mund nehmen werde.
Da tun sich halt viele schwer.
Da kriegen wir halt dann so Anforderungen wie, das System muss skalierbar sein.
Schön, Skalierbarkeit ist sehr, sehr breit interpretierbar.
Muss das jetzt eine deterministische Skalierbarkeit zu einem bestimmten Zeitpunkt sein?
Muss die undeterministisch sein, auf Basis unvorhergesehener Ereignisse, beispielsweise in einem Trading-System, wenn da irgendwas auf der Welt passiert, werden Aktien gehandelt wie verrückt etc.
Und das zu substanziieren.
Da habe ich immer wieder so ein Ping-Pong-Spiel beobachtet zwischen Engineering-Teams und der Fachseite.
Und man mochte sich im Laufe des Ping-Pong-Spiels dann immer weniger.
Und im Grunde genau habe ich halt oft gesehen, dass das halt dann auf Basis von Annahmen Architekturentscheidungen getroffen werden.
Da habe ich mal gedacht, hey, im Domain-Domain-Design gibt es eigentlich so Ideen wie Event-Storming, Domain-Storytelling, Example-Mapping aus der BDD-Welt, die halt sehr stark kollaborativ sind.
Können wir nicht einen Rahmen schaffen, wie wir gemeinsam in der Workshop-Methode sowas zusammen erarbeiten können?
Und zwar, dass wir mal ein gemeinsames Verständnis entwickeln und dass vor allem die Einstiegshürde da drin total niedrig ist.
Und das ist Quality-Storming.
Das ist eine Workshop-Methode, die könnt ihr remote durchführen, die könnt ihr vor Ort durchführen, die euch einfach in ein paar einfachen Schritten kollaborativ, also in der Zusammenarbeit, dazu anleiten soll, bessere Qualitätsanforderungen zu bekommen.
Ich vermeide jetzt ganz bewusst den Begriff Perfekte, weil ich glaube, perfekt gibt es in dem Kontext nicht, sondern einfach mal was Besseres zu bekommen mit einem gemeinsamen Verständnis, auch einer gemeinsamen Sensibilisierung dafür, wie das, was wir davor hatten.
Und diese gemeinsame Sensibilisierung, das ist mir ganz wichtig, weil wir sagen immer wieder, Business und IT müssen enger zusammenwachsen.
Und häufig ist es halt auch so, dass man sagt, die Entwicklungsteams und ArchitektInnen müssen näher ans Business ran.
Aber ich glaube, ehrlich gesagt, wir müssen auch eine Brücke bauen, dass die Fachseite näher an die IT kommt und halt versteht und denen eine Möglichkeit gibt, ein Verständnis aufzubauen, warum Qualitätsanforderungen eigentlich genauso wichtig sind wie funktionale Anforderungen.
Und das soll eben diese Workshop-Methode erreichen.
Genau, und ich glaube, damit hast du schon so ein paar ganz, ganz wesentliche Sachen gesagt.
Also einmal eben, dass Qualitäten halt massiver Architekturtreiber sind und dann, dass es eben diese Ideen gibt von kollaborativer Modellierung.
Wir hatten da eine Episode zu Event-Storming und Specification by Example mit der Nicole Rauch hier im Stream und wir hatten auch eine Episode zu Domain Storytelling mit dem Henning Schwenden und dem Stefan Hofer.
Ich verlinke hier auch nochmal.
Und wir haben hier jetzt letztendlich eine weitere Methode, die halt dort, sagen wir mal, ähnliche Themen macht, diese Silos einreißt, dafür sorgt, dass man irgendwie miteinander reden kann und eben, wie du richtig gesagt hast, dieses Involvement vom Fachbereich und von den Domain-ExpertInnen halt sicherstellt und das eben tut, indem der Einstieg relativ einfach ist, nichtformale Artefakte und so weiter und so weiter.
Und damit, genau, ich überlege gerade, aber das ist, glaube ich, das, was wir so als Wegbereitung haben wollen.
Ich würde ja noch was hinzufügen.
Ja, sehr gerne.
Gemeinsames Verständnis aufbauen.
Ich glaube, das ist ein ganz, ganz wichtiger Aspekt, dass wir gemeinsam verstehen.
Also einerseits kann ich ja sagen, wir brauchen den 99,99999 Prozent Verfügbarkeit.
Es ist total leicht, sowas einzutragen in irgendwie so ein Template für Qualitätsanforderungen, damit halt da irgendein Prozessschritt erfüllt ist.
Aber was bedeutet das eigentlich?
Also, was bedeutet das auf einer Kostenseite?
Was bedeutet das auf einer infrastrukturellen Seite, auf einer architektonischen Seite?
Ich sehe halt immer wieder, dass Entwicklungsteams da manchmal lachen über solche Anforderungen.
Das ist ja völliger Wahnsinn.
Aber die andere Seite, die kann es ja nicht besser wissen.
Also, woher soll jemand auf einer fachlichen Seite wissen, welche Implikationen das mit sich bringt?
Und diese Kollaboration soll eben genau auch dort sensibilisieren, was das heißt.
Ich vergleiche das immer wieder mit einem Autokualitätsanforderungen.
Was ist meine Qualitätsanforderung an einem Auto?
Was ist das beste Auto?
Es kommt darauf an.
Also, wenn ich jetzt in irgendeiner Stadt unterwegs bin und mich nur in der Stadt bewege, ist vielleicht so ein elektrischer Kleinwagen total super.
Wenn ich in Island, in den Highlands zum Miley Fell fahren will, ist ein extrem leistungsfähiger 4x4, so ein Monstrum, wahrscheinlich das beste Auto dafür.
Und die S-Klasse von Mercedes oder ein 7er BMW oder was weiß ich was, ist natürlich sehr, sehr angenehm, wenn ich mich von einem Chauffeur laufen von München nach Hamburg fahren lasse, aus welchen Gründen auch immer.
Und ich glaube, diese Sensibilisierung, dieses Verständnis, das möchte ich eigentlich fördern damit, weil ich sehe mich gerne als Brückenbauer zwischen den beiden Seiten, dass die sich begegnen können.
Genau, und das war der Aspekt, den ich auch nochmal hervorheben wollte.
Gut, dass du es nochmal gesagt hast.
Das ist das, wo man nicht sagt, seid doch nett miteinander und unterhaltet euch, sondern das, wo man sagt, hier kriegen wir das halt konkret hin.
Hier ist ein Ansatz, mit dem wir das auf die Reihe bekommen.
Einen Aspekt, den ich dabei auch noch wahnsinnig wichtig finde, wir hatten dazu mal eine Episode mit der Tseng Chao, die gesagt hat, vielleicht ist gar nicht das Artefakt so wichtig, sondern eben auch die Kollaboration und das gegenseitige Verständnis.
Wir sperren eben alle Leute in einen Raum und dann kriegen wir halt am Ende irgendwie ein Ergebnis raus und das bedeutet, dass wir die Kollaboration überhaupt erstmal einüben.
Und ich glaube, das ist auch nochmal ein ganz wichtiger Punkt an der Stelle.
Gut, der Rest der Episode ist, glaube ich, im Wesentlichen ein Marsch durch Quality Storming, wie das halt sozusagen funktionieren soll oder funktioniert.
Und ich glaube, das Erste ist die Vorbereitung, also der erste Schritt, mit dem ich loslege.
Genau, also vorbereitend muss man sich natürlich überlegen, wer sollte an so einem Workshop teilnehmen.
Wenn ihr jetzt eh schon in der Architekturarbeit tätig seid und euch da vielleicht schon mal Gedanken gemacht habt, wer sind denn eigentlich die Stakeholder an eurer Architektur?
Beispielsweise auch was, was AK42-Template euch als Frage stellt.
Welche Stakeholder habt ihr denn?
Müsstet ihr da, glaube ich, eigentlich schon eine ganz gute Liste an potenziellen Teilnehmern und Teilnehmerinnen identifiziert haben.
Ich favorisiere eigentlich immer Gruppen so 16 bis 24 Leute in dem Dreh.
Warum ich die Zahlen 16 und 24 wähle, erzähle ich gleich noch.
Denn ein Teil der Vorbereitung ist natürlich auch das, dass ihr euch mal überlegt, entlang von was für einem Qualitätsmodell wollt ihr denn sammeln?
Also das heißt, ein wichtiger Input für so einen Workshop, dass ihr euch erst mal Gedanken macht über das Qualitätsmodell, mit dem ihr arbeitet.
Da gibt es jetzt verschiedene, manche Firmen haben dafür von ihren QS-Abteilungen beispielsweise schon Standards, bestimmte Qualitätsmodelle, an denen das erfolgt.
Andere haben das noch nicht.
Da gibt es beispielsweise ISO 25010 als eine Art Standard, an dem man sich mal orientieren kann.
Das hat bestimmte Hauptkategorien, dieses ISO-Modell, wie jetzt beispielsweise Performance, Effizienz, Kompatibilität, funktionale Passgenauigkeit, Usability, Wartbarkeit und so weiter.
Und die brechen das meistens runter auf Unterkategorien, was weiß ich, was beispielsweise im Bereich Wartbarkeit, Modularität, Testbarkeit etc.
Also das solltet ihr euch mal entscheiden drüber.
Kleiner Tipp, ich würde für jede Oberkategorie von so einem Qualitätsmerkmal die Teilnehmeranzahl ableiten.
Also beispielsweise ISO 25010 hat jetzt 8 Oberkategorien.
Wenn man das mal 2 nimmt, wären wir bei 16, wenn man mal 3 nimmt, sind wir bei 24.
Nehmt das aber jetzt bitte als Pi mal Daumen-Regelung.
Wenn ihr das trefft, ist das total cool.
Wenn ihr es nicht trefft, geht die Welt nicht unter.
Aber ich würde schon gern so 2-3 Leute an so einer Oberkategorie später stehen haben.
Ihr könnt auch andere nehmen, das ist kein Problem.
Sollten die Leute jetzt dieses Qualitätsmodell noch nicht kennen, zum Beispiel ISO 25010, macht es vielleicht Sinn, im Vorfeld mal eine kurze Session zu machen.
Da ein paar Sachen zu erklären, aber ich halte das nicht dringend für nötig.
Denn wir werden später da in dem Workshop auch Beispiele einführen.
Wie gesagt, für mich ist ein ganz wichtiges Kriterium für einen guten kollaborativen Modellierungsworkshop, dass die Einstiegshürden extrem niedrig sind.
Deshalb würde ich das niemals so aufsetzen, dass die Leute das sehr gut kennen müssen.
Ihr solltet natürlich eine Einladung rausschicken, das ist ganz klar, wo man ein bisschen erklärt, worum es geht.
Und ihr müsst einen geeigneten Raum auswählen.
In der Remote-Setting braucht man ein Video-Tool des Breakout-Rooms.
Das können inzwischen die meisten Tools.
Und irgendein Tooling zur kollaborativen Zusammenarbeit.
Da geht es um Concept-Board, Miro, Mural usw.
Inzwischen unzählige Dinge, da hat sich sehr viel etabliert in der Zeit von Covid-19.
Ich glaube, da hat eigentlich jede Firma irgendwas am Start inzwischen.
Solange da mehrere Leute parallel auf so einem Ding arbeiten können, ist das gut genug.
Vor Ort solltet ihr eine Räumlichkeit wählen, in der ihr, Beispielsweise im Fall von ISO 25010, das ist so ein Beispiel, das werde ich jetzt im Stream die ganze Zeit einfach mal konsistent verwenden, für jede Oberkategorie von eurem Qualitätsmodell, also in unserem Fall jetzt acht, so eine große Moderationswand aufstellen können.
Das sind jetzt keine Flipcharts, sondern diese Pinboard-Wände, die man so rumrollen kann.
Und acht Stück sollten da reinpassen.
Und ihr solltet noch Raum haben, dass die Leute sich da drinnen ganz, ganz gut bewegen können.
Evert, wenn du willst, kann ich mal so ein Setup von so einem Raum einfach mal einblenden im Screenshare.
Genau.
Das sähe dann in etwa so aus, der Workshop-Raum.
Es werden da diese Pinboards stehen.
Ich stelle das immer ganz gerne im Kreis.
Also ihr seht, ihr braucht da schon ein bisschen größeren Raum.
In der Mitte vielleicht irgendwie so Barfische oder sowas mit Sticky Notes, Stiften.
Vielleicht noch ein, zwei Flipcharts, damit ihr noch als Facilitator ein paar Notizen machen könnt.
Und das wäre sozusagen mal der eine Teil der Vorbereitung und der andere Teil der Vorbereitung.
Sorry, nur kurz.
Also was wir jetzt sehen, ist eben tatsächlich ein Raum, wo jetzt zwei, vier, sechs, acht von diesen Moderationswänden vor den Wänden stehen.
Keine Stühle.
Und wie du sagst, es hat so zwei Tische mit irgendwelchen Post-its oder so.
Und wofür die Leute, die jetzt sozusagen im Podcast das nicht sehen können, das ist halt das, was Michael jetzt gerade geteilt hat.
Sorry.
Ja, genau.
Und die Größe des Raums, ihr seht schon, er braucht einen relativ großen Raum mit Tischen, die ihr zur Seite schieben könnt, etc.
Also schaut da bitte ein bisschen rum.
Genau.
Es gab im Vorhinein eine Frage von dem Torsten Irlender bei LinkedIn.
Zu welchen Voraussetzungen sind erforderlich?
Wie geht man zum Beispiel mit Kunden um, die mit den Kriterien nach ISO 25010 noch nicht vertraut sind?
Ich glaube, das hast du schon beantwortet.
Also denen bringt man es dann sozusagen ad hoc bei.
Also was ich da mache, ich würde das gerne mal beantworten, Eberhard.
Ich zeige mal ein Beispiel.
Ja, jedes dieser Pinboards steht für eine der Oberkategorien von ISO 25010.
Und die Unterkategorien, also wir schreiben da die Oberkategorie mal hin, ganz oben auf das Pinboard mit einem großen Sticky Note.
Genau, hier ist es Effizienz, was wir jetzt gerade als Oberkategorie haben.
Genau, Performanceeffizienz, da haben wir die Unterkategorien Zeitverhalten, Ressourcenverbrauch, Kapazitätsmanagement, etc.
Ich weiß jetzt nicht den genauen deutschen Begriff, ich habe ihn nicht flüssig.
Und da beschreibt man das mal, was das bedeutet.
Und ich glaube, was ganz, ganz wichtig ist, ist, dass ihr da schon mal Beispielanforderungen ausformuliert davor.
Kleiner Tipp am Rande.
Auf der ARC 42 GitHub-Seite gibt es, und ich glaube, da gibt es auch inzwischen eine dedizierte Homepage dafür, gibt es eine supergute Sammlung von Beispielqualitätsszenarien.
Ich kann das gerne mal raussuchen, dann können wir das in die Notes am Schluss noch mal reinpacken.
Ja, und ich glaube, da könnt ihr euch ziemlich gut bedienen, dass ihr da einfach mal ein paar Beispiele raussucht, wie die aussehen, und die da mal hinschreiben, damit die Leute ein besseres Verständnis dafür bekommen.
Und auf die Art und Weise müssen die Leute jetzt ehrlich gesagt noch nicht einmal so tief in der Materie des jeweiligen Qualitätsmodells drinstecken.
Also ich habe inzwischen für mich, für so Vorort-Workshops, so eine Mappe, wo das alles schon vorbereitet ist, wo ich auf ein paar Sticky Notes meine Beispiele draufgeschrieben habe.
Das heißt, ich ziehe die einfach raus und klicke die dann jetzt mal mit auf, so dass die Leute eine Orientierung bekommen, ah, okay, das ist gefordert.
Also beispielsweise bei Skalierbarkeit, wir müssen bei besonderen Ereignissen in der Lage sein, innerhalb von fünf Sekunden auf die doppelte Anzahl von Requests oder Concurrent Users hochskalieren zu können.
Oder das System muss von Montag bis Freitag zwischen 6 und 20 Uhr verfügbar sein.
Also dass man das halt so mal ausformuliert, was da gemeint ist.
Versucht diese Ausformulierungen so zu gestalten bei den Beispielen, dass die für die Leute greifbar sind, dass die sich da wiedersehen.
Das ist, glaube ich, eine ganz wichtige Sache auch.
Das führt für mich übrigens zu der nächsten Frage.
Ich weiß nicht, ob wir die hier jetzt gleich beantworten wollen.
Also es gibt ja gewisse formale Kriterien, die Qualitätsszenarien haben sollen.
Mindestens müssen sie aber eigentlich verifizierbar sein.
Und ich habe jetzt genügend Beispielen draußen in der realen Welt gesehen, um zu glauben, dass das halt gar nicht so einfach ist.
Wie gehst du denn damit um?
Also das ist ja auch etwas, was jetzt TeilnehmerInnen irgendwie beherrschen müssen, dass sie halt verifizierbare, vernünftige Qualitätsszenarien schreiben und ISA-QB-Advanced-Level-Menschen, die sich da zertifizieren lassen, haben da auch manchmal irgendwie Herausforderungen.
Ich würde sagen, das würde ich in der Phase 2 adressieren.
Das kriegen wir hier noch nicht hin.
Das ist dann eine Frage der Gruppenzusammenstellung, wie wir da durchgehen.
Okay, alles klar.
Also der Workshop per se ist nicht darauf getrimmt, hier 100% extrem spezifisch korrekt zu sein.
Sondern was unser Ziel ist hier, ist substanziell besser zu werden, wie das, was wir in der Breite bisher häufig bekommen.
Ja, wenn das jetzt bis auf das allerletzte Quäntchen 100% wissenschaftlich korrekt quantifizierbar ist.
Also jetzt beispielsweise so eine Skalierbarkeitsanforderung, ist mir es besser, ist mir es lieber, wie wenn ich irgendwas habe, was besser ist, wie Systeme skalieren können.
Also ich glaube, das ist dann eine Sache, die müssen dann Leute mit einem Spezialwissen später auch nochmal nachschärfen.
Das gleiche haben wir ja auch jetzt beispielsweise bei anderen kollaborativen Modellierungsmethoden, Event-Storming oder sowas.
Da fallen ja jetzt auch noch keine perfekt formalisierten Modelle raus, sondern wir schaffen eine gesunde Basis für eine spätere Formularisierung von diesen Sachen.
Dass die auf einer fundierteren Basis erfolgt, auf Basis von einem gemeinsamen Verständnis.
Ja, wahrscheinlich könnte man nochmal so eine Art Manifesto irgendwo schreiben, nicht?
Kollaborative Modellierung, Kollaboration über formale Korrektheit oder so.
Also von daher, guter Punkt.
Kollaborative Modelling Manifesto.
Ja, genau.
Sehr schön.
Das ist, glaube ich, das soweit zur Vorbereitung.
Dann ist, glaube ich, die erste Frage, achso, genau, weil du sagtest, diese QR-Beispiele, also ich verlinke deinen Artikel, den du ja auf der InnoQ Homepage hast und da ist halt auch der Link zu eben jenem Repository, den packe ich dann halt auch nochmal in die Links, da findet man das also anschließend.
Den Link zu diesen Slides kann ich dir auch noch geben.
Das wäre super, ja, genau.
In letzter Zeit habe ich ziemlich viel Feedback dazu bekommen, weshalb ich ein bisschen mit der Idee rumspiele, ob ich da nicht auch mal eine Digi-CT Homepage dazu mache.
Mal schauen.
Immer so eine Zeitsache.
Ja, hört sich, glaube ich, gut an.
Dann ist die Vorbereitung soweit durch, denn wäre halt, also ich habe mehr aus deinem Artikel rausgeschrieben, Phase 1 ist Einleitung und Einführung.
Ja, das ist eine relativ triviale Phase, also da ist jetzt keine Rocket Science oder Ähnliches nötig.
Ich würde sagen, jeder von so einem Workshop sollte halt einen oder vielleicht zwei Facilitators haben, die sich um den Rahmen kümmern, die die Leute begrüßen, mal erklären, worum es geht.
Auch ganz, ganz wichtig, eine korrekte Erwartungshaltung schaffen, dass man mit einer gemeinsamen Erwartungshaltung reingeht.
Ja, also beispielsweise, wir wollen besser werden, wie das, was wir davor haben, aber wir haben jetzt nicht den Anspruch, absolut minutiös perfekt zu werden an der Stelle.
Das wäre für mich so ein Nicht-Ziel von so einem Workshop, sondern erst einmal gemeinsame Sensibilisierung, gemeinsames Verständnis entwickeln, besser werden wie das, was wir davor haben.
Formalisieren werden wir es dann später im Nachgang.
Ja, und das ist eigentlich so ein Ding, das ist in 5 Minuten, 10 Minuten maximal durch.
Vielleicht mal ein paar Fragen beantworten, vielleicht auch mal abklopfen, was haben die Leute für Erwartungshaltungen daran, wo sind die unsicher beispielsweise, also z.B. ich habe keine Ahnung von dem Zeug und da halt auch Ängste, Befürchtungen etc. nehmen und halt den Leuten die Zuversicht geben, wir haben eine niedrige Einstiegshürde, ihr werdet euch beteiligen können.
Vertraut uns da und auch die Erwartungshaltungen schaffen wir am Anfang, wird es chaotisch werden, später werden wir Ordnung reinbringen in die ganze Schuße.
Okay.
Genau, mehr ist in der Phase eigentlich nicht zu sagen.
Gut, und dann geht es glaube ich tatsächlich gleich los.
Dann geht es los, richtig.
Die erste Phase, die habe ich ein bisschen so mich inspirieren lassen, beispielsweise von einer Chaotic Exploration im Big Picture Event Storming.
Ich habe es jetzt im Quality Storming die Broad Collection genannt, also das heißt, wir sammeln erst mal in der Breite.
Ich gehe her und stelle, ich habe hier auch mal ein Bild vorbereitet dazu, ich stelle 2 bis ca.
3 Leute, je nach TeilnehmerInnenanzahl, in dem Workshop an ein so eine Pinboard und was da ganz, ganz zentral ist.
Passt bitte auf, dass jetzt hier nicht ein Grüppchen von nur Software Engineers steht, ein Grüppchen von nur Testleuten, ein Grüppchen von nur Domain Experts oder nur irgendwelchen Führungskräften etc., sondern achtet drauf, dass ihr dort heterogene Gruppen an Leuten bildet.
Dass beispielsweise jetzt jemand aus dem Test mit jemand aus der Architektur und jemand aus der Fachseite zusammensteht, dass eine Führungskraft mit jemand aus dem UX und jemand aus der Softwareentwicklung beispielsweise zusammensteht.
Ich würde immer schauen, dass in jeder dieser Gruppen eine Person steht, die später auf einer Engineering- oder Architekturseite von diesen Anforderungen betroffen ist.
Das wäre immer ganz gut, weil die können den anderen dann dabei helfen, diese Anforderungen zu schärfen, präziser auszudrücken.
Also ich sehe das quasi so, dass sich die Gruppen da untereinander auch ein bisschen coachen und anleiten, dass wir verschiedenste Perspektiven vereinen beispielsweise.
Also jemand schreibt hin, das System muss 99,99999 Prozent verfügbar sein.
Dann könnte jemand aus einer Betriebs-Background, zum Beispiel aus dem Operating, sagen, hey, ist dir eigentlich klar, was das bedeutet?
Habt ihr eigentlich überhaupt das Budget dafür?
99,999 heißt und etc. im Jahr wegen mir 30 Sekunden Downtime.
Also das Budget werden wir wahrscheinlich gar nicht haben.
Also das heißt, da bauen wir gleich was ein, wo so ein gewisser Realitätsabgleich dann auch stattfinden kann und auch ein gewisses Coaching in den Gruppen eben stattfinden kann.
Ich habe die Erfahrung gesammelt, dass Leute mit einem technischen Hintergrund da eigentlich ganz, ganz gut auf andere auch einwirken können.
Und ich würde denen einfach sagen, hey, sammelt einfach mal zu diesen Unterpunkten mögliche Szenarien, schreibt die auf die Sticky Notes und knet die da erst einmal auch hin.
Und ich lasse das jede Gruppe zehn Minuten machen.
Nach zehn Minuten, und das ist etwas, was ich wirklich ein Box macht.
Also da fahre ich in den Workshop sehr klare Timeboxen.
Das ist ja immer in kollaborativen Modellierungstechniken eine Frage, wie stark gehen wir mit Timeboxen um oder nicht?
Hier arbeite ich strikt Timebox.
Also zehn Minuten haben sie total gut bewährt für sowas.
Das ist ein bisschen Druck dahinter, dass man ein bisschen was hinbringt und die Zeit verläuft sich nicht.
Nach zehn Minuten schlägt der Gong.
Wäre gut, wenn er da irgendwie ein Ding dabei hat, was Lärm macht.
Und dann ziehen alle Gruppen eine Moderationswand weiter zur nächsten Oberkategorie und die sammeln wieder.
Also diese Gruppen bleiben über diese Zeit hinweg konstant und sammeln immer miteinander.
Und was man eben sieht, ist, dass spätestens nach der zweiten, dritten Moderationswand, an der die waren, die untereinander sehr, sehr gut eingegroovt sind.
Dass das eigentlich ziemlich gut funktioniert.
Oder ihr werdet auch mal feststellen, wo irgendwo eine völlig dysfunktionale Gruppe ist, die hint und vorn nicht miteinander kann.
Wo sie streiten, da könnt ihr vielleicht dann auch nochmal als Facilitator Zusammensetzungen eventuell auch verändern.
Erfahrungsgemäß muss ich aber sagen, passiert sehr selten bis damit.
Wenn man das jetzt mal hochrechnet, mit so der Zeit, die die brauchen, um auf die nächste Ding zu gehen, sind so circa 90 bis 100 Minuten rum.
Und ich glaube, dann haben alle Leute in den Workshops sich redlichst mal eine ausführliche Pause verdient.
Also das Endergebnis von so einer Sammlung in der Breite ist einfach eine riesengroße Sammlung an verschiedensten Qualitätskriterien, die können widersprüchlich sein.
Das ist auch völlig okay.
Wir wollen da verschiedene Perspektiven einnen.
Und wir haben da erstmal so eine chaotische Sammlung einfach mal abgeschlossen, die natürlich ein bisschen durch die Ober- und Unterkategorien geführt sind, klar.
Aber wir haben da jetzt erstmal so einen Haufen an potenziellen Ideen, nenne ich es gern.
Und das ist quasi so das Ende dieser Sammlung.
Genau.
Gut, ich glaube, wir müssen nochmal kurz zurückspringen.
Also in YouTube hat der DIN Hamburg gerade gesagt, wenn 16 bis 24 Leute in der Projektvorbereitung zu einem Workshop aufgerufen werden, ist das ja schon mal eine Hausnummer als Kostenpunkt.
Und hat dann weiter gefragt, kann man das nicht als Anzahlperson in Abhängigkeit vom Projektbudget formulieren?
Dann hat Superman02 gesagt, da schließe ich mich an.
Irgendwie ist mir auch nicht klar geworden, was das Objekt der Betrachtung ist.
Bei was, wo soll die Qualität verbessert werden?
Lass uns mal kurz anfangen mit dieser Anzahl der Personen.
Also 16 bis 24 hattest du ja jetzt irgendwie gesagt.
Und die Aussage ist, wenn ich sozusagen verkürzen dürfte, wenn ich ein kleines Projekt habe, ist das möglicherweise sehr viel.
Also ich würde mal sagen, bei einem sehr kleinen Projekt ist das wahrscheinlich auch overkill, diese Maßnahme.
Ich glaube, die richtet sich primär schon an recht große, ambitionierte Projekte, wo Qualitätsanforderungen dann auch sehr weitreichende Architekturentscheidungen mit sich bringen.
Ich würde mal sagen, meiner Erfahrung nach ist es, dass gerade in so größeren Projekten auf streckenweise auf viel zu ambitionierte Qualitätsanforderungen geschielt wird, was dann später raus zu sehr teuren Architekturentscheidungen führt.
Und ich glaube, wenn ich da an einer Stelle mit so einem Workshop was identifiziere, wo ich an zwei, drei, vier Architekturentscheidungen Geld spare, haben wir schon einen Business Case für den Workshop.
Und ich glaube auch, das ist was, was auch für mittel- bis langfristigen sehr, sehr positiven Einfluss auf den monetären Aspekt hat.
Natürlich ist es so, aber ich glaube, das eint alle kollaborativen Modellierungstechniken, dass die erst mal in der Durchführung relativ teuer sind.
Deshalb würde ich mal überlegen, in welchen Teilbereichen würde ich das machen?
Da kann es natürlich auch sein, dass man sich da primär mal auf die Kerndomänen fokussiert, die strategisch wirklich wichtig, relevant sind, etc., dass man eben sowas durchführt.
Genau.
Und vielleicht noch kurz, ich finde es total wichtig, das noch mal hervorzuheben.
Also der Name sagt es nicht, es ist ein kollaboratives Modell.
Das heißt, es geht um Kollaboration.
Das heißt, Menschen müssen zusammenarbeiten.
Das ist halt so.
Sonst macht es halt keinen Sinn.
Und ich weiß gar nicht mehr, wie genau dieser Spruch geht, von wegen, dieses Meeting hätte irgendwie acht Stunden entwickeln vermeiden können.
Also wie soll ich sagen, es ist eben mitnichten so, dass das Einsparen von Meetingzeiten dazu führt, dass es insgesamt besser wird.
Also wie du ja völlig richtig gesagt hast, wenn ich nicht weiß, was ich bauen soll, wird es halt irgendwie schwierig.
Der super Main…
Das ist auch nichts, warte mal schnell, das ist auch nichts, was ich jetzt wöchentlich durchführen werde.
Also ich glaube, wenn ich jetzt mal so eine Projektbrille aufsetze, dann ist das eigentlich was, was ich am Anfang einmal durchziehe.
Und dann sollte eigentlich der Output oder das Ergebnis davon über das gesamte Projekt hintragen.
Wenn ich eine Produktbrille habe, ist es so, dass ich da mal eine Basis legen kann und dann später ja nur noch verfeinern muss.
Das ist auch nichts, was ich jetzt wöchentlich oder monatlich durchführen würde.
Ich würde es mal regelmäßig auf den Prüfstand stellen und schauen, passen die Anforderungen noch?
Ja, aber ob ich dann jedes Mal so einen Riesen-Workshop brauche, eher Alexander weniger, sehe ich gerade.
Der Alexander Herold hat dazu gerade eine Frage gestellt, die, glaube ich, ganz gut dazu passt.
Also der hat gefragt, macht es auch Sinn, so einen Workshop bei schon laufenden Projekten zu machen?
Es kommt darauf an.
Ich glaube, wenn du in einem laufenden Projekt das Gefühl hast, dass die Qualitätsanforderungen, die irgendwie festgehalten sind, nicht mit denen entsprechen, die in der Realität gelten, könnte so ein Workshop gut helfen.
Ich meine, da, wenn du schon was hast, spricht nichts dagegen, die bestehenden Anforderungen vielleicht in einer anderen Sticky Note Farbe schon mal an die Boards zu hängen.
Das ist eine Möglichkeit.
Das setzt natürlich auch einen gewissen Bias ein, dass die Leute sagen, ja, passt schon, lass mich in Ruhe mit dem Workshop, geh weg.
Das kommt ein bisschen aufs Umfeld an.
Eine andere Sache ist, was ich immer wieder sehe, ist, dass ich Architekten bei Kunden erlebe, die sich beklagen, wir haben eigentlich an der Stelle nichts Brauchbares.
Und das, was da ist, damit können wir keine Entscheidungen treffen.
Und wenn du in so einem Szenario bist, kann da mal so eine Zeitinvestition von, ich sage jetzt mal so vier Stunden, was so ein Workshop in der Regel dauert, vielleicht eine sehr gute Idee sein.
Auch noch eine Idee, in einer Remote-Durchführung könntet ihr Hausaufgaben vergeben, dass ihr die Dreierteams bildet.
Und die sollen sich asynchron einfach mal die Sachen zusammensammeln über mehrere Wochen hinweg oder über eine Woche hinweg.
Und die sollen das einfach dann in ihre Arbeitszeit reinpacken, wann es für sie gerade passt.
Ja, da kann man auch viele dieser Probleme aushebeln.
In einer Vorort-Variante, da würde ich sagen, lass uns einen halben Tag einsperren.
Genau, der Raimund Klein hat gerade geschrieben, absolut oftmals ist das sogar besser, weil dann auch die Nutzerseite eine gewisse konkrete Idee von praktischen Auswirkungen hat.
Ich glaube, das ist eine Bestätigung zu dem, was du vorhin sagtest, insbesondere mit so etwas wie der Verfügbarkeit.
Ich wollte noch kurz, genau, das wäre eigentlich eine Frage, die ich mir jetzt stellen würde, die mir halt gerade bei der Anzahl der Teilnehmer noch mal eingefallen ist.
Wie sollte denn das Verhältnis von Techniker zu Nicht-Techniker sein?
Also wenn wir sagen, 16 bis 24 Personen insgesamt, wie viele davon sind so Leute, die halt entwickeln oder sich Architekten schimpfen?
Und wie viele davon sind irgendwelche Stakeholder, die eben nicht selber entwickeln oder Architekturen malen oder sowas?
Ich würde es mal so 50-50 sagen, wobei ich da auch Leute mit einem betrieblichen Know-how…
Es kommt jetzt natürlich sehr stark aufs Umfeld an.
Viele größere Organisationen haben ja sehr, sehr leistungsstarke und gute Operating Teams.
Und die können euch natürlich da auch wahnsinnig wertvollen Input liefern auf Basis Erfahrungen aus der Vergangenheit.
Die sind super spannende Teilnehmerinnen und Teilnehmer da.
Und die würde ich damit dazu zählen.
Also ich würde es mal sagen, so Architektur, Development, Operations.
Die drei Gruppen, circa die Hälfte, wenn ihr das habt, ist, glaube ich, eine ganz gute Sache.
Also Hintergrund der Frage war halt einfach, um noch mal darauf hinzuweisen, dass es eben nicht ein Projekt ist, das jetzt 16 bis 24 Entwicklerinnen hat, sondern es können halt auch weniger sein.
Raimund hat noch geschrieben, vor Jahren haben die beiden Stefans, also ich nehme an, das sind Zörner und Tod von Embark, mal eine Reihe von Workshops bei meinem damaligen Arbeitgeber durchgeführt.
Die Systeme waren schon lange in Entwicklung und Einsatz.
Heraus kam eine Ansammlung von konkreten Qualitätsszenarien, die wir auf jeden Fall umsetzen wollten.
Das ist, glaube ich, auch noch mal eine gute Ergänzung, dass man das sozusagen on demand noch mal machen kann.
Und jetzt ist noch die andere Frage und ich glaube, die ist auch noch mal ganz wichtig.
Der Superman02 hat gesagt, irgendwie ist mir auch nicht klar geworden, was das Objekt der Betrachtung ist.
Bei was, wo soll die Qualität verbessert werden?
Und da ist es vielleicht noch mal wichtig, diesen Qualitätsbegriff zu klären.
Du hattest ja vorhin, also nachdem du den Begriff nicht noch mal nennen willst, wir reden eigentlich über nicht funktionale Anforderungen.
Also über solche Sachen wie, wie sollen die Antwortzeiten sein?
Das System soll besonders benutzerfreundlich sein.
Wenn ein Loadpeak kommt, hattest du gesagt, dann muss das System halt trotzdem vernünftig reagieren.
Solche Geschichten.
Das geht also hier.
Dieses Qualität verbessern hört sich an wie Codequalität.
Das ist hier nicht der Punkt.
Obwohl zum Beispiel so etwas wie Wartbarkeit natürlich eine Qualitätsanforderung sein kann.
Dass man sagt, okay, wenn halt irgendwie eine Änderung in der Domäne ist, dann muss man die halt schnell nachziehen.
Ich weiß nicht, passt das soweit oder willst du da noch was ergänzen?
Nö, da würde ich jetzt nichts dazu ergänzen.
Es sind, ich sage mal so, Qualitätsanforderungen.
Ich nehme wieder die Analogie zum Auto.
Ja genau.
Für welche Nutzungsszenarien brauche ich ein Auto?
Brauche ich das jetzt, um in den isländischen Highlands herumzufahren oder brauche ich das für den täglichen Weg in die Arbeit in der Stadt, inklusive Parken an der Laterne?
Ich glaube, das sind, wenn ich jetzt mal zwei konkrete Produkte in den Mund nehmen darf, für die Highlands in Island wäre wahrscheinlich so ein Jeep Wrangler oder so ein Defender ein total gutes Ding, wohingegen für den Großstadtdschungel wahrscheinlich eher so ein kleiner Smart oder ein Fiat Cinquecento eine ganz gute Sache ist.
Da geht es jetzt nicht um die Qualitätsverbesserung am Motor oder am Antrieb oder was weiß der Geier was.
Das war erst einmal um die Anforderungen, die dann ein Treiber sind für das Engineering, um so ein Auto zu bauen.
Genau, darum geht es hier halt.
Gut, dann haben wir, glaube ich, das Thema.
Das sind so die Sachen, die aus dem Chat hochgekommen sind.
Genau, der Raimund Klein hat da nochmal geschrieben, das Modell nutzt seine gewisse Unternehmensgröße voraus.
Das haben wir, glaube ich, gesagt.
Und ich glaube, von daher sind wir da, glaube ich, erst einmal sauber.
Gut, das heißt, wir haben jetzt…
Achso, das ist auch noch eine Frage, die ich ganz gerne loswerden wollen würde.
Das impliziert ja jetzt…
Also wir haben jetzt diese verschiedenen…
Moderationswende vollgemalt.
Und jedes Qualitätskriterium ist eine Moderationswende, was bedeutet, dass alle Qualitätskriterien gleich behandelt werden mit derselben Priorität.
Manchmal ist es so, dass bestimmte Sachen, also Skalierbarkeit oder so, total wichtig sind.
Andere Sachen sind irgendwie nicht so wichtig.
Das wird hier jetzt aber nicht priorisiert.
Ist das ein Problem?
Noch nicht.
Okay.
Noch nicht.
Ich glaube, wir werden später hinten raus noch einen Priorisierungsschritt haben.
Aber was ja jetzt hier im aktuellen Status noch sein kann, dass wir zum Beispiel Meinungen haben, das System muss von Montag bis Freitag 6 bis 20 Uhr verfügbar sein.
Und jemand anders sagt, nee, nee, nee, es muss Montag bis Freitag rund um die Uhr verfügbar sein, weil wir beispielsweise Backoffice-Prozesse in verschiedenen Zeitzonen haben.
Also da können ja auch widersprüchliche Anforderungen kommen, dass sich in einzelnen Gruppen unterschiedliche Meinungen dazu befinden.
Und das müssen wir erst mal noch aufräumen an der Stelle.
Und deshalb haben die Facilitators leider keine Pause.
Ich will jetzt einfach mal weitermachen.
Also nach dieser Broad Collection schicken wir die Teilnehmer und Teilnehmerinnen mal in eine wohlverdiente Pause.
Aber die Gruppe, die die Facilitation macht, ich würde euch den Tipp geben, schaut, dass ihr da zu zweit oder zu dritt seid, die sich da drum kümmern.
Vielleicht findet da im Teilnehmerkreis ein paar Freiwillige.
Die sollen jetzt erst einmal drüber gehen, sich das Zeug anschauen.
Da kann man auch viel schon während der Sammlung machen.
Als Facilitator solltet ihr natürlich nicht im Eck sitzen und LinkedIn-Posts schreiben, sondern die Gruppe mitbetreuen, einen Blick drauf haben, was macht denn die.
Ich glaube, da habt ihr auch schon ganz gut ein Ding.
Ah, okay, da haben wir Duplikate, da haben wir vielleicht widersprüchliche Sachen.
Und die solltet ihr mal so ein bisschen gruppieren, so eine Vorgruppierung für die Gruppen durchführen.
Das ist natürlich auch ein bisschen aus einer softwarearchitektonischen Brille, weil wir müssen ja nur Entscheidungen treffen zwischen den Sachen.
Nach der Pause kommen dann die Gruppen zusammen und ich würde dann dort, ich nenne diese Phase Consolidation, hergehen und die Sachen verdichten.
Dass wir eben sagen, okay, wie ist denn jetzt wirklich die Verfügbarkeitsanforderung?
Ist das jetzt Montag bis Freitag, 6 bis 20 Uhr?
Ist es Montag bis Freitag rund um die Uhr?
Oder 24-7, beispielsweise mit bestimmten Verfügbarkeitskriterien?
Oder können wir da noch was machen?
Und da würfel ich die Gruppen nochmal neu durcheinander.
Ich arbeite jetzt da mit größeren Gruppen, meistens so vier bis sechs Leute beispielsweise, oder drei bis vier Leute, je nachdem, wie viele Personen ihr da in so einem Workshop habt.
Und denen gebe ich jetzt nochmal so eine Viertelstunde, ca. vielleicht 20 Minuten, dass die mal Entscheidungsvorschläge ableiten.
Das nehmen wir, das nehmen wir, das nehmen wir.
Und wir sollten vielleicht schauen, dass an jedem der Boards zwei Gruppen waren.
Ich lasse mal anders formulieren, dass jedes Board von mindestens zwei Gruppen da besucht wurde.
Dass wir wirklich eine nennenswerte Anzahl an Leuten haben, die da draufgeschaut haben, die sich das angeguckt haben etc.
Auch hier wieder bitte die Gruppen cross-funktional besetzen.
Und immer schauen, dass eine gewisse Expertise von Leuten, die später von den Anforderungen betroffen sind, vertreten sind in den Gruppen.
Dass die da eben, ich sage mal, Entscheidungen treffen.
Und das Endergebnis ist halt, dass wir gewisse Duplikate aussortiert haben.
Duplikate tun wir halt weg.
Das ist eigentlich total ähnlich, das brauchen wir nicht.
Und dass die jetzt sagen, okay, das ist jetzt so ein potenzieller Entscheidungskandidat.
Mit dem Ding würden wir jetzt einfach nach vorne schreiten.
Da kann es natürlich krasse Meinungsverschiedenheiten geben.
Die würde ich, ich sage mal so, die können wir vielleicht dann in der großen Gruppe diskutieren oder die nehmen wir dann einfach mal raus und sagen, hey, das kriegen wir jetzt in dem Workshop nicht diskutiert.
Da müssen wir fünf oder sechs Leute uns einfach nochmal zusammensetzen, das nochmal aufrollen etc.
Aber ich würde da jetzt nicht mich in irgendwelche nitty-gritty Detaildiskussionen für zwei, drei ganz spezifische Requirements einlassen.
Erfahrungsgemäß ist es so, dass man eigentlich in der Breite der Gruppe 80, 90 Prozent der Dinger relativ klar benannt bekommt.
Dass man sagt, das ist jetzt eigentlich gut genug, das passt, damit gehen wir jetzt mal weiter.
Und das ist sozusagen dieses Ende der Konsolidierungsphase, die wir da haben.
Das wären aber dann Architekturentscheidungen, wo, ich sage mal so, wenn man dann in großem Grad an Verbindlichkeit reinbringen will, wo man den Leuten schon sagen soll, hey, auf der Basis werden die Software Engineers und die Architektinnen und Architekten später Entscheidungen treffen.
Also wenn die beispielsweise überlegen, machen wir jetzt Integration mit RESTful HTTP-Feeds oder auf Basis von Apache Kafka, werden die da drauf schauen und diese Architekturentscheidungen da dagegen legen.
Oder die werden auch sagen, hey, wir haben diese Anforderung, haben wir dazu bewusste Architekturentscheidungen getroffen.
Da kann man schon einen gewissen Verbindlichkeitscharakter mit reinbringen. Überstresst es aber nicht, dass die Leute sich nicht trauen, Entscheidungen zu treffen.
Das ist immer wieder Sache, natürlich.
Aber auch hier wieder halte ich agile Ideen, kontinuierliches Dazulernen, natürlich für die gute Seite, dass man sagt, okay, das ist jetzt mal erst mal Wurst, da fangen wir mal an, Entscheidungen zu treffen.
Wenn wir aber später herausfinden, dass das nicht gegeben ist, nehmen wir uns die Freiheit, da punktuell noch mal nachzujustieren.
Und dann kommen wir zur Priorisierung.
Genau, sorry.
Und das ist eben auch die Möglichkeit, diese Kollaboration überhaupt einzuüben, sozusagen.
Genau.
Gut, und dann kommen wir zur Priorisierung.
Da wolltest du gerade ansetzen.
Richtig, genau.
Bei der Priorisierung gehe ich üblicherweise her und arbeite mit einer Technik namens Dot Voting für diese ganzen Kollaborationstechniken.
Das wäre vielleicht auch noch mal ein ganz guter Link in die Shownotes.
Es gibt eigentlich ein ganz spannendes Buch, das ist schon uralt, das nennt sich Gamestorming, wo verschiedenste Techniken für Moderationen, Facilitation etc. beschrieben sind.
Das Dot Voting ist beispielsweise eines davon.
Da kriegt jede Person so einen Klebezettel in die Hand.
Und ich würde mal sagen, glaubt mal, dass ihr jeder Person so einen Klebezettel für 15 bis 25% der Qualitätsanforderungen in die Hand drückt.
Also wenn ihr jetzt 100 Anforderungen habt, würde ich den Leuten mal so 15, 20 Klebepunkte an die Hand geben.
Und die sollen dann rumrennen und markieren, welche der Anforderungen sind für sie von ganz besonderer Priorität.
Was sind so die Top 15, 20, 25% der Anforderungen, die wirklich ganz, ganz wichtig sind für die Fachlichkeit, für das Produkt, für das System beispielsweise.
Und da kriegt man eigentlich ganz gute Tendenzen raus, was besonders wichtig ist, was unwichtig ist.
Und vielleicht fragen sich jetzt ein paar von euch, warum brauche ich die Priorisierung überhaupt?
Und ich glaube, das liegt eigentlich an der schwersten Tätigkeit der Softwarearchitektur.
Ich zitiere da ein bisschen den Neil Ford in seinem Softwarearchitecture, The Hard Parts oder auch seinem entsprechenden Vortrag.
Das Navigieren von Trade-offs ist eigentlich mit das Schwierigste in der Tätigkeit einer Softwarearchitektin oder einer Softwarearchitektin.
Und so eine Priorisierung bei Qualitätsanforderungen kann es uns punktuell, situativ erleichtern, mit solchen Trade-offs eben umzugehen.
Dass ich eben sage, ich habe hier eine Architekturentscheidung, die hat einen positiven Einfluss auf diese fünf Qualitätsanforderungen, aber einen negativen Einfluss eigentlich auf zwei andere Qualitätsanforderungen.
Und das ist ehrlich gesagt jetzt kein exotischer Fall.
Ich glaube ehrlich gesagt, das ist etwas, was ihr in der Architekturarbeit laufend haben werdet.
Mit einer Priorisierung könnt ihr dann sehen, ist der positive Einfluss auf drei sehr hochpriori Qualitätsanforderungen und der negative Einfluss auf zwei extrem niedrig priori Anforderungen, dann kann die Entscheidung wahrscheinlich trotzdem ganz okay sein.
Ist es genau andersrum, würde ich meine Architekturentscheidung vielleicht einmal wieder überdenken und sagen, naja, das ist jetzt eigentlich nicht so gut.
Da müssen wir uns was anderes einfallen lassen.
Und dafür machen wir das.
Also sozusagen das Endeergebnis, das finale Ergebnis ist dann quasi so eine Liste aus priorisierten Anforderungen.
Und die können wir ja dann auch überführen, später nochmal weiter formalisieren, noch schärfen.
Aber dann müsstet ihr, glaube ich, eine ganz gute Basis haben für künftige Architekturentscheidungen.
Wenn man das mal so zusammenfasst, wir haben die Vorbereitung, die Broad Collection, die Konsolidierung und dann die Priorisierung am Schluss.
Ich glaube, da müsste eigentlich dann was rauskommen, was deutlich besser ist wie irgendwie so Sachen.
Keine Ahnung, das System muss halt schnell und skalierbar sein und muss toll aussehen und auf allen Browsern der Welt funktionieren und 24-7 mit 99,99999% verfügbar sein.
Mehr will das gar nicht sein.
Das ist jetzt keine Silver Bullet, diese Methode, sondern halt eine situative Verbesserung.
Ich würde mal sagen, insbesondere für komplexere Projekte im Vorhaben.
Ich mache jetzt den Screenshot mal wieder aus.
Genau, vielen Dank erstmal so weit.
Es gab jetzt von dem Torsten Irlender, dem schon zitierten bei LinkedIn noch einmal die Frage, wie sinnvoll es ist, die zu priorisieren.
Das hast du, glaube ich, beantwortet.
Also mit Dot Voting kann man das einfach machen.
Und er hat noch vorgeschlagen, also er hat sich die Frage gestellt, ob man das durch eine relative Schätzung machen würde.
Ich glaube, das ist das, was du gezeigt hast.
Oder durch Moscow.
Und Moscow steht für Must, Should, Could oder Won’t, dass man die ja sozusagen kategorisiert.
Hast du dazu eine Meinung?
Also es wäre ein anderes Verfahren, dass man jetzt irgendwie sich…
Einfach ein anderes Verfahren.
Habe ich bis jetzt persönlich nicht ausprobiert.
Möchte ich aber jetzt nicht ausschließen, dass das eine doofe Idee wäre.
Also das könnte man mal durchaus ausprobieren.
Habe ich bisher aber so noch nicht gemacht.
Ich habe bisher ausschließlich mit dem Dot Voting gearbeitet.
Also ich glaube, das ist auch so ein Aspekt von diesen…
Also wenn man halt sagt, dass die Verfahren nicht so super formalisiert sind, dann kann man sowas eben noch ausprobieren.
Dann hat er noch die Frage, darüber hätten wir uns im Vorhinein kurz unterhalten, wie viele Kriterien sind genug?
Reichen die Top 3?
Muss gestehen, dass ich das…
Ich hatte halt gedacht, sozusagen drei Moderationswände zu drei Qualitätsthemen, sozusagen, ob das genug ist.
Ich bin mir jetzt nicht mehr sicher.
Eigentlich kommt ja jetzt raus eine komplett durchpriorisierte Liste.
Und das ist irgendwie mehr als die Top 3.
Ich weiß nicht, wie du das siehst oder was du dazu noch sagen willst.
Ich würde mir jetzt nicht auf Top 3 jetzt hier drauf festlegen.
Ich würde eher sagen, ich würde einfach mit Prior arbeiten.
Das ist sehr wichtig.
Das ist eher weniger wichtig.
Das hat vielleicht eine mittlere Priorität.
Und ich glaube, das hilft eigentlich mehr, wie jetzt nur auf drei Kriterien zu schielen und dann eben den Rest zu ignorieren.
Ich glaube, das würde ich nicht machen.
Ich würde eher mit einer Priorisierung arbeiten.
Und es ist auch die Frage, wie aufwendig das ist, bestimmte Kriterien zu erfüllen.
Heute können ja Sachen sein, die total easy sind und Sachen, die super aufwendig sind.
Da muss man sich die Karten legen.
Es gab dann noch hier eine Diskussion, die zwei Aspekte hat.
Hamburg hat vor einiger Zeit losgelegt und gesagt, im Grunde ist doch diese Diskussion vor Projektbeginn unerlässlich.
Beispiel Skalierbarkeit kann ein enormer Kostentreiber sein.
Ohne eine Klärung dieser Qualitätspunkte kann doch kein Budget geschossen werden.
Daraufhin hat der Raimund Klein gesagt, das passiert aber in der Praxis oft genug oder bei langlebigen Systemen ändern sich solche Anforderungen im Laufe der Jahre auch mal.
Darf ich da kurz was dazu sagen?
Ja, genau.
Das war die Intention.
Also erstens mal, ich stimme allen zu, dem Hamburg und dem Raimund.
Ich würde auch dringend dazu raten, die Ergebnisse dieses Workshops, gerade bei langlebigen Systemen, immer mal wieder auf den Prüfstand zu stellen.
Also beispielsweise brauchen wir wirklich eine bestimmte Skalierungsanforderung, brauchen wir wirklich bestimmte Security-Anforderungen, brauchen wir wirklich bestimmte UX-Anforderungen, Wartbarkeitsanforderungen.
Also beispielsweise, man schreibt ein Modul X, neue Anforderungen muss innerhalb von fünf Tagen umsetzbar und produktivstellbar sein.
Kann man mal retrospektiv überlegen, wie oft haben wir das in der Vergangenheit wirklich benötigt.
Vielleicht Bereiche, wo wir sagen, da haben wir was übersehen, es passiert, es kommt vor.
Ich glaube auch, dass sich die Anforderungen vom Markt, in dem so ein System betrieben wird, im Laufe der Zeit ändern.
Also ich würde es immer mal wieder auf den Prüfstand stellen.
Also ich habe beispielsweise schon Umfelder erlebt, die sowas einmal im Jahr einfach auf den Prüfstand stellen und sagen, hey, was sind denn jetzt aktuell die Anforderungen, was sind auch unsere Erkenntnisse aus dem produktiven Betrieb.
Ich glaube, der produktive Betrieb von solchen Anforderungen kann ein unschätzbarer Quell an erstens mal Realitätsüberprüfung sein, aber auch vielleicht so, hey, da haben wir was übersehen.
Da haben wir eigentlich eine Anforderung, die man so explizit noch gar nicht berücksichtigt.
Und da gibt es eben auch Ansätze wie Atom, die eben sagen, ich gucke mir mal die Qualitätsszenarien an, um dann irgendwie anschließend auf eine Idee zu kommen, ob das System eigentlich die aktuellen Qualitätsszenarien noch erfüllt und das ist so ein Architektur-Review-Ansatz.
Warte mal noch einen Satz.
Will ich jetzt sagen, ihr müsst jetzt dieses Ding, was wir da haben, alle drei Monate, alle sechs Monate, alle zwölf Monate durchführen?
Nein, würde ich gar nicht sagen.
Also nicht selten sehe ich es, dass man sagt, okay, das sind jetzt unsere Anforderungen, die haben wir jetzt auf dem Board, beispielsweise auf irgendeinem Konzept, miro, schieß mich tot.
Und wir gehen da einfach nochmal alle miteinander, aber alle zusammen drüber und überprüfen die.
Das kann durchaus sein.
Oder man geht da mal her und macht nach zwei, drei Jahren wirklich nochmal from scratch so eine Sache und schaut mal, was ist denn jetzt rausgekommen mit unseren jetzigen Erfahrungen.
Ich glaube, kollaboratives Modellieren ist auch ein ganz starker Katalysator für das gemeinsame Sammeln von Erfahrungen, für das gemeinsame Weiterentwickeln von Perspektiven.
Und manchmal ist es ganz spannend, was dann, wenn man das mal ein bisschen aktiver betrieben hat, zu was dann solche Teams in drei Jahren oder sowas fähig sind.
Also da kann das schon mal Sinn machen.
Und ich glaube, ehrlich gesagt, bezüglich dieses Kostenfaktors, wenn sowas mal gut angelaufen ist, tritt der erfahrungsgemäß ein bisschen in den Hintergrund.
Genau, der Superman02 hat auch noch eine interessante, finde ich, Bemerkung.
ManBlackwolf bei Twitch hatte noch geschrieben, Moskau ist was wir im Unternehmen nutzen.
Und der Superman02 hat noch geschrieben, für mich klingt das jetzt irgendwie wasserfallartig.
Passen kleine Scrum Teams und Agilität im Allgemeinen in dieses Vorgehen?
So ein bisschen, glaube ich, was du schon vorhin diskutiert hast, aber ich weiß nicht, gibt es da noch irgendwie eine Antwort drauf?
Warte, ich glaube, dein Video ist weg.
Ja, ich habe es gesehen, genau.
Ich würde sagen, das will explizit nicht wasserfall sein, sondern ich möchte ganz klar dazu plädieren, dass wir sowas auch regelmäßig machen können.
Das hatte ich vorhin auch schon gesagt, dass wir Qualitätsanforderungen auch regelmäßig auf den Prüfstand stellen sollen.
Dieser Workshop, den kannst du total gut in einem agilen Kosmos machen, aber bis du in der Organisation, die wasserfallmäßig läuft, kann man da erstmal was an die Rampe stellen.
Aber ich glaube, ehrlich gesagt, wenn man mal Wasserfall sehr strikt betrachtet, ist sogar das, was da rauskommt, ich weiß nicht, ob ich damit bis zum Sankt-Nimmerleins-Tag arbeiten möchte, sondern der Fokus ist eigentlich schon eher darauf, dass wir einen ersten Wurf haben, ein erstes gemeinsames Verständnis, was wir danach auch gemeinsam weiterentwickeln würden.
Und ich glaube, ehrlich gesagt, schon, dass diese gerade kollaborative Modellierung zehrt ja sehr, sehr stark aus den Werten der Agilität.
Eines der Prinzipien aus dem Agile Manifesto lautet ja, Businesspeople and Developers must work daily together throughout the project.
Das ist eine Methode, wie wir diese gemeinsame Zusammenarbeit eigentlich bewerkstelligen können.
Aber natürlich kannst du mal sagen, wir machen so einen Workshop, Wasserfall, zack, fertig, klar.
Das ist meine Präferenz, definitiv nicht.
Ja, und vielleicht eine Sache, die ich da noch gerne ergänzen würde.
Es spricht nichts dagegen, am Anfang eines Projekts sich ernsthaft über Anforderungen zu unterhalten.
Diese sollten nur nicht fixiert sein.
Und es ist nicht so, dass im Agile Manifesto steht, wenn wir am Anfang eine Vielzahl an Anforderungen haben, dann ignorieren wir das.
Sondern im Gegenteil, das ist etwas, was durchaus hilfreich sein kann.
Und das ist ja auch das, was hier rauskommt.
Ich fange am Anfang an, ich mache diesen Workshop, da habe ich vielleicht gar keine Ahnung, wenn ich Techniker bin.
Und dann komme ich später dazu und habe eine bessere Idee und komme schrittweise weiter.
Und kann es dann nachschärfen.
Es ist einfach so, dass ich am Anfang möglicherweise nicht weiß, was los ist.
Und dann muss ich mehr machen.
Und später mache ich weniger, weil ich die ganze Vordiskussion hatte.
Gut.
Fragen sind jetzt im Chat keine mehr.
Ob ich meine Kamera noch mal zum Laufen kriege, weiß ich im Moment gerade nicht so genau.
Dann würde ich sagen, wenn sonst keine Themen sind, vielen Dank.
War total spannend.
Nächste Woche gibt es wieder eine Episode.
Thema ist noch offen.
Also wenn Vorschläge da sind, sehr gerne.
Und ich weiß nicht, ob du noch abschließende Worte sagen möchtest.
Also ein Bitte.
Also wenn ihr das mal bei euch ausprobiert und Erfahrungen gesammelt habt, teilt die total gerne.
Ich bin da immer sehr gespannt, welche Erfahrungen ihr damit sammelt, etc.
Ihr könnt mir auf LinkedIn, etc.
Mastodon jederzeit mal anhauen und sagen, hey, Michael, wir haben das ausprobiert.
Das ist total gut gelaufen.
Oder wir haben da die und die Schwierigkeiten gehabt.
Also ich will da auch sehr gerne kontinuierlich dazulernen, was da funktioniert und was da nicht funktioniert.
Also jederzeit gerne.
Genau.
Und das ist, glaube ich, exakt das, was der Nicktune letzte Woche auch gesagt hat.
Also wir sind, glaube ich, alle jederzeit sehr dankbar für ganz viel Feedback, Informationen, offene Kommunikation usw.
Dann vielen Dank und schönes Wochenende.
Vielen Dank.
Ja, tschüss.