Kolumne

Req4Arcs: Miteinander statt gegeneinander
Keine Kommentare

Nach vielen inhaltlichen Folgen zum Umgang mit Requirements greifen wir diesmal ein ganz anderes Thema auf: Wie sollten Architekt(inn)en mit Requirements-Spezialisten zusammenarbeiten?

Iterativ und inkrementell sind Pflicht

Wasserfall ist wirklich passé, oder? Requirements und Architektur sollten heute – da sind sich alle Vorgehensmodelle einig – hochgradig iterativ und inkrementell entwickelt werden. Eine schöne Metapher dafür hat Ellen Gottesdiener mit ihrer Formel „Discover to deliver“ [1] entwickelt. Grafisch dargestellt [2] durch ein Möbiusband (Abb. 1): Ein ständiges Wechselspiel zwischen Requirement entdecken (discover) und Architektur und Umsetzung weiterbringen (deliver).

Abb. 1: Discover to deliver

Abb. 1: Discover to deliver

Bevor wir jedoch in diese Endlosschleife eintreten, müssen wir ein paar Grundlagen schaffen. Sie erinnern sich sicherlich noch an unsere zweite Folge, in der wir den „Clean Project Start“ schildern: Fangen Sie erst mit Ihrer Entwicklung an, wenn Sie Business Goals, Stakeholder und Scope kennen. Sie erinnern sich auch noch an die Folge „Qualität fällt nicht vom Himmel“ [3], in der wir Ihnen dringend geraten haben, die wichtigsten Qualitätsanforderungen und Randbedingungen frühzeitig zu klären, denn Unkenntnis dieser Architekturtreiber könnte Ihr System zum Scheitern verurteilen. Auch wenn die funktionalen Anforderungen anfänglich noch sehr grob daherkommen, können Sie trotzdem schon Architekturentscheidungen treffen.

Abbildung 2 zeigt dazu das T-Stich-Modell. Der komplette Aufwand für gute Requirements ist mit 25 Prozent des Gesamtaufwands beziffert [4]. Davon brauchen Sie aber anfangs nur ca. ein bis fünf Prozent (für den oberen Balken des T). Der Inhalt wird als „architecturally relevant Requirements“ bezeichnet – und auf diese (und nicht auf Vollständigkeit der Anforderungen) sollten Sie anfangs Wert legen.

Abb. 2: Architecturally relevant Requirements

Abb. 2: Architecturally relevant Requirements

Das Zwischenergebnis als Kommunikationsbasis zwischen Architekten und Requirements Engineers können z. B. Story Maps [5] sein, die zumindest den Überblick über alle Epics zeigen. Anhand dessen können Sie bzw. Ihr Team dann entscheiden, welche Epics Sie zur frühzeitigen Implementierung in Features und Storys verfeinern möchten. Womit Sie jeweils starten, sollte maßgeblich vom Businesswert der Anforderungen abhängen, oder es sollte eine deutliche Risikoreduzierung versprechen (Abb. 3).

Abb. 3: Story Maps als Bindeglied

Abb. 3: Story Maps als Bindeglied

Doppelt hält besser: Double Loop Learning

Eine mögliche Lösung (deliver) [2] ist es, mit Safe-to-Fail Probes zu arbeiten. Diese testen eine gemeinsam von Analytikern und Architekten erstellte Hypothese, dass eine bestimmte Lösung das Problem der Kunden löst und entsprechenden Geschäftswert abliefert. Dieser Versuch, eine rasche Lösung für das Problem zu implementieren (Safe-to-Fail Probe), zeigt aber vielleicht, dass wir mit unseren Architekturansätzen oder der Implementierung danebengelegen haben und wir das Problem nicht ordentlich lösen konnten. Im Single-Loop (Abb. 4) versuchen Sie dann an einer alternativen Lösung für das gleiche Problem zu arbeiten. Im Double-Loop gehen Sie nochmals zurück und hinterfragen die Problemstellung.

Abb. 4: Double-Loop Learning

Abb. 4: Double-Loop Learning

Es geht noch enger: gemeinsam statt nacheinander

Viele Ansätze der letzten Jahre schlagen vor, die Zusammenarbeit von Analytikern und Architekten/Entwicklungsteams noch enger zu gestalten: Wenn möglich, sollten sie ständig gemeinsam als ein Team an gemeinsamen Artefakten arbeiten. Das führt dazu, dass diese integrierten Teams selbst bei sehr groben Anforderungen frühzeitig an Lösungsalternativen denken, diese sofort bewerten und die erfolgversprechendsten kurzfristig umsetzen. Ein ständiges Wechselspiel zwischen Divergieren und Konvergieren, (Abb. 5) garantiert, dass Sie weder zu abstrakt bezüglich der Requirements werden noch die falschen Lösungen bauen. Im Folgenden fassen wir einige dieser Ansätze kurz zusammen.

Abb. 5: Divergieren und konvergieren

Abb. 5: Divergieren und konvergieren

Gemeinsame Sprache und gemeinsame Modelle

Das Minimum in der Zusammenarbeit über Requirements und Architektur muss eine gemeinsame Sprache sein: Sowohl aus Anforderungs- wie auch aus Lösungssicht stoßen Sie auf viele Begriffe. Stellen Sie sicher, dass es im Projekt nur ein gemeinsames Glossar gibt und nicht zwei konkurrierende.

In einer vorherigen Folge haben wir Sie mit der Ubiquitous Language von DDD vertraut gemacht. Das geht einen wesentlichen Schritt in Richtung Zusammenarbeit aller Beteiligten weiter: So schaffen Sie ein einheitliches Modell für alle Projektbeteiligten, sprechen über die gleichen Business Objects (Entities) und Services, und richten Ihre Epics hoffentlich an Bounded Contexts aus.

In der letzten Folge sind wir noch eine Stufe weiter gegangen und haben gezeigt, wie Sie mit BDD und ausführbaren Spezifikationen gemeinsam über beispielhafte Szenarien zum Ziel kommen können.

Three Amigo Sessions

Eine weitere Form der engen Zusammenarbeit ist unter dem Namen „Three Amigo Meetings“ in der agilen Welt bekannt geworden. John F. Smart erklärt dazu, dass man mindestens drei Rollen besetzen muss, um raschen Erfolg zu haben (Abb. 6):

  • einen, der fordert – üblicherweise ein Analytiker oder Product Owner
  • einen, der Lösungsansätze vorschlägt – Architekt(in) und
  • einen, der protestiert oder anzweifelt – das könnte jemand aus dem Testteam übernehmen.

Natürlich können es auch mehr als drei Personen sein, aber jede Rolle muss besetzt sein. Jeder Beteiligte kann jede Rolle spielen, manchmal auch mehrere gleichzeitig. So werden Anforderungen und Lösungsideen in ganz enger Zusammenarbeit auf den Prüfstand gestellt.

Abb. 6: Three Amigo Meeting

Abb. 6: Three Amigo Meeting

Design Thinking

Ein Prozess, der zunehmend an Popularität gewinnt, ist Design Thinking. Der ehemalige Boeing-Ingenieur David Kelley gründete mit anderen Personen in den späten 70er-Jahren das Unternehmen IDEO. Seit 2003 vermarkten sie ihre Ideen unter dem Namen „Design Thinking“. Der ursprünglich sechsstufige Prozess (Emphathize – Define – Ideate – Prototype – Test – Implement) kombiniert Ergebnisoffenheit mit Lösungsfindung. Durch die enge Zusammenarbeit vieler Rollen (Endnutzer, Analytiker, Designer, Implementer) ist in kurzer Zeit mehr zu erkennen als durch getrennt arbeitende Spezialisten.

Ingrid Gerstbach hat die sechs Phasen [6] pragmatisch auf vier reduziert (Abb. 7). „Einfühlen“ und „Definieren“ entsprechen dem „Discover“. „Deliver“ wird durch „Generieren“ und „Experimentieren“ ausgedrückt. Die vier Schritte dienen der gemeinsamen Problemanalyse und Lösungsfindung sowie dem raschen Feedback, ob die Lösung die Probleme aus Kundensicht wirklich löst. Allerdings ist zu beachten, dass alle Rollen an allen Schritten beteiligt sind und in sehr kurzen Abständen immer wieder die Schritte gehen müssen.

Abb. 7: Design Thinking [9]

Abb. 7: Design Thinking [6]

Lean Software Development und Lean Startup

Mary und Tom Poppendieck haben die Ideen des Lean Manufacturings auf Softwareentwicklung übertragen [7]. Eric Ries hat es in seinem Bestseller „The Lean Startup“ [8] speziell für Firmen erweitert, die generell Produkte auf den Markt bringen wollen.

Diese beiden Ansätze setzen auf frühzeitigen Produkt-Launch durch sehr kurze Produktentwicklungszyklen. Das wichtigste Element ist Kundenfeedback. Dieses Feedback zu wirklich deploybaren Produkten (statt nur zu dicken Papierdokumenten mit Plänen) ermöglicht ein messbares Lernen bezüglich der wahren Bedürfnisse des Markts und der Kundenwünsche. Die gewonnenen Erkenntnisse fließen in die nächsten (genauso kurzen) Produktentwicklungszyklen ein.

Abb. 8: Lean Development Cycle

Abb. 8: Lean Development Cycle

Diese kurzen Zyklen bedürfen einer sehr intensiven Zusammenarbeit zwischen Marktkennern (Analytikern, Requirements Engineers) einerseits und Lösungsspezialisten (Architekten, Designer, Programmierer) andererseits.

Fazit

Wir hoffen, Sie haben jemanden im Umfeld, der Ihnen zeitgerecht die richtigen Anforderungen zuliefert. Wenn nicht, dann müssen sie als Team diese Aufgabe meistern: Requirements erforschen und umsetzen. Je enger Sie diese beiden Tätigkeiten verzahnen, je mehr Sie miteinander im Gespräch bleiben, desto reibungsloser wird Ihre Entwicklung ablaufen und Sie vermeiden Zeitverschwendung – denn Sie spezifizieren nur die Dinge, die wirklich benötigt werden. Das bedeutet, dass Ihr Team nicht raten muss, was Kunden und Anwender wirklich wollen und Teile auf Verdacht entwickeln, die Sie später wieder entsorgen müssen.

In diesem Sinne – möge schon wieder die Macht guter Anforderungen und ergiebiger Zusammenarbeit mit Ihnen sein!

Links & Literatur

[1] Gottesdiener, E.: „Discover to Deliver: Agile Product Planning and Analysis“, EGB Consulting Inc. 2012

[2] Robertson, J.; Robertson, S.: „Business Analysis Agility – Solve the Real Problem, Deliver Real Value“, Addison Wesley, 2019

[3] Starke, Hruschka: „Qualität fällt nicht vom Himmel“, Java Magazin 8/2019

[4] Hruschka, P.: „Business Analysis und Requirements Engineering – Produkte und Prozess nachhaltig verbessern“ (2. Auflage), Hanser Verlag, 2019

[5] Patton, J.: „User Story Mapping: Discover the Whole Story, Build the Right Product“, O’Reilly, 2015

[6] Gerstbach, I.: „Design Thinking im Unternehmen: Ein Workbook für die Einführung von Design Thinking“, GABAL Verlag, 2016

[7] Poppendieck, Mary; Poppendieck, Tom: „Lean Software Development: An Agile Toolkit“, Addison-Wesley Professional, 2003

[8] Ries, E.: „The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses“, Crown Business, New York, 2011

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -