Seite 5: Layer-8-Probleme

Inhaltsverzeichnis

Sicherlich hat jedes Team schon mal Abstimmungs- oder Kommunikationsprobleme durchlitten – und solche können gravierende Auswirkungen auf die betroffenen Systeme haben. Im Rahmen der Reviews sollte man auch die betroffenen Arbeitsprozesse und die (Team-)Kommunikation untersuchen: Wo gibt es Know-how-Flaschenhälse? Ist die Entscheidungskompetenz angemessen verteilt? Gibt es ausreichend Feedback zwischen den Beteiligten? Gibt es genügend Freiraum und genügend Festlegungen? Reviewer sollten innerhalb von Entwicklungsprozessen nach Aufgaben suchen, an denen ungebührlich viele Personen beteiligt sind, die unangemessen lange dauern oder mit denen Stakeholder sonstige Probleme berichten.

Alle arbeiten unter Zeit- und/oder Budgetdruck – das allein kann erst mal nicht als "Ursache aller Probleme" gelten. Allerdings können Organisationen beziehungsweise Entwicklungsteams diesen Druck leicht übertreiben. Deswegen ist der Blick auf Entwurfs- und Testprozesse, Build/Release und Deployment, aber auch organisatorische und betriebliche Themen wichtig. Sind Agilität und DevOps wirklich umgesetzt, oder bleibt es beim Lippenbekenntnis? Gibt es automatisierte Tests, und finden diese überhaupt relevante Fehler?

Bis hierhin wurde schon in vielen Ecken des Systems nach Problemen gesucht – aber Probleme sind ungeheuer erfinderisch und verstecken sich auch an anderen Stellen: Bisher hat der Artikel zum Beispiel die technische Infrastruktur respektive Hardware ausgeklammert, das Monitoring/Logging oder auch das leidige Thema Dokumentation. Zu Beginn hatte der Autor die Breitensuche ins Spiel gebracht – nun ist zu entscheiden, ob man bereits in ausreichender Breite gesucht hat oder ob es für das konkrete System noch weitere Analysen geben sollte. Im Buch des Autors und einigen seiner Kollegen finden sich noch ein paar Vorschläge.

Resultate kommunizieren

Am Ende eines Reviews steht normalerweise ein Abschlussbericht, der in einer Präsentation den beteiligten Personen vorgestellt wird. Das möglicherweise wichtigste Resultat des gesamten Reviews ist dabei eine kompakte Zusammenfassung ("Management Summary"). Sie sollte maximal drei Handlungsempfehlungen mitsamt Herleitungen darlegen und erst zum Schluss verfasst werden, wenn die Resultate feststehen.

Neben der Zusammenfassung sollte die Präsentation Erklärungen enthalten, wie die Ergebnisse zustande gekommen sind und wie sie sich belegen lassen. Es empfiehlt sich, die gefundenen Probleme in drei Kategorien einzuteilen: schlimm (hohe Mehrkosten oder starke Verzögerungen), mittel (Kosten oder Verzögerungen) und störend. Entsprechend dieser Prioritäten sollte man Verbesserungs- oder Abhilfemaßnahmen vorschlagen. Vergessen sollten Reviewer auch nicht, das Gute ausdrücklich zu benennen, das sie vorgefunden haben: gute Entscheidungen, gute Strukturen, gute Prozesse – darüber freuen sich Auftraggeber und das Entwicklungsteam.

Rezept für die Abschlusspräsentation

Gemäß dem nachfolgenden Vorschlag können Reviewer ihre Abschlusspräsentation oder ihren Abschlussbericht aufbauen.

1. Eine kurze, sehr prägnante Management-Summary (Hinweise dazu im Text).
2. Zusammenfassung organisatorischer Aspekte des Reviews:
• Was genau waren die Ziele und Scope des Reviews?
• Welche Beschränkungen gibt es?
• Wie wurde vorgegangen? Wie viel Zeit wurde (circa) worin investiert?
• Mit wem hat wer worüber gesprochen, inklusive Daten und Dauer?
• Welche Aktivitäten waren neben Gesprächen und Interviews Bestandteil des Reviews?
3. Welche Aspekte am System und dessen Entwicklung waren positiv zu bewerten (keep, don't change)?
4. Eine Zusammenfassung der Probleme und Risiken, Top-down beschreiben
• In welchen Kategorien waren Probleme und Risiken zu finden?
• Welche Probleme gab es, beginnend mit den höchsten Prioritäten (also die schlimmsten, gravierendsten Probleme zuerst)?
• Wo drohen Risiken?
• Welche Auswirkungen sind zu erwarten oder sind bereits akut?
5. Zusammenfassung der vorgeschlagenen Maßnahmen (optional)
• In welchen strategischen, technischen oder organisatorischen Bereichen sind Maßnahmen zu empfehlen?
• Welche unterschiedlichen Optionen gibt es?

Fazit

Mit Reviews lassen sich Probleme im System und dessen Umfeld systematisch und zuverlässig identifizieren. Das benötigt zwar etwas Zeit, birgt aber sehr hohes Nutzenpotenzial. Die gute Nachricht: Die meisten Analysen lassen sich ohne den Einsatz teurer oder komplizierter Werkzeuge durchführen – mit Hirn, Erfahrung und Motivation. Hauptsache, man sucht in der Breite.

Gernot Starke

ist INNOQ Fellow. Er verbessert und entwickelt Softwarearchitekturen. Außerdem ist er Mitgründer und Betreiber der "Architecture Improvement Method" aim42, des Architekturportals arc42, sowie aktives Mitglied im iSAQB e.V. Teile dieses Artikels basieren auf dem Buch "Software-Reviews", das Starke zusammen mit Markus Harrer, Christine Koppelt und Benjamin Wolf verfasst hat.

Literatur

1. Carola Lilienthal; Langlebige Softwarearchitekturen; dpunkt.verlag 2020 (3. Aufl.)
2. Adam Tornhill; Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs; Pragmatic Bookshelf 2015

(ane)