Intro für alle, die nicht wissen, wer die beiden Männer am Titelbild sind
Max Verstappen hat in den letzten Jahren die Formel 1 dominiert, insbesondere seit der Saison 2021, als er seinen ersten Weltmeistertitel gewann. Seitdem hat er auch die Saisonen 2022 und 2023 dominiert und jeweils die Weltmeisterschaft gewonnen. Verstappen und sein Team, Red Bull Racing, haben in dieser Zeit zahlreiche Rekorde gebrochen. So stellte Verstappen unter anderem den Rekord für die meisten aufeinanderfolgenden Rennsiege auf und beendete die Saison 2023 mit einem Rekordvorsprung von 290 Punkten vor seinem Teamkollegen Sergio Perez. Es besteht kein Zweifel, dass für die Erfolge das außerordentliche Talent und die harte Arbeit von Max Verstappen wesentlich sind. Aber ohne einen kongenialen Partner auf Seiten der Technik, das ist Adrian Newey, wäre selbst das größte Talent chancenlos.
Die Dominanz von Verstappen und Red Bull ist auf eine Kombination aus seinem außergewöhnlichen Fahrkönnen und der technischen Überlegenheit des Teams zurückzuführen. Verstappen hat großes Interesse an den technischen Aspekten der Fahrzeugentwicklung gezeigt und häufig seine Vorlieben diskutiert und Feedback gegeben, das Newey und das Team zur Verbesserung der Leistung des Autos nutzen konnten. Dieser kollaborative Ansatz war entscheidend für die jüngsten Erfolge von Red Bull. Andererseits schätzt Newey, bekannt für sein tiefes technisches Wissen, auch die Einblicke von Fahrern wie Verstappen, um die Fahrzeugdesigns weiter zu verfeinern. Neweys Fähigkeit, das Feedback eines Fahrers in technische Verbesserungen umzusetzen, ist eine seiner Stärken.
Wir kommen auf dieses Fallbeispiel noch zurück.
Anforderungsanalyse – ein irreführender Begriff
In der Wasserfallwelt wird von den Anwendern erwartet, dass sie ihre Anforderungen an das gewünschte IT-System vollständig und hinreichend detailliert beschreiben. Diese Anforderungen werden dann von der IT analysiert und daraus werden Aufgaben für die technische Umsetzung abgeleitet. Die Interaktion zwischen Business und IT dient der Klärung der Anforderungen, sei es durch Klarstellungen, sei es durch Detaillierungen, also das Herunterbrechen von Anforderungen in Teilaspekte.
In agilen Projekten wird dieses Paradigma letztlich beibehalten. Der Weg von Epics zu User Stories und dann zu Tasks für die Entwickler ist im Grunde auch ein Analyseprozess mit einer Flussrichtung von den fachlichen Anforderungen zu den technischen Lösungen. Vielfach wird auch davon gesprochen, dass die technischen Lösungen aus den fachlichen Anforderungen „abgeleitet“ werden.
Wir sollten jedoch bedenken, dass Analyse nur ein Teil des Aufgabenspektrums bei der Entwicklung von IT-Systemen ist und es auch einen gegenläufigen Prozess geben muss.
Der Duden definiert Analyse und deren Antagonisten so:
- Analyse: „Systematische Untersuchung eines Gegenstandes oder Sachverhalts, bei der dieser in seine einzelnen Bestandteile oder Aspekte zerlegt wird.“
- Synthese: „Zusammenfügen von Teilen zu einem Ganzen; gedankliches Verknüpfen von Elementen zu einem neuen Ganzen.“
Synthese ist in der IT-Welt kein gängiger Begriff, wir sprechen von Entwurfs- oder Konstruktionsprozessen.
Sowohl Analyse- als auch Entwurfsprozesse sind bei allen Beteiligten gefordert. Die fachlichen Anforderungen entstehen nicht nur aus dem Sammeln, Sortieren, Priorisieren und Analysieren von Wünschen. Sie erfordern auch einen Entwurfsprozess, der ein integriertes Szenario von künftigen Geschäftsprozessen und dafür erforderlichen IT-Services hervorbringt. Ebenso müssen auf IT-Seite die fachlichen Anforderungen mit Systementwürfen abgeglichen werden, die nicht aus fachlichen Anforderungen „abgeleitet“ werden können, sondern einen eigenständigen und kreativen Entwurfsprozess voraussetzen. Wenn wir mit Standardsoftware arbeiten, ist der gegenseitige Abgleich als Delta-Analyse bekannt und für die IT vergleichsweise einfach; es gibt eine mehrfach erprobte und bekannte Architektur mit definierten Konfigurations- und Customizingmöglichkeiten. Je mehr wir uns in den Bereich von Individualentwicklungen und/oder disruptiven Prozessinnovationen begeben, umso anspruchsvoller und eigenständiger muss der technische Entwurfsprozess sein.
Was sagt IREB?
Der dominierende Standard für das Requirements Engineering („International Requirements Engineering Board„) definiert folgende Phasen bzw. Prozesse des Anforderungsmanagements.
- Anforderungserhebung (Requirements Elicitation):
Ziel: Sammlung der Anforderungen von allen relevanten Stakeholdern.
Methoden: Interviews, Workshops, Beobachtungen, Fragebögen und Anforderungsdokumente.
Ergebnisse: Eine Liste der funktionalen und nicht-funktionalen Anforderungen.
- Anforderungsanalyse (Requirements Analysis):
Ziel: Verstehen und Strukturieren der gesammelten Anforderungen.
Aktivitäten: Klassifizieren, Priorisieren und Verfeinern der Anforderungen.
Ergebnisse: Detaillierte Anforderungen, die klar, konsistent und vollständig sind.
- Anforderungsdokumentation (Requirements Documentation):
Ziel: Festhalten der Anforderungen in einer verständlichen und überprüfbaren Form.
Dokumente: Lastenheft, Pflichtenheft, Anforderungsdokumente.
Ergebnisse: Dokumentierte Anforderungen, die als Referenz für die Entwicklung dienen.
- Anforderungsvalidierung (Requirements Validation):
Ziel: Sicherstellen, dass die Anforderungen korrekt und vollständig sind.
Methoden: Reviews, Walkthroughs, Prototyping, Simulationen.
Ergebnisse: Validierte Anforderungen, die die Bedürfnisse der Stakeholder erfüllen.
- Anforderungsmanagement (Requirements Management):
Ziel: Verwalten und Überwachen der Anforderungen über den gesamten Projektlebenszyklus.
Aktivitäten: Änderungsmanagement, Versionskontrolle, Nachverfolgbarkeit der Anforderungen.
Ergebnisse: Kontrollierte und aktuelle Anforderungen, die den Projektfortschritt unterstützen.
Man könnte aus diesem Phasenmodell folgern, dass IREB keine Wechselwirkung von fachlichen Anforderungen und technischen Lösungsoptionen vorsieht. Das trifft allerdings nicht zu. Im Standard für den Advanced Level finden wir das „Twin-Peaks-Modell“ (siehe Grafik). Dieses stellt dar, dass eine immer detaillierter werdende Anforderungsbeschreibung (links im Bild) und parallel dazu eine immer detaillierter werdende Systemarchitektur (rechts im Bild) entstehen und sich beide gegenseitig ergänzen.
Twin-Peaks-Modell (Quelle: Handbuch Requirements Management nach IREB Standard)
Dass Max Verstappen und Adrian Newey das Twin-Peaks-Modell kennen, dürfen wir wohl ausschließen. Aber zweifellos handeln sie im Sinne dieses Modells. Newey hat auch schon früher, speziell mit Sebastian Vettel, in dieser Weise erfolgreich zusammen gearbeitet. Er ist wohl die prägende Person und wir können die Parallele ziehen, dass es auch in IT-Projekten vor allem darauf ankommt, dass die IT einen guten Job macht, der auch das Vorgehen im Requirements Management umfasst.
Was sollten agile Projekte von Verstappen und Newey lernen?
Agile Frameworks betonen die Bedeutung der intensiven Zusammenarbeit von Business und IT. Das agile Manifest ist von IT-Leuten geschrieben worden und eines ihrer Lösungsprinzipien ist: „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten“. Es bleibt allerdings offen, was sie im Zuge dieser täglichen Zusammenarbeit konkret besprechen und tun.
Der Scrum-Guide hat mit seiner strikten Fokussierung auf den Product-Owner als einzige akzeptierte Quelle von fachlichen Anforderungen und dem Abkapseln des Teams während eines Sprints maßgeblichen Anteil daran, dass sich in vielen agilen Projekten eine Variante des Wasserfallmodells etabliert hat: Es gibt nicht mehr den großen Wasserfall über das gesamte Projekt hinweg, sondern Mini-Wasserfälle je User-Story. Natürlich ist es nicht effizient, wenn ständig an den fachlichen Anforderungen gedreht wird. Aber Sprint-Reviews und Retrospektiven, die sowohl die fachlichen als auch die technischen Stark- und Schwachstellen der Arbeit adressieren, sind unbedingt erforderlich. Alle Beteiligten müssen bereit und in der Lage sein, einander verständlich zu machen, was notwendig und möglich ist, um die Projektziele zu erreichen.
Hier noch einige Beiträge von mir zum Thema:
Wie Anforderungen durch Testfälle konkretisiert werden können
Wie die zwei wichtigsten Komplexitätstreiber entschärft werden können