Ich habe gerade einen Vortrag für die JAX eingereicht in dem ich über Architekturarbeit mit mehreren Teams sprechen möchte. Nach einer User-Group Teilnahme in Leipzig habe ich gesehen, dass das Thema durchaus von breitem Interesse ist. Architekturbewertung (im nicht akademischen Sinn) ist hier, meiner Meinung nach, ein sehr hilfreiches Werkzeug.
Größere Projekte stellen sich oft die Frage wie viel Steuerung und welche zentralen Rollen benötigt werden wenn man „agil“ arbeiten möchte. Die Architekturarbeit berühren vor allem zwei Fragestellungen immer wieder: Wie geht man mit Abhängigkeiten zwischen Teams um und wie sorgt man für Transparenz, Kommunikation und Zielrichtung (Teamübergreifend)?
Abhängigkeiten zwischen Teams
Grob gesprochen gibt es zwei Arten von Abhängigkeiten die hier interessant sind:
- Terminliche Abhängigkeiten, bei denen Team A etwas umgesetzt haben muss bevor Team B damit arbeiten kann. Diese Abhängigkeiten sind oft fachlicher Natur. Team A arbeitet beispielsweise an einer zentralen Komponente oder an einem Systemteil der im Geschäftsprozess weiter vorne steht.
- Abhängigkeiten aufgrund querschnittlicher Aspekte. Diese Abhängigkeiten entstehen bei mehreren „Cross-funktionalen“ Teams, da sich alle Teams Gedanken zu Sicherheit, Persistenz, UI-Frameworks, etc. machen müssen. Der Auslöser sind hier meist nicht-funktionale, qualitative Anforderungen.
Terminliche Abhängigkeiten können meist ganz gut „geplant“ werden. In Scrum-Projekten würde etwa der Product Owner (bzw. sein Team) für eine geeignete Zuteilung von Stories zu Teams und Releases sorgen. Die meisten Abhängigkeiten können so lokal gehalten werden, ohne zu große Kommunikationshürden aufzubauen. Um diese Aufgabe zu bewältigen, ist in größeren Projekten ein gewisses Maß an fachlicher Analyse und Abhängigkeitsmanagement notwendig. Die Architekturaufgabe der fachlichen Strukturierung muss teilweise früh im Projekt angegangen werden, die genaue Ausgestaltung der Schnittstellen kann aber durchaus später erfolgen.
Abhängigkeiten aufgrund querschnittlicher Aspekte sind schwerer zu antizipieren. Arbeitet man alle übergreifenden Fragestellungen vorrausschauend aus, landet man schnell beim Wasserfall. Auf der anderen Seite führt völlige Ignoranz auf Anforderungsebene zu Insellösungen, Redundanzen, wenig Integrität und mehrfacher Arbeit. Ein Lösungsansatz muss hier Verantwortung an die Teams abgeben, gleichzeitig aber Kommunikation zwischen den Teams fördern, den Austausch zielrichten und entsprechende Entscheidungen möglich machen, ohne in „Design by Comitee“ abzudriften.
Eine Hälfte der Lösung kann das Verankern von qualitativen Anforderungen in den Backlogs sein (wie hier beschrieben: http://bit.ly/ehcVux). So sind sich die Teams dieser Abhängigkeiten bewusst und können entsprechend kommunizieren. Allgemeine Merker werden dabei meist gemeinsam ausgearbeitet (Stichwort Scrum of Scrums), Qualitätsgeschichten müssen in den meisten Fällen abgestimmt werden und Akzeptanzkriterien können in Einzelfällen zu breiteren Lösungen (wie Frameworks) führen, die dann ebenfalls abgestimmt werden müssen.
Transparenz, Kommunikation und Zielrichtung
Das Erkennen von Abhängigkeiten ist ein guter Schritt, aber wie funktioniert nun die genannte „Abstimmung“? Die zweite Hälfte einer möglichen Lösung heißt für mich Architekturbewertung. Der Kern dieser Methodik liegt abseits der akademischen Methoden und „Expertenreviews“ in der zielgerichteten Zusammenarbeit. In Workshops mit möglichst breiter Stakeholder-Beteiligung werden Lösungsoptionen gegen Anforderungen gehalten. (Architekturbewertung stelle ich im Detail hier vor: http://bit.ly/hKkZ7r)
In obigem Beispiel, wären die wichtigsten Stakeholder auf jeden Fall Mitglieder aus den betroffenen Teams und der (ein) Product Owner. Lösungsoptionen werden vom bearbeitenden Team in die Runde getragen und dort auf breite Anwendbarkeit und Risiken geprüft. Im Prinzip handelt es sich um ein Scrum of Scrums mit einigen unterstützenden Werkzeugen. Durch die lokale Erarbeitung, die getrennte Bewertung und die explizite Benennung dieses Vorgangs richtet man Kommunikation klar auf ein Ziel aus. Dabei schrumpft der Kommunikationsbedarf auch in größeren Projekten auf ein handhabbares Ausmaß. Um breite Transparenz zu erzeugen, kann man die Workshops in wechselnder Zusammensetzung durchführen oder stille Beobachter erlauben.
Und der Architekt?
Auch wenn die Rollengestaltung immer eine sehr individuelle Sache ist, ist der Architekt als Rolle in der Architekturbewertung nicht zentral. Es geht um Architekturentscheidungen, die durch die Arbeit mit Qualitätsanforderungen im Backlog getroffen werden. Die Teamübergreifende Abstimmung kann auf dieser Basis gut ohne eine entsprechende Rolle auskommen. Die Abhängigkeiten aufgrund querschnittlicher Aspekte erfordern also nicht zwangsläufig einen Architekten. Für die angesprochene fachliche Strukturierung und die Verankerung von Qualitätsanforderungen könnte der Product Owner allerdings Unterstützung brauchen…
Mehr dazu hoffentlich auf der JAX.