Architekturarbeit gemeinsam gestalten

Wir arbeiten in einem zehnköpfigen Team. Unser System unterstützt Disponent:innen dabei, Transporte effizient zu steuern und zu überwachen. Es handelt sich um eine datenintensive Web-Anwendung auf Basis von Java, Spring Boot und Angular – mit vielen Listenansichten, Echtzeitinformationen und unterschiedlichen Quellsystemen.

Nach über drei Jahren Entwicklung war unser System stark gewachsen: sechs Services, zahlreiche Schnittstellen, kontinuierlicher fachlicher Ausbau. Gleichzeitig bildeten sich gewisse Know-how-Inseln und nur einzelne Kolleg:innen überblickten das Gesamtsystem und dessen Architekturidee. Das Team ist technisch versiert, aber in der Kommunikation eher zurückhaltend. Verstärkt wurde dies durch eine langjährige Remote-Arbeitsweise, die informelle Gespräche und spontane Diskussionen über Architektur erschwerte. Im Team gab es zunehmend kritische aber oft unspezifische Rückmeldungen zur Qualität der Software.

Wir suchten daher gezielt nach einer Methode, die es uns ermöglichen würde, Qualitäts- und Architekturfragen gemeinsam zu adressieren und alle Teammitglieder aktiv einzubinden. LASR – der Lightweight Approach for Software Reviews – wirkte wie das strukturierte aber niedrigschwellige Format, das wir suchten, um Architekturthemen ins Team zu holen.

Wir wollten möglichst alle Beteiligten physisch an einen Tisch bringen, zur Teilnehmergruppe gehörte auch unsere PO. Wir haben uns auf den Kern von LASR beschränkt, also ohne Konfidenzerhöhung mit LASR+ und uns insgesamt 5 Stunden Zeit dafür genommen.

Das Mission Statement mussten wir nicht komplett neu erfinden, in die Richtung gab es schon etwas. Wir haben den vorhandenen Text ausführlicher formuliert und etwas ausgeschmückt. Der erste Satz lautete “Überwache Transporte auf einen Blick von Start bis Ziel mit intelligent kombinierten Fahrplänen im In- und Ausland.“

Für die Bestimmung der Top-5 Qualitätsziele haben wir den Top-5-Challenger leicht angepasst. Nach dem Auslegen der zufälligen Top-5 Zielkarten, wurden die restlichen Kandidaten-Karten in der Gruppe verteilt. Jede/r sollte als Einstieg in eine Diskussion für die eigene(n) Karte(n) sagen, ob sie eingetauscht oder zur Seite gelegt werden sollte(n). Das hatte zum Ziel, alle von Anfang an aktiv zu involvieren.

Die fünf Qualitätsziele, die wir auf diese Weise für unseren Bewertungsmaßstab ermittelt haben, waren Benutzbarkeit, Zuverlässigkeit, Betreibbarkeit, Funktionale Eignung und Wartbarkeit. Wir haben nebenbei ein paar Stichworte auf Post-its notiert um später auch in der Dokumentation festzuhalten, warum wir diesen Bewertungsmaßstab so gewählt haben. Die Spinnennetzgraphik zeigt sie mit den betreffenden Zielwerten.

Um die Standardrisikokarten auszudünnen und auch dabei möglichst viele Menschen zu involvieren, haben wir die 8 Kategorien jeweils einer beteiligten Person zugewiesen und ihr die 4 zugehörigen Risikokarten gegeben. Der “Besitzer” durfte dann vorschlagen, wie viele Karten davon “mitspielen” sollten. In manchen Kategorien sind alle 4 Risikokarten, in anderen nur 2 Risikokarten im finalen Deck gelandet. Das Deck wurde gemischt und zufällig an alle Teilnehmenden verteilt.

Der Rest des Basis-Reviews folgte dem Standard-Vorgehen, unten seht ihr ein Foto aus dem Workshop. Direkt ein Tipp: Wir hatten einen etwas zu kleinen Tisch – das Minimum ist 1x1m, etwas Extraplatz zum Post-It schreiben ist sicher gut.

Für die Einordnung konkreter Risiken (nach Schadenhöhe und Eintritsswahrscheinlichkeit) haben wir Timeboxen von 3-5 Minuten zugelassen und auch Notizen gemacht. Das Ergebnisdiagramm ist im Steckbrief zu sehen - wir haben großen Lücken bei Wartbarkeit und Funktionaler Eignung identifiziert.

Hier haben wir tabellarisch Stärken und Schwächen gesammelt. Diesen haben wir die tangierten Qualitätsmerkmale zugeordnet und auch die Software-Komponenten identifiziert, die es betrifft. Im Anschluss haben wir die Schwächen zudem priorisiert.