Retrospektiven sind im agilen Vorgehen mittlerweile bewährte Praxis. Scrum-Teams zum Beispiel schauen regelmäßig zurück auf das, was sie im letzten Sprint getan haben, wie gut es geklappt hat und wie es den Teammitgliedern dabei ergangen ist. Am Ende einer solchen „Retro“ kommt eine Maßnahmenliste heraus, die dann im nächsten Sprint umgesetzt wird.

Das kennen wir alle.

Was weniger bekannt ist: Dasselbe sollten Sie in regelmäßigen Abständen auch in Bezug auf Ihre Architektur machen! Verbesserungsschancen finden, Risiken aufspüren, Sicherheit für Architekturentscheidungen gewinnen – all das können Sie mit Hilfe von Architekturbewertungs-Workshops erreichen.

Agile Projekte nutzen diese Praktik, um die Architekturarbeit schlank, iterativ und auf die Qualtätsziele fokussiert durchzuführen. Große und lange laufende Projekte lenken damit die Aufwände für die Architekturüberarbeitung und -pflege auf die richtigen Stellen im System, also dort, wo die kostentreibenden Probleme liegen.

In Teams kommt bei der Architekturarbeit nach einigen Iterationen Fragen auf:

  • Sind wir eigentlich noch auf dem richtigen Weg?
  • Passt das so, was wir in letzter Zeit an Architekturentscheidungen gefällt haben?
  • Wie sieht eigentlich das große Ganze aus?
  • Ist das alles in sich stimming, was wir entwerfen?
  • Passt es noch zu den Anforderungen, die wir haben, fachlich und qualitativ?

In den Projekten, die ich als Coach betreue, hat es sich bewährt, wenn die Teams alle 4 bis 8 Wochen für einen Nachmittag zusammenkommen, ihre Architektur gegen die Anforderungen halten und sich fragen:

  • Was wollten wir in der letzten Zeit umsetzen?
  • Welche zentralen Architekturentscheidungen haben wir getroffen?
  • Hat uns etwas behindert oder haben wir Risiken entdeckt?
  • Welche Veränderungen hat es an der Architektur gegeben?

Als Inputs zu solch einem Workshop können Architekturbilder, Messergebnisse aus dem Build, Annahmen und Entscheidungen der letzten Zeit dienen. Oder auch die Qualitätsmerkmale und Szenarios, die aus den Anforderungen der Kunden hervorgegangen sind. Im Workshop werfen wir dann gemeinsam einen Blick auf die Architektur als Ganzes, dann auf die Anforderungen. Zum Schluss sprechen wir wichtige Szenarios durch, die mit den geforderten Qualitätseigenschaften des Systems zu tun haben (Beispiel Verfügbarkeit: Ausfall eines wichtigen Servers).

Am Ende eines solchen Workshops kommen Risiken, Vorteile und ToDos als Ergebnisse heraus, die die Architektur betreffen. Die Teams arbeiten diese Erkenntnisse in der folgenden Zeit in ihre Architektur ein und nutzen ihre Arbeitskraft dadurch sehr ökonomisch.

Architektur-Reflexion bringt Erkenntnisse, die im normalen Arbeitsalltag nicht entdeckt würden !

Click To Tweet

Teams erzählen mir regelmäßig, dass solche Architektur-Reflexion Erkenntnisse bringt, die im normalen Arbeitsalltag nicht entdeckt worden wären. Sie ermöglichen es den Teams, mit hoher Geschwindigkeit vorwärts zu arbeiten, weil die Qualität der Software und die Flexibilität der Architektur hochgehalten werden.

Die Methoden für diese Art von Architekturbewertung sind erlernbar. Ich biete dazu Trainings an, der nächste Termin ist Anfang Oktober. Die Trainings sind akkreditiert vom iSAQB®️ – Sie bekommen dafür Credit Points zum CPSA-A, falls Sie die (advanced level-)Zertifizierung zum Softwarearchitekturexperten anstreben.

Wenn Sie sich zum Kurs anmelden möchten, hier die Termine, Themen und Anmeldeseiten.

Titelfoto

Danke an den Fotografen Alex Vasey:

Alex Vasey (@alexrvasey) | Unsplash Photo Community
See the best free to download photos, images, and wallpapers by Alex Vasey on Unsplash.
UnsplashUnsplash
, Agile Entwicklung , Softwarearchitektur