Auf den ersten Blick scheinen sich agile Frameworks nicht sonderlich mit Architekturarbeit zu vertragen. Erst in der jüngsten Neufassung des Scrum Guides wird überhaupt von „Entwicklungsarchitekturen“ gesprochen, ohne aber dabei konkret zu werden, wie in Sprints auf eine Zielarchitektur hingewirkt werden kann. Scrum sieht bewusst keine separate Rolle für Software-Architekten vor. Und das kontinuierliche Entwickeln der Inkremente, vom Durchstichprototypen bis zum funktional vollständigen Produkt, dient ausdrücklich nur einem Ziel: der Auslieferung lauffähiger Software. Doch wie kann ein agiles, sich selbst organisierendes Entwicklungsteam nun sicherstellen, dass das ausgelieferte Produkt eine „gute“ Architektur hat oder in eine außerhalb des Teams definierte Zielarchitektur passt? In diesem Artikel werden drei Ansätze vorgestellt, wie agile Teams Architekturarbeit gezielt anpacken können:
- Kontinuierliches Refactoring
- Things That Matter-Matrix einsetzen
- Technische Schulden transparent machen
Kontinuierliches Refactoring
Architekturarbeit findet im Verlauf einzelner Zyklen statt. In Projekten mit hoher Produktunsicherheit werden wichtige Architekturvorgaben und -entscheidungen durch Architekturteams getroffen. Ein Unterschied von solchen erkenntnisgesteuerten Projekten im Vergleich zu annahmegesteuerten Projekten ist jedoch, dass nicht versucht wird, solche Entscheidungen gänzlich im Vorhinein zu treffen, sondern dass die endgültige Architektur auf Basis der Erfahrungen und des Feedbacks bisheriger Zyklen iterativ entsteht. Das erfordert jedoch eine kontinuierliche Überprüfung, Bewertung und Überarbeitung (englisch: Refactoring) der Softwarearchitektur durch die Entwicklungsteams. Um diese Arten von Aktivitäten einzuplanen, die keine vom Kunden wahrnehmbare Funktion als Ergebnis haben, sind Backlog-Elemente vom Typ technische Arbeit oder Wissenserwerb möglich. In einem Release Train werden solche Elemente auch im Zyklus „Innovation and Planning“ gezielt mitberücksichtigt (Leffingwell, 2017).
- Möchten Sie tiefer in das Thema Agilität einsteigen? Dann empfehlen wir Ihnen unseren Tageskurs zum agilen IT-Architekturmanagement
- Wie fit sind Sie in Scrum? Oder anders gefragt: Sind Sie https://www.campuslab-online.de/ Testen Sie sich jetzt mit 200 Fragen rund um das Scrum Framework!
Things-That-Matter-Matrix
Eine Things-That-Matter-Matrix (TTM-Matrix) ist eine Veranschaulichung, bei der Backlog-Elemente bestimmten architektonischen Elementen oder Aktivitäten zugeordnet werden, die für deren Umsetzung eine Rolle spielen. Sie wurde von King (2010) vorgestellt und ist unter anderem in Röpstorff/Wiechmann (2012) beschrieben. Es gibt aber keine feste Vorgabe, wie eine konkrete TTM-Matrix aussieht. Sie sollte zur Art des Projektes und der Arbeitsweise des Projektteams passen. In der Matrix unten wurden zum Beispiel die typischen Schichten einer Unternehmenswebanwendung als Spalten ausgewählt. In den einzelnen Zellen der Tabelle wird jeweils der erwartete Aufwand grob in T-Shirt-Größen geschätzt. Leere Zellen bedeuten, dass ein architektonisches Element für eine User Story keine Rolle spielt. Je stärker eine Zelle gewichtet wird desto eher spielen sie eine Rolle bei der Entwicklung der Softwarearchitektur.
Technische Schulden
Dieser Begriff ist eine Metapher, um bewusst oder unbewusst eingebaute Qualitätsmängel zu beschreiben (Röpstorff/Wiechmann, 2012). Wird etwa eine gewünschte Funktion stets sehr schnell und ohne auf die Architektur zu achten implementiert und werden oft Tests übersprungen, so kann die Funktion zwar recht schnell geliefert werden. Im Softwaresystem sind dadurch jedoch technische Schulden entstanden, die in Zukunft zu größeren Aufwänden führen, z. B. immer schlechtere Wartbarkeit und Testbarkeit. Falls das Projektteam erkannte technische Schulden kontinuierlich dokumentiert und dem Product Owner bzw. den Entscheidern über Ressourcen angemessen veranschaulicht, kann gezielt über die Begleichung der Schulden in Form von technischer Arbeit beispielsweise durch Refactoring entschieden werden. Die konkrete Einplanung dieser Aufgaben erfolgt über Backlog-Elemente vom Typ „technische Arbeit“.
Die Zunahme technischer Schulden kann sowohl organisatorisch als auch technisch überwacht werden. Die organisatorische Überwachung kann mit einer strikten Handhabung einer Definition of Done erreicht werden, wo entsprechende Maßnahmen zur Qualitätssicherung verbindlich vorgeschrieben werden. So kann das Weglassen von Tests oder der Nicht-Aktualisierung der technischen Dokumentation vermieden werden. Auch der Release Train plant Zyklen ein, in denen technische Aufräumarbeiten regelmäßig durchgeführt werden können. Eine technische Möglichkeit zur Überwachung technischer Schulden ist der Einsatz von automatisierten Softwaretests und die automatisierte und kontinuierliche Integration.
Literatur
- King, J. (2010): Estimation Toolkit. (URL: http://www.infoq.com/articles/estimation-toolkit [letzter Zugriff: 13.03.2018]).
- Leffingwell, D (2007): Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley.
- Röpstorff, S./Wiechmann, R. (2012): Scrum in der Praxis. Erfahrungen, Problemfelder und Erfolgsfaktoren. dpunkt.verlag, Heidelberg. ISBN 978-3-898647922.
