Erstes öffentliches Architektur Kata in Mannheim – ein Erfahrungsbericht

Vorletzte Woche Montag haben sich 10 Interessierte zum ersten öffentlichen Architektur-Kata im Rahmen des Agile Monday Mannheim im Club Speicher 7 am Mannheimer Hafen eingefunden. Mit dabei waren sowohl erfahrene Software-Haudegen als auch junge IT-Consultants und Architekten.

Was war die Motivation für die Teilnehmer?

Architekten bekommen in ihrem Arbeitsleben typischerweise nur eine Handvoll Möglichkeiten, eine komplette Softwarearchitektur auf der grünen Wiese zu entwerfen. Damit hat man nur wenige Versuche, ein guter Architekt zu werden. Katas können hier in Form von architektonischen Trockenübungen helfen, sich in ungezwungener Atmosphäre mit einem fiktiven Beispiel und gerade erst kennengelernten Mitstreitern weiterzubilden. Es werden bei einem Architekturkata aber nicht nur die fachlichen Kompetenzen aufgebaut, auch die sozialen Komponenten, die sog. Softskills können erweitert werden. Als Coaches beobachten wir dabei immer wieder, wie sich einzelne bewusst zurücknehmen und andere von dem gewonnenen Freiraum profitieren.

Vorgehensweise

Das Ziel eines “Architectural Kata” ist die praktische Einführung in den Entwurf einer Softwarearchitektur anhand einer vorgegebenen Problemstellung. Diese wird in mehreren, in unserem Fall zirka 20minütigen Durchgängen bearbeitet. Wir haben uns bei diesem Kata bewusst dafür entschieden, eine offene Problemstellung und ein breites Trainingsziel zu definieren, um den Anforderungen an den unterschiedlichen Wissenstand gerecht zu werden. Die Lösung der Aufgabe wurde dabei in kleinen Gruppen erarbeitet.

Um sinnvolle Lösungsvorschläge machen zu können, galt es zunächst die richtigen Fragen an die Stakeholder, in diesem Falle die Coaches, zu stellen und daraus die nötigen Schlüsse zu ziehen. Alle Gruppen wählten für die erste Runde eine analytische Herangehensweise, kristallisierten zunächst den für sie wichtig erscheinenden Teil der fachlichen und technischen Anforderungen heraus, um darauf basierend die notwendigen Entscheidungen treffen zu können. Ähnlich wie bei einem Code Kata in Coding Dojos bzw. Code Retreats ist das aber eine Übungssache. In der ersten Runde verzettelt man sich oftmals zu sehr in Details. Außerdem muss sich das zufällig zusammengewürfelte Team zunächst finden. Darum bestehen Architektur-Katas immer aus mehreren aufeinander aufbauenden Runden.

Die erste Übungsrunde schloss mit einem Review ab. Je nach Anzahl der Gruppen kann man es als Peer oder als Public Review durchführen. Beim Peer Review stellen sich jeweils zwei Gruppen gegenseitig ihre Ergebnisse vor und stellen Fragen bzw. geben Feedback. Bei ungerader Anzahl von Gruppen stellen alle ihre Ergebnisse jeweils in einer großen Runde vor. Das Ziel ist es, den Außenstehenden von der eigenen Idee zu überzeugen. Das kann rein mit Worten passieren, sinnvoll ist aber immer eine bildliche Unterstützung in Form von Diagrammen. Ziel ist das Verkaufen des Entwurfs. Dazu müssen die geschlossenen Kompromisse und Entscheidungen für alle in einer nachvollziehbaren Form kommuniziert werden. Natürlich wird dabei von Seiten der Coaches und der anderen Teilnehmer auch Feedback zur Dokumentation gegeben, so dass sich hier weitere Lernerfolge einstellen.

Nach einer kurzen Pause und einer kleinen Theorie-Einlage zu Sichten in der Architektur-Dokumentation starteten die Teams in eine zweite Runde. Diesmal waren einige fachliche und technische Randbedingungen vorgegeben, um die folgenden Diskussionen stärker zu kanalisieren und den Teilnehmern so trotz der Kürze der Zeit auch konkrete Entscheidungen (Modularisierung, Technologien, Verteilung, Laufzeit-Verhalten usw.) zu entlocken. Das konnte in Form von Baustein-, Laufzeit- und Verteilungssichten geschehen, um den meist noch sehr groben Überblick (Systemkontext) aus der ersten Runde zu verfeinern. Alternativ hätten sich die Teilnehmer auch einen Kernaspekt herausnehmen und diesen dann etwas detaillierter herausarbeiten können. In unserer Veranstaltung entschieden sich die Gruppen für den ersten Weg.

Fazit

Letztlich waren nach der zweiten Review- und Feedbackrunde alle mit ihren Ergebnissen zufrieden. Ziel der knapp zwei Stunden war es nicht, eine vollständige Architektur zu entwerfen. Vielmehr ging es um das Miteinander-Arbeiten, das Voneinander-Lernen, das Kennenlernen einzelner Entwurfsaspekte, das Dokumentieren und Kommunizieren. Das sind alles Punkte, die man auch in der tagtäglichen Arbeit benötigt und hier in einem ungezwungenen Rahmen ohne jeglichen Erfolgsdruck einfach mal nur ausprobieren konnte. Die Teilnehmer hätten sich dabei etwas mehr Zeit je Runde gewünscht. Aber das enge “Timeboxing” gehört zum Konzept und fördert die Konzentration auf die wesentlichen Aspekte des Entwurfs. Etwas was man im Berufsleben leider häufig vermisst.

Die Zeit verging leider viel zu schnell. Zum Glück konnten noch einige der Aspekte im Anschluss bei einem Kaltgetränk diskutiert werden. Wir wollen in näherer Zukunft weitere öffentliche Architektur Katas anbieten. Wer dieses Format als eine intensive Ganztagesveranstaltung für sich und seine Abteilungskollegen ausprobieren möchte, kann auch unseren Workshop Architektur-Katas zum Training agiler Teams buchen.

Short URL for this post: http://wp.me/p4nxik-2vD
Patrick Rudloff

About Patrick Rudloff

Patrick Rudloff ist bei der Mannheimer Firma OIO - Orientation in Objects GmbH als Trainer, Berater und Entwickler tätig. Dort beschäftigt er sich mit agilen Methoden, Softwarearchitektur und dem Atlassian Tool-Stack. Patrick twittert unter @RudloffPatrick.
This entry was posted in Agile Methods and development, Did you know? and tagged , , , , , . Bookmark the permalink.

Leave a Reply