Kolumne

Req4Arcs: Miteinander statt gegeneinander

Gernot Starke, Peter Hruschka

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!

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: