Kolumne Req4Arcs

Warum ein „Clean Start“ für Software-Architekten wichtig ist

Gernot Starke, Peter Hruschka

© S&S_Media

In der zweiten Folge unserer Kolumne stellen wir Ihnen drei Zutaten vor, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten. Wir nennen das zusammenfassend einen „Clean Start“ für Ihr Projekt oder Ihre Produktentwicklung. Für den Fall, dass das nicht klappt, kennen Sie ja Ihr Schicksal: Dann müssen Sie diese Teile der Analysearbeit auch noch selbst in die Hand nehmen.

Jedes Unterfangen sollte eine klare Vision und/oder klare Ziele haben, und die Sie sollten sowohl die beteiligten „Mitspieler“ (neuhochdeutsch: Ihre Stakeholder) kennen, wie auch ihre Spielweise – d. h. diejenigen Gebiete, die ihr Team beeinflussen kann (neuhochdeutsch: Ihren Scope) (Abb. 1).

Abb. 1: Drei Zutaten für den erfolgreichen Start

Abb. 1: Drei Zutaten für den erfolgreichen Start

Die drei Aspekte beeinflussen einander gegenseitig: Je ehrgeiziger Ihre Ziele, desto mehr Mitspieler; je größer der Scope, desto vielfältiger die Ziele. Es spielt daher keine Rolle, in welcher Reihenfolge Sie als Architekt(in) das angehen – Sie benötigen grundsätzlich alle drei.

Lesen Sie auch: Req4Arcs Teil 1: Das Dilemma

Visionen und Ziele

Sie müssen damit leben, dass sich Anforderungen mit durchschnittlich 1 bis 3 Prozent pro Monat ändern. Wir definieren Vision oder Ziele als denjenigen Teil der Requirements, die sich in dem geplanten Zeithorizont möglichst nicht ändern sollen; also als das, was wir in einer Iteration oder Entwicklungsphase wirklich anstreben.

Ein Projekt kann Ziele für unterschiedliche Zeithorizonte definieren, die aufeinander abgestimmt werden sollten. Für große Systeme haben wir drei unterschiedliche Zeithorizonte kennengelernt:

  • Strategische Ziele gelten für teilweise für drei bis fünf Jahre.
  • Ziele für den Budgetzyklus von Firmen gelten üblicherweise ein Jahr.
  • Releaseziele gelten Wochen bis wenige Monate (unter der Voraussetzung, dass Sie innerhalb eines Jahres mehrere Releases liefern).

Innerhalb der Iterationen, die zu einem Release führen, sollten Sie dafür sorgen, dass die Anforderungen möglichst stabil bleiben. An den Übergängen zwischen Iterationen gibt es jedoch Zeitfenster, in denen Sie Ziele, Inhalte und Umfang den geänderten Wünschen oder Randbedingungen anpassen können. Tom de Marco & Co. nennen das in [1] „Zeit für Änderungen“. Die Toleranz gegenüber Änderungen sollte einen Verlauf ähnlich Abbildung 2 nehmen – je näher Sie einem Release kommen, desto stabiler sollten Anforderungen bleiben.

 

Abb. 2: Änderungstoleranz bis zum Release

Abb. 2: Änderungstoleranz bis zum Release

Wie man Visionen und Ziele kommuniziert

Die klassische Art ist, Ziele einfach umgangssprachlich festzuhalten. Dafür hat sich die Formel „PAM“ bewährt. Legen Sie pro Ziel Purpose, Advantage und Metrik fest:

  • Purpose beschreibt, was Sie erreichen wollen.
  • Advantage motiviert, warum man dieses Ziel anstrebt.
  • Die Metrik gibt vor, wie man Zielerreichung überprüfen möchte.

Ein Projekt sollte höchstens eine Handvoll solcher Ziele haben. Sorgen Sie also dafür, dass Sie von Ihren Managern oder Analytikern drei bis fünf solche Aussagen (natürlich abgestimmt mit den wichtigsten Stakeholdern) bekommen. Sie wollen definitiv ohne Zielkonflikte starten können.

In der agilen Welt finden Sie einige weitere Spielarten von Zieldefinitionen. Eine davon ist die Erstellung eines Produktkoffers (Abb. 3). Neben dem Namen des Produkts und einem Logo, das allen Beteiligten das Gefühl vermittelt: „Das sind wir“ und „Das ist unser Baby“ sollten darauf drei bis fünf Haupteigenschaften des geplanten Produkts stehen. Diese sollten möglichst so formuliert werden, dass die Kunden oder Nutzer das Produkt unbedingt haben wollen.

Eine Alternative dazu sind die News from the Future. Schreiben Sie am Anfang eines Projekts einen kurzen Zeitungsartikel, von dem Sie annehmen, dass er am Tag nach der Freigabe auf der Titelseite Ihrer Lieblingszeitung erscheint. Darin wird – vor Beginn der Entwicklung – festgehalten, was Sie als Lobeshymne auf Ihr Produkt am Tag nach dem Release lesen wollen (Abb. 3).

Abb. 3: Varianten der Zielfestlegung

Abb. 3: Varianten der Zielfestlegung

Alle drei Arten der Zieldefinition finden Sie im IREB Handbuch zum Advanced Level „RE@Agile“ ausführlicher beschrieben. Die Notation spielt keine Rolle, aber als Architekt sollten Sie die Ziele des Business auf jeden Fall kennen.

Stakeholder

Der zweite wesentliche Einflussfaktor, den Projektmanagement und Analytiker bereits geklärt haben sollen, bevor Sie zu arbeiten beginnen, sind die Stakeholder Ihres Vorhabens. Wer hat welchen Einfluss? Wer kann wobei helfen oder hindern? Und auf dieser Liste sollte viel mehr stehen als nur der Sponsor des Vorhabens und Ihre potentiellen Kunden oder Nutzer. Die allerwichtigsten Ihrer Stakeholder haben erheblichen Einfluss auf die Ziele und den Scope des Vorhabens.

Eine solche Liste zu erstellen, ist kein Hexenwerk. Setzen Sie eine kleine Gruppe von Projektbeteiligten an einen Tisch und lassen Sie diese 15 Minuten lang brainstormen. Dann haben Sie wahrscheinlich schon  zwanzig bis dreißig Stakeholder identifiziert. Nun schicken Sie diese Liste an alle gefundenen Personen und fragen, wen Sie noch vergessen haben. Mit diesem Schneeballeffekt wird Ihre Stakeholderliste schnell vollständig.

Warum ist die Kenntnis der Stakeholder so wichtig? Sowohl für Analyse als auch für Architektur und Entwicklung gilt: Vergessene Stakeholder sind vergessene Requirements! Damit ist nicht gesagt, dass Sie alle Stakeholder, die Sie finden, auch intensiv am Projekt beteiligten müssen. Wenn Sie alle wichtigen potenziellen Interessenten kennen, dann können Sie aktiv entscheiden, wie viel oder wenig Sie diese in das Projekt einbinden wollen oder müssen.

Bezüglich der Form gilt, ähnlich wie für die Ziele: Sie haben Freiheiten. Nehmen Sie eine einfache Tabelle und führen Sie unter den Überschriften Rolle, Ansprechpartner, Einfluss etc. Ihre Stakeholder einfach linear auf. Oder zeichnen Sie eine Stakeholder-Map, in der Sie Stakeholder und deren Abhängigkeiten bzw. Kommunikationskanäle visualisieren. Hilfreich ist oft auch eine Stakeholdermatrix (Abb. 4), um das Verhältnis zwischen Einfluss und Interesse auszudrücken.

Abb. 4: Stakeholdermatrix

Abb. 4: Stakeholdermatrix

Für Ihre Architekturarbeit kommen dann sicherlich noch viele weitere Stakeholder hinzu: alle, die mit der Lösung zu tun haben bzw. Teilsysteme oder Technologien zuliefern. Diese spielten eventuell für Ihr Management und die Analytiker noch keine Rolle. Als Architekt(in) müssen Sie aber all diese Personen und Organisation identifizieren.

Weitere Tipps zum Umgang mit Stakeholdern haben wir für Sie zusammengestellt [2].

Scope

Der dritte Bestandteil eines Clean Starts wird oft in der Praxis ignoriert, obwohl doch die Festlegung von Scope und Kontext den weiteren Verlauf des Projekts erheblich beeinflussen. Die Definitionen der beiden Begriffe sind einfach: Scope ist der Bereich, den das Projekt aktiv gestalten kann, Ihre Spielweise. Zum Kontext gehören alle Personen und IT-Systeme (evtl. auch Hardwaresensorik und Aktuatorik), über die Sie nicht allein entscheiden können (Abb. 5). Wenn Sie im Kontext bzw. an den Schnittstellen zwischen Scope und Kontext etwas ändern wollen, dann müssen Sie mit den Nachbarn darüber verhandeln. Wenn Sie nicht verhandeln können oder dürfen, dann gelten die Festlegungen aus dem Kontext für Sie einfach als nicht beeinflussbare Randbedingungen.

Abb. 5: Abgrenzung von Scope und Kontext

Abb. 5: Abgrenzung von Scope und Kontext

Die Scope-Festlegung sollte erfolgen, um Innen von Außen unterscheiden zu können und die Schnittstellen zwischen Innen und Außen zu identifizieren. Eine einfache Notation dafür ist das sogenannte Kontextdiagramm [2], das nur aus drei Elementen besteht: Ihr System oder Produkt in der Mitte, rundherum alle Personen oder Systeme im Kontext und alle Informationen, die aus dem Kontext in den Scope fließen bzw. aus dem Scope in den Kontext – kurz gesagt: die Ein- und Ausgaben Ihres Systems. Für Analytiker und Projektmanager reicht es aus, früh im Projekt über die ein- und ausgehenden Daten Bescheid zu wissen. Sie als Architekt(in) werden die Schnittstellen später noch sehr viel genauer betrachten müssen (Technologie, Protokolle, Push oder Pull, Mengengerüste, Vertrauen in die Schnittstelle etc.). Als Einstieg gilt aber: Schnittstelle erkannt, Gefahr halbwegs gebannt. Vergessene Schnittstellen gehören zu den Dingen, die Ihnen als Architekt(in) das Leben erschweren.

Das waren nur einige Eingangsbetrachtungen zu Scope und Kontext. In der nächsten Folge werden wir uns noch ausführlicher über die Scope-Festlegung unterhalten.

Weiterer Input

Mit den Klärungen von Zielen, Stakeholdern und Scope haben Sie die wichtigsten Voraussetzungen für einen Clean Start erfüllt. Schön wäre es auch, wenn Sie einen groben Überblick über die gewünschte Funktionalität erhalten würden (z. B. in Form von Epics oder Featurelisten), wenn man Ihnen die allerwichtigsten Qualitätsziele für das Produkt verrät (z. B. die Top 3 der Qualitätsanforderungen). Sicherlich sollten auch die wichtigsten Randbedingungen klargestellt werden. Das T-Stich-Modell in Abbildung 6 fasst das grafisch zusammen. Wenn der Aufwand für die komplette Klärung der Requirements 5 Prozent beträgt, dann reichen am Anfang ein bis zwei davon aus, um volle Breite vor Tiefe zu eruieren. Parallel zu dieser Arbeit der Analytiker können Sie als Architekt(in) ja schon wichtige Eckpfeiler der Architektur festlegen (möglichst mit Ihrem Team zusammen) und auch schon erste Prototypen oder MVPs implementieren. Ausgestattet mit dem Wissen bohren Sie dann iterativ da in die Tiefe, wo es sich am ehesten lohnt.

Abb. 6: Das T-Modell mit den wichtigsten Artefakten

Abb. 6: Das T-Modell mit den wichtigsten Artefakten

Fazit

Lassen Sie uns zusammenfassend unsere Empfehlung wiederholen: Bringen Sie Ihrem Management, den Product Ownern oder Business Analysts bei, dass Ziele, Scope und Stakeholder auf jeden Fall in deren Aufgabenbereich fallen. Vielleicht können diese Stakeholder Ihnen zusätzlich noch einen groben Überblick über die gewünschte Funktionalität des Systems, die dringendsten Erwartungshaltungen bezüglich Qualität sowie die härtesten Randbedingungen liefern. Dann haben Sie in Ihrer Rolle als Architekt(in) einen entspannten Arbeitsbeginn.

In diesem Sinne: Keep educating your product owners and business analysts!

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: