Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Ja, hallo und herzlich willkommen zu einer neuen Folge von Software-Architektur im Stream.
Heute habe ich Peter Ruschka als Gast.
Er beschäftigt sich vor allem mit Requirements und ganz vielen anderen spannenden Themen.
Peter, möchtest du dich gerade mal vorstellen?
Ja, danke, Ralf.
Wie gesagt, Peter Ruschka, mein Name, gebürtiger Österreicher, der direkt nach dem Studium in Wien dann in das schöne Städtchen Aachen ausgewandert wurde.
17 Jahre lang, 18 Jahre lang in einem großen System- und Softwarehaus und inzwischen seit über 30 Jahren selbstständig.
Beruflicher Hintergrund
In meinem ersten Arbeitsvertrag stand Systemanalytiker als Berufsbezeichnung.
Und ich hatte keine Ahnung, weil wir an der Uni zwar programmieren gelernt haben und jede Menge über Software-Technologie, aber nichts über Requirements Engineering oder Business Analysis.
Ich hatte mir allerdings vorgenommen, im Rest meines Lebens herauszubekommen, worum es bei diesem Thema geht.
Und ich glaube, das ist mir in den letzten 45 Jahren auch ganz gut gelungen.
Ja, sehr gut.
Wir sehen uns ja auch Ende November auf dem Software Architecture Gathering in Berlin.
Ich bin froh, dass ich dich jetzt hier vorab auch schon im Gespräch habe.
Für alle, die Interesse an dem Gathering haben, in den Show Notes werden wir einen 15% Coupon Gutschein verlinken, damit die Entscheidung dann vielleicht nochmal leichter fällt.
Du hast jetzt Requirements schon angesprochen.
Du hast das RAC 42 Template in die Welt gebracht.
Möchtest du mal einen kurzen Überblick geben?
Vielleicht ein bisschen zum Hintergrund.
Meine englischen Kollegen von der Atlantic Systems Guild, James und Susanne Robertson, haben vor vielen Jahren ein Requirements Template auf den Markt gebracht, das inzwischen in der 22.
Version ist, namens Volere.
Das sind 27 Schubladen, die man füllen sollte, wenn man Requirements macht.
Ich habe danach mit Gernot Scharke das Äquivalent dazu für Architekten entwickelt, ARC 42.
Zur Beschreibung, das waren zwölf Schubladen für agile Architekturentwicklung.
Entstehung und Entwicklung
Und wir haben vor fünf, sechs Jahren begonnen, das Template meiner englischen Kollegen ein bisschen abzuspecken und auf die agile Welt anzupassen.
Und als Pendant zu ARC 42 haben wir es RAC 42 genannt.
Es hat auch zwölf Schubladen aufzuweisen, die teilweise überlappend mit ARC 42 sind, weil nicht alle Leute beides machen, sowohl Requirements wie auch Architektur.
Und manche Punkte einfach wichtig sind, dass man sie mit bedenkt.
Wenn man also beide zusammen nimmt, kann man einige Kapitel in jedem davon weglassen und hat immer noch den vollen Umfang.
Es ist ausgelegt für Agiles Requirements Engineering und ich glaube, Claim to Fame ist, dass seit 20 Jahren suggeriert wird, dass ein bisschen Backlog-Pflege und Umgang mit funktionalen Anforderungen und Storys genug ist.
Und der Meinung bin ich nicht.
Da fehlen viele andere Sachen rundherum und deshalb hat RAC 42 mehr als eine Schublade, nämlich nicht nur den Product Backlog, sondern noch viele andere Sachen, die man braucht.
Insbesondere auch Qualitätsanforderungen, insbesondere Randbedingungen, aber auch die Management Aspekte.
Ich brauche für Projekt- oder Produktentwicklung sicherlich irgendwo Geld und ein Team.
Auch darüber sollte man Bescheid wissen.
Ich brauche eine Roadmap, wie wir vorgehen wollen.
Ich brauche vielleicht eine Risikoliste und alle diese Schubladen sind in RAC 42 auch enthalten.
Das finde ich jetzt ganz spannend, weil du sagst ja eigentlich dieser agile Ansatz.
Wir haben einen Backlog, wir haben User Storys, das ist schon Requirements Management, aber es ist nicht ausreichend.
Da fehlt noch einiges.
Die Qualitätskriterien, die ich ja auch von RAC 42 kenne, dort sehr schätzen gelernt habe.
Sind das die gleichen Qualitätskriterien wie in dem RAC 42 oder haben die eine andere Sicht auf die Dinge?
Qualitätskriterien
Nein, das sind genau die gleichen, die wir auch in RAC 42 drin haben.
Bedeutung für die Industrie
Dahinter verbirgt sich unsere Einsicht in die industrielle Welt, dass zwar viele Teams und viele Firmen ganz gute funktionale Anforderungen haben, aber dass in vielen Unternehmen an den Qualitätsanforderungen geschlampt wird.
Eigentlich sind das Anforderungen, das sind Requirements.
Wenn aber die Product Owner oder Business Analysts sie nicht liefern, dann bleibt die Arbeit bei den Architekten.
Und deshalb haben wir sie auch in RAC 42 drinnen.
Ich würde sie auf jeden Fall als ganz wesentliches Kapitel auch zu den Requirements zählen.
Und dann kann man in RAC 42 viel Zeit und Geld sparen, wenn man gute Voraussetzungen geliefert bekommt.
Ist leider nur zu selten der Fall.
Wow, das heißt also, bislang habe ich immer mit RAC 42 gearbeitet, habe dann immer so diesen Ärger.
Wo kriege ich jetzt die Qualitätskriterien her?
Im Idealfall hat dann jemand schon Requirements mit deinem RAC 42 Template vorher erarbeitet und hat die Qualitätskriterien, die ich dann in die Architektur einfach übernehmen kann.
Richtig?
Richtig.
Aber die Beobachtung von Gernot Starke und mir ist, dass es zu selten in der Industrie basiert.
Gernot sagt immer, er hat die letzten zehn Jahre kein Projekt gehabt, wo er halbwegs gute Anforderungen bekommen hat.
Bei mir sieht es anders aus.
Ich arbeite sehr oft in der Embedded-Industrie und gerade bei größeren Hardware-Software-Projekten ist die Requirements-Phase anständig ausgeprägt und die meisten Firmen nehmen das ernst.
Denn in die Entwicklung von neuem Flugzeug oder neuem Auto oder großen Hochregallagern oder militärischen Utensilien, da sind die Anforderungen meistens ganz gut definiert.
Das heißt, ich habe das Glück, in meinem Umfeld immer wieder mal gute Product-Owner und gute Requirements-Engineers oder gute Business-Analysts vorzufinden.
Bei Gernot ist das immer ein großer Mangel.
Das liegt dann wahrscheinlich tatsächlich daran, dass wir in der Software-Industrie, wenn wir schlampen, dann fällt das nicht ganz so auf.
Das ist ein Bug und der wird nachträglich gefixt.
Wir liefern nicht mehr auf CD aus, sondern wir haben immer noch Zugriff auf unsere Software und können es ändern.
Embedded, da wird es schwieriger.
Lass mich ein Beispiel geben.
Wenn wir eine Getriebesteuerung entwickeln, dann wird die in ein Fahrzeug eingebaut und soll da drinnen die nächsten 18 Jahre, was so die durchschnittliche Lebensdauer eines Pkw ist, funktionieren.
Natürlich kann es da auch Updates geben.
Heutzutage muss man dafür nicht unbedingt mehr in die Werkstatt fahren.
Das geht auch over the air.
Aber im Wesentlichen möchte ich mein System nicht dreimal am Tag patchen müssen, sondern solange das Auto in Betrieb ist, soll auch das System funktionieren.
Das ist eine andere Welt als die, wo man am Tag 20 Mal deployed.
Zählen dann zu den Requirements in der Embedded Welt, mit denen du zu tun hast, dann auch die Hardware Anforderungen oder bezieht sich das dann nur auf die Software, die auf der Hardware zum Laufen gebracht wird?
Ich bin ein großer Fan von Systemdenken und ein System besteht halt heutzutage nicht nur aus Software, sondern Software, Elektronik, Mechanik und vielen anderen Technologien.
Ich fange immer mit den Gesamtanforderungen an das System oder an das Produkt an, weil ich die Entscheidung offen lassen möchte, wie viel davon wird in Hardware gemacht?
Was wird in Software gemacht?
Was wird in Mechanik gemacht?
Das ist eine Entscheidung, die man vielleicht erst in der Systemarchitektur trifft, lange bevor man dann über Software Requirements und Software Architektur spricht.
Jetzt habe ich schon herausgehört, dass das Backlog und die User Stories Requirements sind Teil der Requirements.
Jetzt hat man sehr viele unterschiedliche Begriffe und mir fallen bei Requirements auch immer die Spezifikationen ein.
Und wenn ich jetzt so an Hardware denke, dann sehe ich da schon einen ganz guten Unterschied in diesen Begriffen Spezifikation und Requirements.
Mir begegnet jetzt das Wort Spezifikation auch immer in Sachen Spec Driven Development mit der KI.
Wie siehst du diese Begriffe?
Wie ist das Zusammenspiel dieser Begriffe?
Requirements ist der allgemeine Begriff.
Jemand hat Anforderungen oder Wünsche oder Bedürfnisse.
Requirements Engineering Prozess
Und die vier Haupttätigkeiten im Requirements sind erstens herauskitzeln, was die Anforderungen überhaupt sind.
Das hat man früher nur über Interviews gemacht.
Inzwischen kennen wir 15, 20, 30 verschiedene Techniken, um auf Anforderungen draufzukommen.
Zweitens, ich muss sie spezifizieren, dokumentieren.
Wenn man nicht wie bei Extreme Programming den Anwender auf den Schoß des Programmierers setzt und das alleine erzählen lässt, dann brauche ich irgendeine Aufzeichnung meiner Requirements und da kommen Spezifikationen ins Spiel.
Ich brauche Requirements Dokumentation.
Das dritte ist, ich muss sie überprüfen und verifizieren, ob die zusammenpassen hinten und vorne.
Und das vierte ist, ich muss sie im Laufe der Zeit managen, weil Anforderungen ändern sich mit ein bis zwei Prozent pro Monat.
Und wenn man glaubt, die auf ein Jahr festzuschreiben, hat der Kunde meistens 25 Prozent andere Wünsche, auch wenn er sie ursprünglich genannt hat.
Spezifikation ist also nur der zweite Punkt.
Zuerst muss ich sie finden, dann kann ich sie spezifizieren, dann kann ich sie prüfen und konsolidieren und dann muss ich sie im Laufe der Zeit verwalten.
Das spezifizieren ist heute ein bisschen zurückgegangen.
Dokumentation
Früher hat man dicke Pflichten und Lastenhefte geschrieben als Niederschrift der Requirements.
Agile Methoden
Heutzutage im agilen Bereich wird weniger geschrieben, dafür aber hoffentlich mehr miteinander gesprochen.
Beides kann ich nicht weglassen.
Also wenn ich nicht schreiben will, muss ich mehr reden.
Und wenn ich nicht reden will, dann muss ich mehr schreiben, insbesondere bei Offshore-Entwicklung und ähnlichem.
Aber wenn man jetzt mehr redet als schreibt, dann erzeugt man zwar ein System, hat aber hinterher nicht mehr die Requirements, aus denen das Ganze entstanden ist.
Traceability ist dann auf jeden Fall irgendwie weg.
Ich glaube, wir kennen alle diese Legacy-Systeme.
Das heißt, das muss mal erneuert werden.
Und wenn man Glück hat, findet man noch irgendwo 18 Jahre alte Aufzeichnungen.
Wie siehst du das Thema?
Wie wichtig ist da die Dokumentation?
Ich glaube, das ist sehr unterschiedlich zu betrachten.
Wenn es mir nur darum geht, ein System möglichst schnell an den Markt zu bringen, dann muss ich nicht unbedingt viel aufschreiben.
Dann interessiert mich das endgültige Produkt einfach mehr, als mich die Anforderungen interessieren.
Wenn man ein Produkt entwickeln möchte, das jahrelang weiter gepflegt und weiterentwickelt wird, dann möchte ich die alten Anforderungen nicht verlieren.
Denn es ist leichter, neue Anforderungen zu ergänzen, als das Rad neu zu erfinden.
Und wenn dann nichts mehr von den Anforderungen da ist, fängt man jedes Mal wieder bei Adam und Eva an.
Insofern wäre es schon gut, denn die Anforderungen in einer Branche sind meistens langlebiger als die Lösungen.
Ich habe schon mal neue Technologien.
Ich baue das Ganze mit anderen Oberflächen oder anderen Persistenzsystemen.
Aber eine Firma ändert nicht täglich ihre Branche.
Wenn ich heute Bäcker bin, bin ich auch morgen Bäcker oder übermorgen Bäcker.
Und da kommen nur neue Brötchensorten dazu oder neues Brot dazu.
Es wird variiert, aber es wird nicht grundsätzlich geändert.
Deshalb sind meistens die Requirements, die Anforderungen stabiler in einer Branche, als es die Lösungen sind.
Die Architekturen und so etwas.
Es aufzuheben, hat also viele Vorteile, dass man sich bei den nächsten Releases viel Arbeit sparen kann.
Das hört sich vernünftig an.
Jetzt bin ich meist in irgendwelchen agilen Projekten unterwegs und habe schon öfters so gehört.
Naja, die Spezifikation des Projekts ist ja quasi die Menge der Storys, die umgesetzt worden sind.
Ich muss dann immer mal kurz einatmen und überlegen, ob das so passt.
Wie siehst du das?
Kann man das so sehen?
Ja, im Prinzip schon.
Hierarchische Struktur
Seit 25 Jahren sind User Storys populär geworden.
Es gibt auch heute noch viele Leute, die dagegen hetzen und sagen, mit nur Storys, mit kleinen Storys, die man in 14 Tagen implementieren kann, kann man kein großes System spezifizieren.
Da fehlt der Überbau und deshalb haben modernere agile Requirements-Methoden meistens ein mehrstufiges Requirements-Konzept.
Da gibt es halt oberhalb der Storys noch die größeren Features.
Und bei SAFe, dem Scaled Agile Framework, liegen darüber noch Capabilities, die aus vielen Features bestehen, die wiederum aus vielen Storys bestehen.
Und ganz oben drüber findet man meistens noch Epics, die noch größer sind.
Diese Begriffe wie Epics und Features haben keine sattelfeste Definition.
Feature heißt nur zu groß für einen Sprint und Epic heißt zu groß für einen Release.
Das heißt, die Implementierung dauert länger als zwei, drei Monate und dann ist es halt ein Epic und kein Feature und keine Story.
Es wäre auch schön, wenn man sich diese Ebenen aufheben und pflegen würde.
Denn wenn ich alles auf Story herunterbreche, dann ist es so, wie wenn man einen großen Baum einfach fällt, die dicken Äste abhaut, die kleinen Ästchen abbricht, dann die Blätter einsammelt und einen großen Sack tut.
Und kein Mensch sieht mehr die schöne Struktur dieses Baumes, wie er vor uns steht, mit seinen großen Stämmern und Ästen und so weiter.
Also nur Storys machen ist wie ein Sack voll Blätter, ohne dass die Struktur des Baumes noch sichtbar ist.
Würde es dann Sinn machen, vielleicht, wenn man die Blätter eingesammelt hat, sie nochmal irgendwie richtig anzuordnen, dass man die Struktur wieder sieht?
Also sprich, reicht es, die Storys aufzuheben oder bringt es auch einen Mehrwert, wenn man eben das, was in den Storys so über die Zeit reinkommt, dass man das in eine Spezifikation, ein Requirements-Dokument irgendwie geordnet überträgt?
Manchmal hat man es ja auch so, dass sich etwas über die Storys shapet, dass die Architektur sich darüber verändern muss oder sowas.
Siehst du sowas in Projekten, dass man diesen Aufwand betreibt?
Ja, aber ich würde den nicht nachträglich betreiben, sondern ich würde ihn gleich beim Erfassen der Requirements betreiben.
Denn ich mache ein kleines Rechenexempel.
Geh mal davon aus, dein Produkt hat vielleicht zehn größere Epics, also verschiedene Bereiche, die du abdecken möchtest.
Und in jedem Epic gibt es vielleicht zehn Features.
Dann haben wir schon hundert Features da drinnen und für jedes Feature finden wir vielleicht zehn Storys.
Dann bist du bei tausend.
Ich möchte nicht die tausend aufheben, ich möchte die hundert und die zehn aufheben, damit ich bei einer Änderung an einem großen Epic genau weiß, ich muss auf das dritte Feature und davon möchte ich zwei neue Storys einfügen.
Wenn du diesen Überblick verlierst, suchst du immer in den tausend Storys, wo du vielleicht und hast keinerlei Zusammenhang mehr, wie die im größeren im Überblick überhaupt zu betrachten sind.
Das heißt, es ist wesentlicher, die Epics und die Features aufzuheben, als die Storys aufzuheben, weil das ist das, was langfristig als Rahmen für ein ganzes Produkt oder ein großes System da bleibt.
Und wenn ich heute über zehn, hundert und tausend gesprochen habe, in der Automotive-Industrie hat ein größeres Auto ungefähr 150 Teilsysteme drinnen und jedes Teilsystem hat so tausend bis neuntausend Anforderungen.
Also wenn wir ein ganzes Auto reden, dann reden wir über 150 mal im Schnitt 5000 Anforderungen.
Das sind halt doch größere Mengen.
Wenn ich nur den Scheibenwischer konstruiere, habe ich natürlich einen sehr überschaubaren Bereich.
Wenn ich ein ganzes Auto spezifiziere, habe ich sehr, sehr viel mehr an Anforderungen, die ich nicht verlieren möchte, wenn ich sie einmal schon strukturiert habe.
Dann möchte ich dieses Gerüst aufrechthalten.
Ich springe jetzt mal ein bisschen, weil du redest jetzt von tausenden Anforderungen und du hattest gesagt, es gibt verschiedene Möglichkeiten, an diese Anforderungen heranzukommen.
Hast du da so ein paar Lieblingsbeispiele, wie man die Anforderungen erarbeiten kann?
Ja, das persönliche Gespräch mit den Leuten, die die Wünsche haben, heute in Neudeutsch meist Stakeholder genannt, ist natürlich eines der wichtigsten.
Ich brauche eine Stakeholder-Liste, übrigens auch eines der Kapitel in REC 42, zu wissen, wer überhaupt Anforderungen an das System hat.
Und das sind mehr als nur unsere User.
Da kommen die Juristen dazu, da kommen Techno-Experten dazu, da kommen Umweltexperten dazu, da kommen viele, viele andere rein, unter Umständen aber Dutzende.
Also Stakeholder sind diejenigen, die Anforderungen haben und das Gespräch mit denen über ihre Anforderungen, nachdem ich hoffentlich die Stakeholder priorisiert habe.
Denn jemand, der sehr, sehr wichtig ist für dieses Produkt, hat vielleicht auch die wichtigeren Anforderungen als jemand, der auf Priorität 87 steht in dieser Stakeholder-Liste.
Also ist immer noch das Wichtigste, mit Leuten zu reden.
Bei manchen Sachen nützt es aber nichts, weil unter Umständen – wir haben so ein Bonbon entwickelt – gib den Kunden nicht das, was sie dir sagen, sondern gib ihnen das, was sie wirklich brauchen.
Und manchmal können sie das, was sie wirklich brauchen, gar nicht äußern.
Sie sagen etwas, aber durch ihre bisherige Welt eingeschränkt und das Kunststück eines guten Requirements-Ingenieurs ist herauszubekommen, was die wirklich brauchen und nicht das, was sie dir erzählen.
Das ist diese Geschichte mit Henry Ford und den schnelleren Pferden, oder?
Ja, genau.
Das ist das bekannte Beispiel.
Die Leute hätten damals gesagt, gib mir schnellere Pferde.
Niemand hätte Auto gesagt.
Zumal es ja auch nicht genügend Kutscher und Chauffeure gab, wo man gesagt hat, so viele Autos werden wir gar nicht brauchen können.
Eine andere Möglichkeit, um auf Anforderungen draufzukommen, ist, den Leuten bei der Arbeit zuzusehen, was sie machen.
Denn manche Sachen werden einfach so mit einem verlängerten Rückenmark erledigt, ohne dass man viel darüber nachdenkt und das äußern kann.
Ich nehme als Beispiel immer, wenn du dir ein Auto kaufen möchtest, würdest du dem Autohändler sagen, dass man das auch abschließen können soll.
Das ist für dich eine Selbstverständlichkeit, würdest du überhaupt nicht erwähnen.
Aber du wärst sehr böse, wenn man das Auto hinterher nicht abschließen kann, wenn dir eines geliefert wird ohne diesem Feature.
Das siehst du aber, wenn einer ein Auto abstellt, dass er zusperrt.
Ja, das Abschließen ist jetzt was sehr Offensichtliches.
Ich habe mal gehört, dass wenn nicht genügend Getränkehalter vorhanden sind, dass der Kunde auch sehr unzufrieden ist.
Das fand ich spannend.
Möglicherweise, ja.
Also den Kunden zugucken, ich glaube, heißt das nicht im Toyota Production System Gimbal Walk, dass man eben mal, nee, das ist die Produktion, das ist nicht beim Kunden gucken, sondern in der Produktion gucken, was man optimieren kann.
Eine andere Art ist, wenn du große und viele Leute hast, die da mitreden wollen, über Fragebogen ranzugehen, schick doch einen Fragebogen raus und hol dir Mehrheitsmeinungen ein.
Auch nur eine von den Techniken, die man anwenden kann, setzt allerdings voraus, dass man schon vorausgedacht hat, was die vielleicht alles haben wollen.
Denn ansonsten kann ich die Fragen nicht formulieren.
Und da gibt es so Feinheiten wie, soll ich Multiple-Choice-Fragen stellen, wo die nur noch ankreuzen müssen, was sie haben wollen, oder stelle ich offene Fragen.
Und die Erfahrung zeigt, Multiple-Choice kriegst du mehr Bögen zurück, weil das ist einfach auszufüllen.
Bei offenen Fragen hörst du aber viel deutlicher, was dir wirklich am Herzen liegt.
Aber nicht viele Leute sind bereit, da einen ganzen Satz hinzuschreiben.
Also auch immer wieder die Abwägung, wenn ich schon Fragebogen verwende, wie mache ich es dann?
Und, und, und.
Von der Sorte gibt es noch 15, 20 andere Techniken, inklusive sehr vielen Kreativitäts- und Innovationstechniken, wie zum Beispiel verschiedene Arten von Brainstorming, um auf neue Ideen draufzukommen, die ganz neue Produkte entwickeln.
So wie du das jetzt alles erzählst, kann ich mir schon vorstellen, warum das Requirements Engineering nicht so weit verbreitet ist, wie jetzt zum Beispiel einfach ein Backlog.
Da ist ja ein ziemlicher Aufwand dahinter, wenn man das eben richtig betreiben will.
Eben jetzt tatsächlich die Requirements, so wie du erzählst, irgendwie mal in Erfahrung bringen.
Das ist ja, wow, das ist wochenlange Arbeit, oder?
Ja, aber lass mich noch auf einen anderen Punkt, der oft vergessen wird.
Man schreibt so eine schöne User-Story in der Rolle, hätte ich gern die Funktion, damit ich diesen Vorteil habe.
Die ganzen Substantive, die da drinnen auftreten, unsere Domänenterminologie, ist die irgendwo definiert?
Oder muss man die einfach kennen, wenn man in einer Branche arbeitet?
Es wäre schön, wenn man so à la DDD, Domain Driven Design, die Kernbegriffe der Domäne auch irgendwo nachlesen könnte und schriftlich hätte.
Wird sehr oft vergessen, wenn man nur über User-Stories.
Und das fängt schon bei den Zielen oder bei den Visionen an.
Ich kann keinen Satz über ein geschäftliches Ziel formulieren, wenn die Begriffe da drinnen von allen Leuten anders verstanden werden.
Also auch das ist eines der Kapitel in REC 42, dass man sagt, definier doch bitte den relevanten Teil der Domänenterminologie.
Sollen keine 500 Begriffe sein, aber die 15, 20, 25 allerwichtigsten einer Branche, die sollten bitte schriftlich festgelegt sein.
Aber auch das ist wahrscheinlich wieder die hohe Kunst, die richtigen Begriffe rauszubekommen.
Ich habe mal die KI, du weißt, ich bin KI-Mensch mittlerweile, gefragt, was die KI von dem Glossar in Akt 42 hält.
Sie hat geantwortet, ist mir egal.
Ich kenne ja die ganzen technischen Begriffe, wo dann Gernot gesagt hat, ja, nee, darum geht es ja nicht.
Es geht um die Fachbegriffe.
Aber diese Fachbegriffe, ich meine, wenn man jetzt nicht in diesem Fachbereich so tief drin ist und man sich mit den Leuten unterhält, dann werden die wahrscheinlich auch Fachbegriffe teilweise vermeiden, wenn sie denken, naja, ich muss dem das jetzt irgendwie erklären.
Ich gebe dir eine meiner Lieblingsübungen, wenn es irgendwo schriftliche Requirements gibt.
Meine Lieblingsübung ist immer, 60 Prozent der Begriffe rauszustreichen und durch die richtigen zu ersetzen.
Denn in einer größeren Firma hat man garantiert für alles und jedes jeweils fünf bis zehn Begriffe, die das Gleiche bedeuten.
Und das dann zusammenzuführen und sich auf einen Begriff zu einigen und nicht jeder sagt anders zu dem, ist eine sehr beliebte Übung.
Da werden Spezifikationen wesentlich lesbarer, wenn man nicht über dauernd Synonyme und Homonyme reden muss.
Aber im Deutschunterricht hatte ich gelernt, ich sollte möglichst immer wieder andere Begriffe verwenden, oder?
Das habe auch ich im Deutschunterricht gelernt und ich war sehr gut im Aufsatzschreiben.
Und da sagt man eben nicht immer mein Herr Lehrer, sondern mein geistiges Vorbild, mein Idol, dem ich alles verdanke.
Aber dann habe ich Technik studiert und dann gewöhnt man sich hoffentlich die Synonyme ab und sagt nicht zu jedem Ding fünf verschiedene Wörter.
In der Softwareentwicklung haben wir ja auch so ein bisschen das Problem, wir wollen immer irgendwie alles Englisch schreiben, aber wir arbeiten in deutschen Projekten.
Und manchmal ist es dann echt schwierig, wenn sich deutsche Begriffe herauskristallisiert haben, die es so nur im Deutschen gibt, dann irgendwas Englisches zu finden.
Das eine Team übersetzt es anders als das andere.
Hast du da einen Tipp, wie man mit sowas umgehen kann?
Ja, das ist eines der großen und wirklich schwierigen Probleme, wenn wir über multisprachliche Projekte sprechen.
Denn es bleibt mir nichts anderes übrig, wenn wir in unserer normalen Welt Deutsch reden und dann aber mit englischen Vokabeln programmieren oder mit englischen Variablennamen arbeiten und ähnliches, dann brauche ich ein Übersetzungslexikon.
Und das zu pflegen ist zusätzlicher Aufwand.
Aber es gibt ein paar so Sachen.
Ich habe sehr viele internationale Projekte erlebt, die von deutschen Firmen mit internationalen Partnern gemacht wurden, wo wirklich die Firmensprache dann Englisch wurde.
Und das macht es schwieriger, genauer zu spezifizieren unter Umständen, weil wir uns dann in einer fremden Sprache bewegen, aber zum Teil auch einfacher, weil wir uns dann mit Indern und Chinesen und anderen Leuten zusammenraufen auf unsere 6000 Wörter Basic English und nicht so viele unterschiedliche Begriffe verwenden, wie es vielleicht in der normalen deutschen Sprache dann nuancierter ausgedrückt wird.
Wenn man sich zurückzieht auf eine Sprache, die alle als Fremdsprache gelernt haben, ist manchmal sogar leichter zu kommunizieren, als wenn einer in jedes Wort Bedeutung reinlegt und der andere versteht es nicht.
Also es hat Vor- und Nachteile.
Aber im Wesentlichen, wenn man mehrsprachig arbeitet, brauche ich ein Übersetzungslexikon.
Dann muss ich die Begriffe auch mehrsprachig pflegen.
Und das ist ungeliebter Aufwand, den keiner gerne macht.
Aber es hilft nichts.
Es muss dann sein.
Aber da sprichst du natürlich gerade ein Thema an, dass das Requirements Engineering wahrscheinlich im Near-Storing, Off-Storing seine Stärken ausspielt, weil ich da eben doch nicht den direkten Kontakt habe und das Gespräch suchen kann.
Und dann, ja, die Leute, die es umsetzen sollen, die haben dann auch teilweise schon aufgrund der Zeitzonen ein Problem, überhaupt mal nachzufragen, den Leuten über die Schulter zu gucken.
Das muss dann einer vor Ort machen.
Und da sind dann die Requirements wahrscheinlich echt Gold wert.
Es geht aber auch anders.
Mein Kollege von der Atlantic Systems, Steve McMahon, hat große Projekte in Kalifornien beim Stromversorger gemanagt.
Die Entwicklung war komplett in Indien.
Das erste Mal ist das total schiefgegangen, weil die Kommunikation zwischen Kalifornien und Indien einfach nicht funktioniert hat.
Die haben es hinterher organisatorisch gelöst, indem sie gegenseitig Brückenköpfe gebildet haben.
Das heißt, eine ganze Menge Inder in Kalifornien angesiedelt und eine ganze Menge Kalifornier nach Indien geschickt haben.
Dann konnte man in Kalifornien lokal miteinander reden, die Amerikaner mit den Indern.
Und die Inder haben das dann an die Inder übermittelt, die dann weit weg waren.
Und die wurden dort aber von Kalifornien wieder überwacht, ob sie es richtig gemacht haben.
Das heißt, mit so einer organisatorischen Maßnahme überbrückt man unter Umständen dann sowohl die Zeitdifferenzen wie auch die Kulturdifferenzen oder Sprachdifferenzen.
Da sind aber solche Maßnahmen notwendig, eine langfristige Zusammenarbeit im größeren Stil.
Und in dem Fall ging es um Tausende von Personenjahren, die an der Entwicklung geleistet wurden, um so etwas wirklich vernünftig hinzukriegen.
Das sind nicht nur Requirements-Methodik, das sind organisatorische Maßnahmen, die das Ganze unterstützen.
Spannend, vor allem die Größe der Projekte.
Wir haben jetzt viel über die Requirements und User Stories gesprochen.
In dem REC42 habe ich noch den Begriff PAM gelesen.
Purpose, Advantage, Metric.
Kannst du das darüber erzählen?
Ja, eines der oder drei der wichtigsten Kapitel in REC42 sind das, was wir Clean Start nennen, einen sauberen Anfang.
Und dazu gehört, Ziele definieren, wo will ich überhaupt hin.
Dazu gehört, die Stakeholder finden, die mitmachen dürfen.
Und dazu gehört, den Scope abgrenzen, was ist mein Bereich und was ist nicht mein Bereich.
Bei dem Bereich Ziele oder Visionen kommt das Schlüsselwort PAM ins Spiel für Purpose, Advantage, Metric, weil das eine Art ist, wie man Ziele definieren kann.
Sag, was du willst, den Zweck.
Sag, was habe ich davon, den Advantage und sag, wie ich es messen würde.
Und auch da bin ich ein bisschen im Widerspruch mit anderen Requirements-Büchern, die dann sagen, nein, nein, Ziele sind keine Anforderungen.
Das sind intentionale Aussagen, wo wir hinwollen.
Und meine Frage ist immer, was ist eine intentionale Aussage, wo wir hinwollen, anders als eine ganz wichtige Anforderung?
Selbstverständlich sind Ziele auch Anforderungen und PAM ist nur eine Art, wie wir Ziele spezifizieren können.
Eine andere Art, die in der agilen Welt sehr populär ist, um Produktkoffer zu zeichnen mit drei Schlagwörtern drauf, drei Marketingversprechen oder sogenannte Story from the future.
Heute einen Zeitungsartikel schreiben, wo man sich vorstellt, dass er am Tag nach der Freigabe des Produkts auf der Titelseite erscheint.
Aber ich schreibe die Story heute schon, wo ich stolz sein würde, wenn sie dann auf der Titelseite erscheint, warum unser Produkt so gut ist.
Auch das ist eine Art, vielleicht eine spielerische Art, um Ziele zu definieren.
Aber bitte, bitte niemals ein Produkt oder ein Projekt oder eine Systementwicklung anfangen, ohne Ziele zu haben.
PAM haben meine englischen Kollegen James und Suzanne Robertson eingeführt, zu sagen, schreib einfach drei, vier Kärtchen und überall steht drauf, was willst du, warum willst du es und wie würdest du es messen.
Dann hast du auch saubere Ziele.
Denn ein Projekt hat nur eine Handvoll Ziele und keine 10, keine 20 und keine 100.
Ich habe zwar viele Anforderungen, aber nur eine Handvoll Ziele und die sollten jedem Beteiligten klar sein, wo wir insgesamt hinwollen.
Ganz wichtiger Anfangspunkt.
Hört sich so ein bisschen an wie die dicken Äste, die du vorhin angesprochen hast, von dem Baum, dass ich die Ziele habe und dann an den Spitzen die Storys, die Blätter.
Ja, aber nicht nur die dicken Äste, denn die Ziele können natürlich auch qualitativ an Natur sein.
Ich möchte zum Beispiel sagen, dass alle Blätter voll von Chlorophyll und Schöngrün sein sollten, ohne dass ich für zählen Ast anfüge.
Mein Ziel ist es, den Baum im nächsten Jahr ganz gesund zu kriegen.
Und dann hätte ich ein Qualitätsziel für alle Äste natürlich.
Also Ziele können funktional an Natur sein, also ein dicker Ast.
Ziele können aber auch qualitativ an Natur sein.
Ich möchte zum Beispiel endlich die Usability verbessern, um von der Bashing-Sidetracks-Tool.de wegzukommen.
Ja, da sprichst du was an.
Du sprichst ja immer von den Qualitätszielen.
Ich sehe in vielen Projekten die nicht funktionalen Anforderungen.
Siehst du auch noch ganz viele nicht funktionale Anforderungen?
Weil für mich ist der Begriff Qualitätskriterien, Qualitätsziele dann doch irgendwie verständlicher.
Also ich weiß noch, als ich als junger Diplom-Informatiker angefangen habe und den Begriff nicht funktionalen Anforderungen gehört habe, ich konnte damit erstmal nichts anfangen.
Habe ich an der Uni so nicht gelernt.
Jetzt sprichst du ein Reizthema für mich an.
Ich habe in der dritten Auflage meines Requirements-Buches im Hansa-Verlag, ich gab an mindestens zehn Stellen gegen das Wort nicht funktionale Anforderungen gewettert.
Es ist ein Unwort, weil so wie du viele Leute nicht wissen, was nicht funktionale Anforderungen sein könnten.
Ich scherze eben und sage, sind es die Dinger, die hinterher nicht funktionieren?
Das ist natürlich nicht gemeint damit.
Der bessere Begriff und da hat der IREP, das International Requirements Engineering Board, gute Arbeit geleistet, ist diesen Begriff runterzubrechen in die beiden Gebiete Qualitätsanforderungen und Randbedingungen.
Die beiden zusammengenommen werden mit diesem Unwort bezeichnet, das ich eigentlich gar nicht aussprechen kann.
Aber Qualitätsanforderungen und Randbedingungen ist die klarere Aussage.
Qualitätsanforderungen haben wir schon angesprochen.
Randbedingungen sind entweder organisatorische oder technologische Anforderungen.
Bei den organisatorischen, ich muss mich an ein bestimmtes Vorgehensmodell halten, ich muss bestimmte Dokumente erzeugen und was auch immer die Organisation mir als Randbedingung vorgibt.
Bei den technischen Anforderungen, ich soll für die Lösung eine bestimmte Technologie einsetzen, zum Beispiel eine bestimmte Datenbank oder ein bestimmtes Framework.
Randbedingungen ist das, was dem Architekten die Hände fesselt.
Ich soll meine Anforderungen, meine funktionalen, meine Qualitätsanforderungen erfüllen.
Ich muss es aber innerhalb der Randbedingungen machen, die mir durch die Organisation oder durch Technologievorgaben gemacht werden.
Beides gehört dazu und REC 42 hat für beides separate Kapital, sowohl für die Qualitätsanforderungen wie auch für die Randbedingungen.
Mit den Randbedingungen, da hatte ich eine lange Zeit so mit Anforderungen zu kämpfen, dass der Fachbereich gesagt hat, ja und dann kommt da was per Fax rein und ich immer so, seid ihr euch sicher, dass das per Fax reinkommen soll?
Wollt ihr nicht die Technologie rauslassen und uns das irgendwie überlassen?
Das ist ja dann auch nochmal so ein Ding, dass man versuchen muss, irgendwie den Lösungsraum offen zu halten, oder?
Ja, aber es ist für viele Firmen ein legales Ansendern zu sagen, wir haben einen Wartungsvertrag mit Firma XY sowieso und du kommst mir nicht mit der 25. unterschiedlichen Datenbank oder der 25. unterschiedlichen Hardware.
Wir machen das hier im Konzern alles einheitlich und wir haben bestimmte Technologie ausgesucht und da geht halt dann kein Weg dran vorbei, da hast du keine Freiheitsgrade.
Randbedingungen sind immer fessel für die Architekten und Entwickler, aber manchmal aus gutem Grund, weil man Wildwuchs verhindern möchte, weil man bestimmte Einheitlichkeit haben möchte, weil man mit bestimmten Dingen gute Erfahrungen hat im Konzern und das will ich nicht dem Team überlassen, da komplett anders zu entscheiden, sondern ich möchte zentrale Vorgaben machen.
Also manchmal hat das schon seinen Sinn.
Ich glaube, es ist das wenigst größte Problem bei Anforderungen, denn diese Randbedingungen sind folklore im Unternehmen, das spricht sich rum.
Wir machen grundsätzlich Open Source oder wir kaufen immer bei Microsoft ein oder was auch immer es sein mag.
Das vergisst man nicht so leicht.
Das ist nur, wenn von außen Leute dazukommen, die in diesem Umfeld noch nie gearbeitet haben, dass man denen dann hoffentlich mal mitteilt, dass es hier im Unternehmen Randbedingungen gibt, auf die sie gefälligst Rücksicht nehmen sollten.
Meistens in dem Konzern ist das oder in der Firma ist das ohnehin Folklore und jeder kennt die Randbedingungen, weil sie in jedem Projekt die gleichen sind.
Aber wenn jetzt so in den Requirements, so wie ich das jetzt gesagt habe, da kommt was per Fax rein oder auch, da gibt es ja sicher andere schlechte Formulierungen, die man so in Interviews bekommt.
Man interviewt ja die Leute, die eben nicht die Requirements Engineers sind, weswegen sie gar nicht so gut formulieren können, was sie brauchen.
Man sagt es ja schon von wegen, man kann sie dann mal beobachten bei der Arbeit und so.
Aber wie nimmst du das dann auf?
Formulierst es um?
Wird es dann nochmal irgendwie durchgesprochen?
Vor allem hinterfrage ich.
Wir haben zuerst schon bei den Zielen über Purpose Advantage Metric gesprochen.
Stell dir mal vor, jemand nennt dir einen Zweck, er möchte etwas haben.
Meine Gegenfrage ist immer, warum?
Ich möchte den Vorteil hören.
Warum will ich den Vorteil hören?
Wenn er mir sagt, warum er das Ganze braucht, dann habe ich, weil ich mehr über Lösungen weiß, vielleicht sogar eine Möglichkeit, ihm einen besseren Zweck vorzuschlagen.
Ich hätte eine ganz andere Möglichkeit, das für dich zu machen.
Du hast Fax gesagt, aber was willst du wirklich erreichen?
Und wenn ich diesen Hintergrund kenne, das mache ich bis runter zu jeder User Story.
Requirements-Leute sind sehr unbeliebte Leute, weil sie immer warum, warum, warum hinterfragen.
Und der Kunde das manchmal selber nicht weiß.
Aber auf die Art versuche ich, technologieneutral zu werden.
Wenn ich den Hintergrund verstanden habe, kann ich eine bessere Lösung vorschlagen.
Dazu muss ich aber den Vorteil, den wirklichen Vorteil herauskitzeln, der mir nicht immer am Silber Tablett serviert wird.
Wenn du einem Kind verbietest, auf die heiße Herdplatte mit der Hand draufzugreifen, wird es versucht sein, das auszuprobieren.
Wenn du mit der Hand langsam näher kommst und sagst, merkst du, wie das heiß wird.
Das wird heißer und heißer und du wirst dich verbrennen.
Deshalb sollst du da nicht hingreifen.
Dann wird es vielleicht im Gedächtnis bleiben.
Also immer den Grund hinterfragen, warum man was nicht tun sollte oder warum man was haben möchte.
Dann kommt man auch auf die technologieneutralen Anforderungen.
Sie können oft nicht anders als in Ihrer heutigen Technologie zu denken und so formulieren Sie es dann auch und das Geschick eines guten Requirements-Engineers oder Business-Analyst ist, darauf zu kommen, was die wirklich haben wollen oder brauchen.
Das heißt, an dem öfters wiederholten Warum erkenne ich den Requirements-Engineer so, wie ich an dem Kommt-Drauf-An den Architekten erkenne?
Ja, okay.
Oder welches Problem löst das?
Genau.
Du hast jetzt so schön gesagt, die Randbedingungen, die sind gegeben und die sind unumstößlich.
Ich habe früher, wenn ich mit dem Qualitätsbegriff gearbeitet habe, habe ich auch immer gedacht unumstößlich, weil jeder will natürlich die beste Qualität.
Also wenn ich irgendwie was haben will und mich einer fragt, ja, welche Qualität möchtest du denn haben?
Da sage ich natürlich nur das Beste.
Ich habe lang gebraucht, bis ich gelernt habe, dass es gut ist, die Qualität zu definieren und dass da Unterschiede gibt.
Das ist eine typisch deutsche Eigenschaft, dass man bei Qualität automatisch nur das Beste verbindet.
Die Total-Quality-Management-Leute, TQM, sagt, Qualität ist Erfüllung von Anforderungen.
Ich glaube, niemand hat das besser verstanden als Microsoft.
Wenn wir für diese Software Geld ausgeben, ist sie gut genug.
Die muss nicht perfekt sein.
Solange wir in die Brieftasche greifen und die Produkte kaufen, ist es definitiv gut genug.
Also Qualität heißt nicht automatisch nur das Beste, sondern Qualität ist Erfüllung von Anforderungen.
Dazu muss jemand die Anforderung explizit äußern, was er haben möchte.
Sehr oft haben wir ganz unterschiedliche Vorstellungen, was ist schnell oder was ist Performance.
Der Kunde braucht es gar nicht so schnell und wir als Entwickler glauben, es muss hundertmal so schnell gemacht werden.
Wenn man den Kunden mal fragt, denke an deinen Bankautomaten.
Wie lange hast du Geduld, wenn du das Kärtchen reinsteckst, bevor da die erste Schrift rauskommt?
Das ist nicht im Mikrosekundenbereich.
Du hast Sekundengeduld.
Das muss nicht noch schneller reagieren.
Der Mensch ist ohnehin der langsamste Faktor in dieser ganzen Kette.
Da muss ich nicht super optimieren dabei, wenn andere Sachen ausreichen.
Denn nur das Beste kannst du haben.
Kostet allerdings dann unter Umständen sehr viel Geld.
Und wenn du nicht bereit bist, so viel Geld für dich auszugeben, da bist du vielleicht auch mit weniger zufrieden.
Das mit der Geschwindigkeit, das hatte ich einmal erlebt, wie ich ein Produkt präsentieren wollte und zwar eine einfache Java-Web-Anwendung.
Der hat gar nicht auf das Produkt geachtet, sondern hat nur gestaunt, wie schnell das ist, wo ich erst mal nachfragen muss, was ich denn erwartet habe.
So eine SQL-Abfrage, da warten wir schon mal acht Sekunden.
Aber diese Definition, wenn der Kunde bereit ist, die Brieftasche aufzumachen, bedeutet ja auch unter Umständen, dass es reicht, wenn keine andere Option für den Kunden da ist.
Ja, man braucht ein Feature nicht, weil es die Konkurrenz quasi auch nicht hat, wobei man sich immer so ein bisschen wahrscheinlich den Vorteil verschaffen sollte.
Dazu vielleicht eine schockierende Studie der Standish Group, die gesagt hat, 45 Prozent der heute produzierten Software werden nie und nimmer und von niemandem benutzt.
Was könnten wir uns sparen und wo könnten wir viel schneller sein und viel weniger Aufwand haben, wenn wir nur wüssten, was die anderen 55 Prozent sind, die wenigstens benutzt werden.
Und die Standish Group geht noch weiter, indem sie sagt, nur 20 Prozent der heute gelieferten Software wird oft und häufig benutzt.
Das heißt, wir könnten erfolgreiche Produkte an den Markt bringen, die 80 Prozent weniger Features haben und 80 Prozent weniger Aufwand machen, wenn wir nur genau herauskriegen würden, was unsere Stakeholder haben wollen.
Dann kann man viel billiger produzieren und nicht so sehr für den Papierkorb, was ohnehin nicht benutzt wird.
Mein Musterbeispiel ist immer Excel.
Ich weiß nicht, wie viele Funktionen du von Excel benutzt und ob du schon mal gesehen hast, was da noch alles drinnen steckt.
Ja, da gibt es ein paar Spezialisten auf der Welt, die nutzen vielleicht auch die letzten Teile davon.
Aber die große Mehrheit braucht nicht nur 20 Prozent, sondern 20 Funktionen von den tausenden Excel-Funktionen und ist trotzdem zufrieden.
Also wir könnten viel schneller Produkte an den Markt bringen, viel erfolgreicher sein, viel früher rausgehen.
Und das ist der agile Ansatz.
Wir wollen heute mit minimal marketable products sehr früh an den Markt gehen und dann mal abwarten, was der Markt sonst noch verlangt.
Ich muss nicht gleich perfekte Produkte mit allen Features haben.
Ich kann im Laufe der Zeit ausbauen und ergänzen und erweitern.
Und am Anfang kann man aber sehr schnell unter Umständen mit minimal vermarktbaren Produkten schon rausgehen.
Wobei dieses langsam wachsen, ich glaube, da gehört auch die große Kunst dazu, dass es richtig wächst.
Weil ich meine, bei so Office-Produkten würde ich sagen, na ja, die Integration der verschiedenen Features, das ist schon nicht schlecht.
Ich muss aber auch an ein UML-Tool denken, wo auf einmal Projektmanagement-Feature reingekommen sind und sogar ein Java-Debugger, wo ich mir sage, wow, hätte ich jetzt nicht drin erwartet.
Und na ja, wahrscheinlich gehört es zu den 80 Prozent, die quasi gar nicht genutzt werden.
Nur weil einer sich das irgendwie gewünscht hat.
Keine Ahnung.
Das kontrollierte Wachstum hängt ja wieder davon ab, ob ich vernünftige Ziele formuliert habe, wo ich insgesamt hin möchte.
Ich habe noch vorher nicht dazu gesagt, ## Ziele und Vision
Ziele sind immer zeitbezogen und der Zeithorizont kann durchaus drei oder fünf oder sieben Jahre sein in einigen meiner Projekte.
Trotzdem liefere ich nach zwei, drei Monaten schon erste Versionen aus.
Ich weiß aber, wo ich in drei oder fünf oder sieben Jahren sein werde.
Jetzt können wir darüber fantasieren, können sich auch Ziele ändern im Laufe der Jahre?
Na, selbstverständlich.
Wenn die Firma verkauft oder mit anderen Firmen gemerged wird, ändert sich vieles dabei.
Aber ### Bedeutung der Zieldefinition
Ziele sind für mich die Anforderungen, die sich möglichst in dem Zeithorizont, den wir uns vornehmen, nicht ändern sollen.
Damit das Entwicklungsteam auf irgendetwas vertrauen kann.
Da wollen wir lang, da wollen wir hin.
Und da ist unsere Ausrichtung, auch wenn wir in sehr kurzen Iterationen natürlich Versionen herausbringen.
Deshalb sind die Ziele so wichtig und nicht die kleinen User Stories.
Die sind nur für den nächsten Sprint wichtig.
Das war etwas Konkretes liefern.
Wenn du jetzt sagst, die kleinen User Stories, die nur für den nächsten Sprint wichtig sind und davon brauchen wir ganz viele.
Jetzt gebe ich mich mal auf dünnes Eis.
Ich habe jetzt gerade am Wochenende mit Speck Driven Development gearbeitet.
Ich habe die KI angeschmissen und ich habe Speck Kit, heißt das Tool, angeschmissen, was mir verspricht, dass ich kurz beschreibe, was ich haben will.
Und es erstellt mir eine tolle Spezifikation mit ganz vielen User Stories und daraus werden Tasks erstellt und, und, und, und, und.
Nimmt ganz viel Arbeit ab und ich habe eine tolle Spezifikation, wo ich dann ja immer wieder sagen kann, generiere mir das neu, die Software daraus und wie ist so dein Standpunkt dazu?
Kennst du die Geschichte von dem Elefanten und den drei blinden Leuten?
Ja.
Der eine fasst den Rüssel an und sagt, das ist was sehr bewegliches und weiches.
Der andere fasst die Beine an und sagt, das ist aber ganz fest und dick und stabil und ähnliches.
Das heißt, jeder Einzelne hat unter Umständen eine völlig falsche Perspektive von dem Ganzen.
Und das Gleiche passiert dir, wenn du natürlich in einem sehr kleinen Bereich, die jede Menge Stories generieren lässt und das große Ganze aber nicht vor Augen hast.
Alistair Coburn, der ja sehr viel über effiziente Use Cases und ähnliches Use Case Driven Development geschrieben hat, der reiste lange Zeit mit einer Story um die Welt, die nannte er Elephant Carpaccio.
Du weißt, was Carpaccio ist, ganz dünne Fleischscheiben.
Ja.
Er sagt, wenn du einen Elefanten hast, kannst du den nicht auf die Schneidermaschine drauflegen und da sofort Carpaccio-Scheiben runterschneiden.
Du musst zuerst die großen Teile, den Rüssel und den Kopf und den Körper und die Füße zerlegen.
Und wenn das dann halbwegs klein genug ist, dann kannst du Carpaccio-Scheiben draufschneiden.
Du kannst nicht aus einem Elefanten sofort Carpaccio machen.
Das geht nicht.
Du brauchst eine Gliederung im Größeren.
Und das ist das, was ich zuerst angesprochen hatte über Features und Epics und über die größeren Einheiten.
Im kleinen Markt das funktionieren.
Also wenn ich ein Projekt, irgendeinen 50.
Webshop baue und schon weiß, was da alles drinnen ist, dann kann ich sehr schnell auf die Ebene von Stories runterkommen.
Aber wenn ich große, innovative, neue Projekte mache, brauche ich zuerst einen Überblick über das Ganze.
Ich muss nicht alles bis ins letzte Teil herunterbleiben.
Mir reicht der Überblick am Anfang.
Ich weiß, die Features kommen erst in einem Jahr.
Die brauche ich auch nicht genauer betrachten.
Aber ich weiß, sie werden kommen.
Und ich habe zumindest den Platzhalter dafür.
Und ein Jahr später, nach dem vierten, fünften, sechsten Release, kümmere ich mich dann um die Feinheiten von dem, was da erst in einem Jahr kommt.
Muss ich nicht am Anfang machen.
Somit kann man Zeit sparen.
Denn kompletter Requirements-Aufwand ist ungefähr 25 Prozent vom Gesamtaufwand.
Also wenn du drei Jahre später zurückblickst und sagst, wie viel haben wir investiert, um herauszubekommen, was wir eigentlich haben wollen, dann ist es 25 Prozent.
Gott sei Dank müssen wir die nicht am Anfang leisten.
Wir machen das agil.
Aber wir brauchen den Überblick.
Und da kann ich priorisieren.
Und dann breche ich in die Tiefe.
Das ist als T-Stich-Modell bekannt.
Ich brauche den oberen Balken des Tees.
Dazu gehören die Ziele.
Dazu gehört mein Scope.
Dazu gehören die drei wichtigsten Qualitätsanforderungen, die die Killeranforderungen für das Produkt sind.
Und dazu gehört der Überblick über die Funktionalität.
Und jetzt kann ich priorisieren.
Und ich betrachte nur das genauer, dass ich wirklich demnächst umsetzen möchte.
Und nicht alles.
Aber der Überblick ist da.
Aber das, was du ja ansprichst mit dem hundertsten Webshop, ist ja quasi auch das Thema, wenn ich das mit KI mache.
Ja, Webshops kennt die KI zu genüge und kann quasi aus ihrem Merkmalsraum die Anforderungen runterbeten.
Und da ist vielleicht dann auch gar nicht so der Wert drinnen in diesen Requirements, sondern nur einfach mal, dass man nochmal drüber guckt und sagt, ja, passt schon.
Aber der innovative Teil, der muss irgendwo menschlich erarbeitet werden.
Mein Kollege Tom DeMarco hat das brutal formuliert, indem er gesagt hat, alle risikoarmen Projekte, die schnellen Erfolg bringen, wurden schon in den 60er Jahren des letzten Jahrhunderts durchgeführt.
Wenn du heute großen Erfolg haben willst, muss auch großes Risiko gehen.
Und das heißt eben auch Teile anpacken, die man nicht zum hundertsten Mal macht, sondern Teile, die man zum ersten Mal macht oder zum zweiten Mal macht.
Dann hast vielleicht auch den großen Erfolg dahinter.
Und das kann die KI heute nicht leisten, diese Art von Vorausschau, wo vielleicht noch irgendetwas schlommert, was wir eben noch nicht 50 Mal gemacht haben oder 100 Mal gemacht haben.
Das mit dem Risiko ist so ein bisschen dieser Spruch, das Schiff ist im Hafen sicher, aber dafür ist es nicht gemacht.
Da ist es sinnlos, genau.
Ja, prima.
Ich bin jetzt echt ein bisschen geplättert.
Ich habe jetzt so einen großen Eindruck von den Requirements.
Ehrlich gesagt, ich mache ja Architektur und ich ärgere mich immer über die fehlenden Requirements.
Aber mir ist es eben auch gar nicht so klar gewesen, wie aufwendig es ist, diese Requirements überhaupt in Erfahrung zu bringen, zu erarbeiten und zu pflegen.
Was ich mich dann noch frage, ist, ob die Requirements, wenn man da so viel Aufwand reinsteckt, auch tatsächlich gut gelesen und verarbeitet werden oder ob dann viele nur die User-Stories überfliegen, gar nicht genau die Requirements, nochmal die Randbedingungen und sowas sich angucken.
Aber das ist dann wahrscheinlich nochmal ein anderes Thema.
Naja, lass mich einen Fehler eingestehen, den wir mal gemacht haben.
Wir haben für ein riesiges Data-Warehouse-System ein sehr ausgeklügeltes Datenmodell entwickelt, fachliches Datenmodell, in einem bestimmten Bereich mit über 300 Entities, 3.000 Attributen da drin und Massig-Beziehungen und haben das einfach über den Zaun geworfen einer Firma für die Implementierung.
Und die haben das nicht mal genau gelesen, sondern haben gesagt, so komplex kann das gar nicht sein.
Haben dann angefangen, 30 Tabellen zu entwickeln, statt der 300, die wir ihnen vorgegeben haben.
Und haben sich im zweiten, dritten Release dann gewundert, dass Ergänzungen, die eigentlich dann gemacht werden sollten, sich nicht mehr implementieren ließen.
Und wir haben gesagt, es war doch alles genau beschrieben.
Und die haben gesagt, wir haben sträflich vereinfacht, weil wir nicht glauben konnten, es war unser Fehler.
Wir hätten das Requirements-Modell verkaufen müssen.
Wir hätten den anderen klarmachen müssen, dass die Komplexität der Materie wirklich so groß ist und dass sie die nicht unterschätzen sollen und einfach mit einem Zehntel der Entities anfangen sollen und dann glauben, dass sie da alles unterkriegen.
Es ist Gott sei Dank schon im zweiten, dritten Release, also nach einem Viertelhalben Jahr aufgefallen, weil die dann gesagt haben, das können wir nicht mehr implementieren.
Und wir haben gesagt, warum?
Unser Datenmodell gibt das doch her.
Und die haben gesagt, ja, das haben wir aber nicht implementiert.
Also ja, Requirements müssen auch verkauft werden.
Aber dadurch, dass wir die so schön hierarchisch strukturiert haben, muss ich nicht alles darüber wissen.
Ich muss den Überblick haben.
Ich muss die Ziele kennen.
Ich muss den Überblick der Funktionalität kennen.
Und da, wo es einer genauer wissen will, da muss man sich dann auch einarbeiten.
Und heute passiert das meistens miteinander und nicht gegeneinander.
Das heißt, wir schreiben heute keine hundertseitigen oder fünfhundertseitigen oder tausendseitige Pflichtenhefte und werfen die über den Zaun, sondern wir erarbeiten die gemeinsam in der Zeitperiode, kurz bevor wir es implementieren müssen.
Und diese Art Kommunikation stellt sicher, dass hoffentlich alle zuhören und mitmachen.
Und da kommen auch die Entwickler ins Spiel, die dann sagen, ja, aber das ist doch ganz anders, noch leichter lösbar.
Und die vielleicht auch mal widersprechen und die sagen, wenn du das wirklich erreichen willst, habe ich einen besseren Weg für dich.
Durch diese Zusammenarbeit werden Projekte heute schneller und erfolgreicher, ohne dass wir so viel schreiben müssen, wie wir es vielleicht vor 20, 30 Jahren gemacht haben.
Du hast gerade nochmal einen Aspekt erwähnt, den ich, weil ich den Blick auf die User Stories hatte, gerade so gar nicht gesehen hatte, dass ja, wenn man so Ziele hat, die da wahrscheinlich in die Requirements, Aspekte reinkommen, die man auf einem kleinen Detaillevel gar nicht versteht, dass man hat das große Ziel vor Augen, weiß deswegen, es muss so und so gemacht werden, das und das muss sein.
Und da ist dann wahrscheinlich der höchste Erklärbedarf vorhanden.
Diese Vision, die man aufbaut und rüberbringen muss.
Und vor allem, also ich versuche, jedem klarzumachen, streitet bitte nicht über detaillierte Anforderungen, wenn ihr noch einen Zielkonflikt habt.
Wenn also in den Zielen im Prinzip zwei Stakeholder, zwei unterschiedliche Abteilungshäuptlinge, wollen in ganz andere Richtungen.
Also solange das nicht geklärt ist, brauche ich nicht über Details zu streiten.
Da muss ich zuerst mal die Ziele konsolidieren und jemanden haben, der sagt, ja, das sind wirklich die drei oder vier oder fünf Punkte, die wir erreichen wollen.
Solange auf der Ebene noch gestritten wird, brauchen wir uns über Details keine Sorgen zu machen.
Und das passiert leider sehr oft, dass ein Development Team dann mitten zwischen den Stühlen sitzt und dass einige, die das Team von zwei oder drei Seiten aus beschäftigen, in ganz andere Richtungen ziehen und sich dann wundern, dass das kein einheitliches Produkt wird.
Also Zielkonflikte zuerst lösen, bevor wir über detaillierte Anforderungen sprechen.
Ein guter Punkt.
Ja, Peter, wir sind so langsam auch am Ende.
Ich habe jetzt einen tiefen Einblick in das Requirements Engineering bekommen.
Danke dafür.
Falsch, Ralf.
Du hast einen ganz flachen Einblick in die Requirements Engineering bekommen.
Daniel Kruger-Effekt.
The fool thinks he’s a wise guy, but the wise guy knows himself to be a fool.
Herzlichen Dank auch für diese Korrektur nochmal.
Aber ich sage mal, so der Problemraum hat sich jetzt in dieser Stunde geöffnet.
Herzlichen Dank für das Gespräch.
Wir sehen uns Ende November auf dem Software Architecture Gathering in Berlin.
Ich freue mich schon drauf und für alle Zuhörer in den Show Notes werdet ihr den Code finden.
Peter, herzlichen Dank für diesen, wie du sagst, dann doch relativ flachen Einblick.
Und ja, wir sehen uns.
Bis dann.
Ich danke dir, Ralf.