Über unsMediaKontaktImpressum
Roland Mast 21. April 2015

Architektur-Kata als Trainingsform agiler Teams

Bei den japanischen Kampfsportarten ist sie eine Jahrhunderte alte Tradition, bei Softwareentwicklern wird sie bereits seit etlichen Jahren praktiziert und für Softwarearchitektur hat sie Ted Neward auf der ÜberConf 2010 in Denver bekannt gemacht. Die Kata – eine Übungsform bei der dieselbe Aufgabe immer und immer wieder durchgeführt wird, mit dem Ziel, sich bei jeder Wiederholung zu verbessern.

Ich hatte auf der JAX 2011 die Gelegenheit, Ted Neward [1] kennenzulernen und bei einer Kata teilzunehmen. Seither führe ich regelmäßig Architektur-Katas mit Kollegen, Kunden und auf Konferenzen durch [2]. Katas sind eine geeignete Form, um Fähigkeiten und Fertigkeiten zu trainieren und können hervorragend zu Ausbildungszwecken eingesetzt werden. Überschaubare, aber realistische Problemstellungen dienen als Grundlage, um die Architekturarbeit zu trainieren. In agilen Teams soll diese Arbeit von möglichst vielen Teammitgliedern übernommen werden. Die Kata ist eine geeignete Form, das Architekturthema zu verbreiten und die Betroffenen für das Thema zu sensibilisieren.

Im weiteren Verlauf wird immer wieder vom Softwarearchitekten die Rede sein. Dabei ist jeweils die Rolle gemeint, die die Architekturarbeit betreibt. Im agilen Umfeld ist das in der Regel kein Jobtitel, sondern die Aufgaben werden von den Entwicklungsteams übernommen. Das Durchführen von Katas zur Wissens-  und Kompetenzverbreitung ist ein Baustein, um Architekturarbeit in agilen Teams zu etablieren. Intensiv mit dem Thema der Softwarearchitektur in agilen Teams beschäftigten sich die „Vorgehensmuster für Softwarearchitektur“ von Stefan Toth [3].

Kata

Der Name Kata stammt aus den japanischen Kampfkünsten und betont die Bedeutung von Praxis und häufiger Wiederholung für das Lernen. (Wikipedia)

Softwarearchitektur-Aufgaben

Welche Aufgaben eines Softwarearchitekten lassen sich nun in einer Kata trainieren? Die wichtigsten Aufgaben haben Gernot Starke und Peter Hruschka treffend beschrieben [4] – sie sind in Abb. 1 dargestellt.

Dieses vielfältige Aufgabengebiet möchte ich im Folgenden etwas genauer betrachten:

  • Anforderungen und Randbedingungen klären:
    Als Architekt muss man ein Verständnis für die zu entwickelnde Anwendung haben und die fachlichen Anforderungen verstehen, um darauf aufbauend die passende Architektur zu entwickeln. Dies gelingt am besten durch direkte Kommunikation mit den Kunden, Anwendern und weiteren Stakeholdern. In agilen Projekten hat sich dazu die Phase-0 etabliert, in der die wichtigsten Anforderungen abgesteckt werden und eine erste Architekturvision [5] entsteht.
  • Strukturen entwerfen:
    Sobald ein Bild des zu erstellenden Systems vorhanden ist, kann dieses in passende Strukturen gegossen werden. Ausgehend vom Systemkontext werden wichtige Subsysteme und ihre Beziehungen dargestellt. Dieses grobe Bild wird im agilen Umfeld entwicklungsbegleitend an den erforderlichen Stellen weiter verfeinert. Die Architektur entsteht nach und nach mit der Umsetzung der Anforderungen.
  • Technische Konzepte entwerfen:
    Einige Design-Entscheidungen haben Auswirkungen auf das gesamte System (z. B. Umsetzung von Logging, Exception Handling, Persistenzanbindung, Resilienz, asynchrone Kommunikation) und sollten im gesamten System einheitlich gelöst werden. Diese weitläufigen und somit architekturrelevanten Entscheidungen müssen erkannt werden, um sie anschließend zu verallgemeinern, zu dokumentieren und allen betroffenen Entwicklern zugänglich zu machen. Netflix zum Beispiel gibt den Teams größtmögliche Freiheiten bei der Umsetzung der Microservices für die sie komplett verantwortlich sind. Wichtige technische Konzepte werden jedoch identifiziert und den Teams in Form von gut dokumentierten Open-Source-Bibliotheken zugänglich gemacht [6].
  • Architektur kommunizieren:
    Architektur muss in verschiedenste Richtungen kommuniziert werden. Die Stakeholder interessiert es, ob ihre Anforderungen entsprechend umgesetzt werden. Die Entwickler müssen die Architekturkonzepte verstehen, damit diese auch passend umgesetzt werden. Hierbei hilft die gemeinsame Arbeit im Team. Die Dokumentation deckt ebenfalls einen Teil der Kommunikation ab. Hierzu hat sich der Einsatz von Templates [7] und Wikis bewährt.
  • Umsetzung betreuen:
    Die Ideen der Softwarearchitektur müssen in die Entwicklungsteams getragen werden. Dies erfolgt durch Kommunikation, aber noch besser durch aktive Zusammenarbeit während des gesamten Projekts. Dabei übernimmt das Team die Architekturarbeit. In der Praxis sieht dies oft so aus, dass sich einige erfahrene Entwickler dieser Aufgabe annehmen und darauf achten, dass auch die anderen Teammitglieder in Entscheidungen einbezogen werden.
  • Architektur bewerten:
    Bei der Architekturbewertung geht es darum, mittels definierter Szenarien die Erreichung der Qualitätsziele durch die Architektur zu überprüfen. Dazu gibt es verschiedene etablierte Verfahren [8]. Das Themengebiet ist so umfangreich, dass es an dieser Stelle nicht weiter vertieft werden kann.

In einer Architektur-Kata werden fast alle dieser Aufgaben trainiert. Die Schwerpunkte der Gruppenarbeit liegen auf „Anforderungen und Randbedingungen abklären“ und „Strukturen entwerfen“. In der anschließenden Präsentation muss die Architektur kommuniziert werden, die zuvor meist in Diagrammform dokumentiert wurde. Die anderen Teilnehmer bewerten die Architektur und geben Feedback.

Den erfolgreichen Einsatz der Architektur-Kata zu Ausbildungszwecken konnte ich zusammen mit 14 weiteren Kollegen der Sybit GmbH vor einiger Zeit erfahren. Wir haben uns über den Zeitraum eines halben Jahres mit dem Thema Softwarearchitektur auseinandergesetzt und mit dem Zertifikat der iSAQB (foundation level) [9] abgeschlossen. Dabei wurden die Themengebiete von den Teilnehmern selbstständig erarbeitet und gegenseitig geschult. Jeweils eine Architektur-Kata vor und nach der Schulung zeigten den Teilnehmern deutlich die erzielten Lernerfolge auf. Das Format kam so gut an, dass wir es dieses Jahr weiteren Mitarbeitern anbieten werden.

Ablauf der Architektur-Kata

Für den Ablauf einer Architektur-Kata hat sich folgendes Vorgehen bewährt: Die Teilnehmer werden in Gruppen mit 3-5 Teilnehmern eingeteilt. Damit lässt sich eine Kata mit 6-30 Personen durchführen. Zu einer gegebenen Problemstellung wird in Gruppenarbeit eine Softwarearchitektur erstellt und in Form von Diagrammen skizziert. Dabei erfahren die Teilnehmer, wie schwierig es sein kann, eine zu den Anforderungen passende Architektur zu erarbeiten. Sie werden erkennen, wie wichtig es ist, die richtigen Fragen an die Stakeholder zu stellen. Das Ergebnis der Arbeit wird in Form von Diagrammen festgehalten, die den anderen Teilnehmern präsentiert und zur Diskussion gestellt werden. Aus dem Feedback lernen die Teilnehmer ihre Diagramme besser zu strukturieren und effektiver zu gestalten. In einem zweiten Durchlauf der Kata werden die neuen Erkenntnisse direkt wieder in die Tat umgesetzt.

Gestartet wird mit der Vorstellung der Anforderungen, die maximal eine Seite umfassen sollte. Das Thema sollte nicht zu kompliziert sein, da es doch in recht kurzer Zeit erfasst und verstanden werden muss. Es sollte in das Tätigkeitsfeld der Teilnehmer passen (sofern dies überhaupt bekannt ist), aber der aktuellen Arbeit nicht zu ähnlich sein.

Nach der Vorstellung der Aufgabe beginnt die eigentliche Kata, die aus mehreren Durchgängen besteht. Der Moderator nimmt dabei die Rolle des Product Owners ein und beantwortet die Fragen der Teams zu den Anforderungen. Dazu empfiehlt es sich, entsprechend vorbereitet und auf Fragen gefasst zu sein, die weit über die Kurzspezifikation hinausgehen. Das Spektrum reicht häufig von Budgetfragen bis zu technischen Detailfragen.

Architektur Kata – 1. Durchgang

50 Minuten für den Architekturentwurf

  • Beantworte die wichtigsten Architektur- und Designfragen
  • Berücksichtige die wichtigen Qualitätsziele und Randbedingungen
  • Dokumentiere mit Hilfe von Diagrammen, Tabellen, Listen

20 Minuten für gegenseitige Präsentation und Feedback

Feedback

Für die Feedbackrunden gehen jeweils zwei Gruppen zusammen und stellen sich gegenseitig ihre Ergebnisse vor (Abb. 2). Bei einer ungeraden Gruppenanzahl übernimmt am besten der Moderator die Aufgabe des Feedbacks für eine Gruppe. Ansonsten nimmt der Moderator als Beobachter an der Präsentation teil und unterstützt gegebenenfalls die Teams durch gezieltes Nachfragen. Dabei können folgende Fragen hilfreich sein:

  • Was ist das umzusetzende System und was gehört zum Kontext?
  • Welches sind die wichtigsten Systemteile und in welcher Beziehung stehen sie zueinander?
  • An welchen Stellen habt ihr Flexibilität eingebaut?
  • Wie seid ihr vorgegangen?
  • Welche Notation habt ihr benutzt?
  • Wie viele Diagramme habt ihr erstellt?
  • Welche Detailtiefe habt ihr erreicht?

Architektur-Kata - 2./3. Durchgang

30 Minuten für

  • Systemkontext und Strukturen
  • Explizite Darstellung des Systemkontexts und der Beziehungen zu Drittsystemen
  • Verantwortlichkeiten der Komponenten
  • Dokumentation der Strukturen in Form von geschachtelten Abstraktionsebenen
  • Verbesserte Diagramme durch Legende und verständliche Verwendung von Notation, Formen, Farben usw.
  • Ziele und Lösungsansätze
  • Qualitätsziele + Randbedingungen
  • Lösungsansätze passend zu den Qualitätszielen

20 Minuten für gegenseitige Präsentation und Feedback

In Abb. 2 ist ein typisches Ergebnis nach der 2. Iteration einer Architektur-Kata dargestellt. Bei dieser Kata ging es um das Übungsprojekt AWAS (Arrive With A Smile), einem Internet-Portal eines Limousinen-Services. In der Kontextsicht in der Mitte ist klar das zu entwickelnde System zu erkennen. Ebenso ist der Zusammenhang zu den zu integrierenden Systemen dargestellt. Auf der rechten Seite ist die innere Struktur von AWAS skizziert. Am rechten Rand ist eine Vielzahl von Adaptern aufgelistet. Damit soll der Vielzahl und Änderungshäufigkeit der anzuschließenden Drittsysteme und den Architekturzielen Erweiterbarkeit und Wartbarkeit Rechnung getragen werden.

Bei den Katas, die ich bisher durchgeführt habe, gab es immer wieder Punkte, denen im Architekturentwurf und dessen Dokumentation nicht ausreichend Beachtung geschenkt wurde, die jedoch maßgeblich für die Qualität und das Verständnis erforderlich sind:

  • Qualitätsziele werden nicht explizit gemacht
  • Überladung der Diagramme mit zu viel Informationen
  • Zu früher Fokus auf technische Details
  • Verwendung von Abkürzungen ohne Erklärung
  • Legende zur Bedeutung von Linien, Pfeilen, Formen und Farben

Dies ist jedoch nur eine geringe Auswahl der Punkte, die beachtet werden müssen. Während der Kata ist schlussendlich der Moderator mit seinem Know-how gefordert, die Teilnehmer durch entsprechende Unterstützung auf einen besseren Weg zu bringen.

Fazit

Eine Architektur-Kata trainiert

  • die Umsetzung von Anforderungen in eine passende Softwarearchitektur,
  • die richtigen Fragen an die Stakeholder zu stellen, um die Anforderungen zu verstehen
  • das Erkennen und Priorisieren von architektur-relevanten Anforderungen und
  • die Dokumentation in Form von aussagekräftigen Diagrammen.

Die Form der Kata bietet sich an, um sowohl allgemeines Architektur-Know-how aufzubauen, als auch als ein Teil der Architekturarbeit in Projekten. Im Team kann damit eine Architektur-Vision erstellt oder spezifische Aspekte der Architektur erarbeitet werden. Zu Ausbildungszwecken sind Katas hervorragend geeignet und ebenfalls ein hervorragendes Mittel für die Überprüfung von Lernerfolgen. Die interaktive und zeitlich kompakte Form fördert die intensive Zusammenarbeit der Teilnehmer, die nebenbei lernen, sich auf das Wesentliche zu konzentrieren. Versuchen Sie es einfach auch einmal mit Ihrem Team. Viel Erfolg und Spaß dabei!

Quellen

[1] Technical Blog von Ted Neward: Architectural Katas
[2] Architektur-Kata auf der OOP 2015
[3] Toth, Stefan: Vorgehensmuster für Softwarearchitektur, Hanser 2014
[4] Starke, Gernot: Softwarearchitekten: Die Zehnkämpfer der IT
[5] Roock, Stefan; Pichler, Roman: Die Architekturvision in Scrum
[6] Netflix
[7] Template für Architekturdokumentation
[8] Wikipedia: Szenariobasierte Architekturbewertung
[9] iSAQB-Zertifizierung

Autor

Roland Mast

Roland Mast ist Software-Architekt, Senior-Entwickler und SCRUM-Master bei der Sybit GmbH. Er beschäftigt sich mit großen Content-Management-Systemen, Web-Applikationen im Medienumfeld und Software-Entwicklung in Java. Wichtig...
>> Weiterlesen
botMessage_toctoc_comments_9210