The art of software reviews

Dr. Gernot Starke

Jede Software besitzt Potential

Getreu dem Bonmot „Besser-geht-immer“ leidet praktisch alle Software an Problemen kleiner oder großer Natur: Vielleicht läuft sie zu langsam, stürzt manchmal ab oder sieht weniger schön aus als das System der Konkurrenz. Häufig beschwert sich das Business lautstark darüber, dass neue Features viel zu lange dauern – neudeutsch: die Time-to-Market ist zu schlecht. Abgesehen von hello-world lässt sich überall noch so manches besser machen.

Falls Sie dieses Verbesserungspotential Ihres Systems heben möchten, sollten Sie auf jeden Fall zuerst ein explizites, konkretes und spezifisches Verständnis der vorhandenen Probleme erarbeiten. Dabei können wir aus der Medizin lernen: Dort steht vor den Therapievorschlägen zuerst eine gründliche Diagnose („Untersuchung“). Ohne ein solches „Review“, wie die Untersuchung in der IT-Branche heißt, droht Verschlimmbesserung.

Fünf Phasen

Schematisch sollten Reviews immer in fünf Phasen stattfinden:

1. Vor Beginn sollten Sie mit den Auftraggebern oder Systemverantwortlichen die Zielsetzung sowie den Scope klären. Dazu legen Sie gemeinsam fest, welchen zeitlichen Umfang das Review haben sollte. Mit diesen Personen definieren Sie auch das konkrete Vorgehen: Welche Interviews und Analysen zu welchem Zeitpunkt und mit welcher Beteiligung.
2. In einem Kick-off erläutern Sie dieses Vorgehen allen beteiligten Personen. Gleichzeitig können Sie dieses Treffen für erste Gespräche über das System und dessen Stärken und Schwächen nutzen.
3. Nun folgen gezielte Interviews mit Beteiligten aus verschiedenen Bereichen.
4. Nach diesen Gesprächen folgen nach Bedarf weitere Analyseschritte, in denen Sie gezielt auf die Suche nach Problemen und Risiken bestimmter Kategorien gehen. Analysen und die Interviews von Schritt 3 können sich abwechseln: Die Ergebnisse von Interviews können bestimmte Analysen notwendig machen und umgekehrt!
5. Schließlich arbeiten Sie die Ergebnisse, Schlussfolgerungen und Empfehlungen auf und stellen diese den Beteiligten vor.

Wer führt Reviews durch?

Vor dem Review sollten Sie überdenken, welche Personen überhaupt für ein Review in Frage kommen. Grundsätzlich können das die Beteiligten an der Entwicklung sein, alternativ auch Außenstehende („Externe“). In Abbildung 2 stelle ich einige Vor- und Nachteile beider Varianten gegenüber. Mein Fazit: Mischen Sie für Reviews interne und externe Beteiligte – so bekommen Sie „best-of-both-worlds“: Sie schließen Befangenheit und Betriebsblindheit aus und kommen zeiteffektiv und inhaltlich fundiert zu konkreten Resultaten.

Sauber starten

Erfolgreiche Reviews beginnen mit einer klaren Formulierung von Zielen, die das Review erreichen soll. Solche Ziele sollten Sie mit den Auftraggebern des Reviews gemeinsam erarbeiten. Fragen Sie, was jemanden überhaupt zu einem Review motiviert oder welche Probleme das Review ausgelöst haben. Halten Sie diese Ziele schriftlich fest – sonst geraten die allzu schnell in Vergessenheit!

Neben den Zielen müssen Sie den Betrachtungsgegenstand des Reviews klären. Was genau sollen Sie untersuchen? Die Formulierung „Das System X“ könnten verschiedene Personen unterschiedlich auslegen. Daher legen Sie gemeinsam mit Ihren Auftraggebern fest, was genau Sie untersuchen sollen. Typische Dinge dabei könnten sein:

1. Die Architektur, den strukturellen Aufbau des Systems aus Komponenten und deren Schnittstellen.
2. Eingesetzte Technologien sowie technische Konzepte des Systems
3. Die Implementierung, also dessen Quellcode
4. Der Betrieb des Systems in dessen Infrastruktur oder Zielumgebung
5. Die Entwicklung bzw. die Entwicklungsprozesse, beispielsweise Anforderungsklärung, Koordination von Entwicklungsaufgaben, Test und Qualitätssicherung, Konfigurations- und Versionsmanagement, Deployment, Rollout sowie Änderungsmanagement und Bug-Fixing.

Sorgen Sie in diesem Vorgespräch dafür, dass Scope und Ziele zusammen passen. Ebenso klären Sie, welche Personen mitarbeiten, Mitwirkung der Auftraggeber sowie Termine. Lassen Sie am Besten die Auftraggeber des Reviews auch alle Beteiligten, z.B. geplante Interview-Partner*innen informieren.

Wie lange?

Aufwand oder Dauer eines Reviews hängen primär von den Zielen, dem Scope und der Größe des betrachteten Systems ab. Ich habe Reviews zwischen zwei und 60 Personentagen (kurz: PT) durchgeführt. In zwei bis vier PT können Sie einen Überblick gewinnen und eine Art „Bericht zur Lage der Nation“ abgeben, ohne dabei viel Code zu sehen. Für große Systeme inklusive Betrachtung von Quellcode sowie organisatorischen Aspekten steigt der Aufwand für Reviews entsprechend an. Im Rahmen von 10–15PT können Sie schon recht viele Aspekte beleuchten und eine Menge Interviews führen.

Falls sich das nach viel Aufwand anhört: Für Systeme mit 10 Personenjahren Entwicklungsaufwand (also ca. 2300 PT) bedeuten 10 PT ja gerade mal 0.4% des Gesamtaufwandes. Im Vergleich: Inspektionskosten für PKW liegen bei knapp 1% des Kaufpreises pro Jahr.

Kalkulieren Sie von Ihrem Zeitbudget mindestens 20% für die Vorbereitung und Kommunikation Ihrer Ergebnisse. Oftmals kommen nach einer Abschlusspräsentation noch eine Menge an Fragen und Änderungswünschen auf das Review-Team zu.

Kick-off

Laden Sie alle Beteiligten zu einem etwa kurzen Kick-off Workshop ein, auf dem Sie (oder die Auftraggeber) die Ziele und Scope des Reviews sowie die Vorgehensweise kommunizieren, zusammen mit Meilensteinen und dem Zieltermin. Das spart bei den eigentlichen Interviews viel Zeit und beugt einer unproduktiven Gerüchteküche vor. Laden Sie beispielsweise Vertreterinnen und Vertreter der Fach-/Produktseite ein, das Entwicklungsteam, Test/QS, Betrieb sowie ggfs. Nutzerinnen und Nutzer.

Jedes Kick-off verdient eine individuelle Agenda, aber ein paar Themen gehören in jedem Fall dazu:

• Lassen Sie fachlich/organisatorisch verantwortliche Personen den wirtschaftlichen oder fachlichen Zweck des Systems in Kurzform darstellen.
• Technisch versierte Personen (etwa: Architekt*innen, Entwicklungsleitung) sollten die Architektur des Systems, wesentliche Subsysteme, fundamentale technische Entscheidungen aufzeigen.
• Jemand sollte das Entwicklungsvorgehen skizzieren, von Anforderungen über Implementierung/Test, Build, Deployment und Release.

In dieser Runde können Sie eine erste qualitative Analyse des Systems durchführen, also Probleme bezüglich konkreter Qualitätsanforderungen suchen.

Kern der Sache

Zentrale Aufgabe üblicher Reviews ist die Suche nach Problemen, und die finden Sie an ganz unterschiedlichen Stellen – auch jenseits vom reinen Quellcode. Tabelle 1 zeigt einige typische Bereiche, in denen Sie bei Ihrer Suche fündig werden könnten (und unserer Erfahrung nach auch werden!).

Suchen Sie bei Reviews stets in die Breite, d.h. stellen Sie möglichst zu allen der in Tabelle 1 aufgeführten Themen Fragen. Unsere Erfahrung aus Dutzenden von Reviews zeigt, dass gravierende Probleme in Systemen definitiv nicht auf Code und Kopplung beschränkt sind, sondern dass manchmal die wirklich schlimmen Dinge an ganz anderen Stellen lauern. Ständig wechselnde Prioritäten bei Anforderungen sowie der Zwang zur Nutzung überalteter Datenstrukturen oder Datenbanken seien hier als Beispiele aufgeführt.

Fragen stellen

Es gibt ja neben dem Entwicklungsteam noch eine Reihe weiterer Personen oder Organisationen, die Ihnen Auskünfte über das System und seine Eigenschaften respektive Probeme geben können. Diese Personen kennen Stärken und Schwächen aus erster Hand, erleben Probleme und profitieren von Stärken – das sind für einen Review wertvolle Informationen.

Da Sie das Review als Breitensuche durchführen, sollte auch die Auswahl Ihrer Interviewpartner*innen in die Breite gehen. Sprechen Sie beispielsweise mit:

• Nutzer*innen
• Fachlich Verantwortliche (etwa: Vertreter der Fachbereiche)
• Technisch Verantwortliche (etwa: Architekt*innen)
• Auftraggeber*innen, Management
• Beteiligte aus dem Entwicklungsteam: Bei größeren Systemen mit mehreren großen Subsystemen oder Komponenten eine Mischung aus mehreren Teams
• Test/QS, falls nicht Teil des Entwicklungsteams
• Personen aus Infrastruktur und/oder Betrieb
• Projekt- und Produkt-Manager*innen
• In agilen Organisationen: Product-Owner, Scrum-Master oder Agile-Coach

Stellen Sie in Interviews offene Fragen, die ganze Sätze als Antworten erfordern, vermeiden Sie Ja/Nein Fragen. Fragen Sie nach Problemen, Schwierigkeiten und besonders aufwändigen oder langwierigen Aktivitäten im Zusammenhang mit dem System. Fragen Sie aber außerdem nach Dingen oder Aspekten, die Personen unbedingt beibehalten möchten.

Schließlich empfehlen wir Ihnen, auch nach denkbaren Abhilfen der genannten Probleme zu fragen, um die Kreativität Ihrer Interviewpartner*innen herauszufordern:

• Was würden Sie tun, wenn Sie eine Woche lang die gesamte Entwicklung beliebig steuern dürften?
• Was wären Ihre Top-3 Änderungen am System, dem Entwicklungsprozess oder der Organisation, wenn Sie das bestimmen dürften?

Ich wollte zum Abschluss von Interviews immer gerne wissen, was „ich noch hätte fragen sollen“. Das gibt den interviewten Personen die Gelegenheit, noch ganz andere Themen anzusprechen.

Führen Sie Interviews am besten zu zweit. Als Duo nehmen Sie mehr mit. Wechseln Sie fragen und mitschreiben ab, dann kann sich die fragende Person besser auf Gestik, Mimik und Verhalten der anderen konzentrieren und ist nicht ständig durch mitschreiben abgelenkt. Markieren Sie Bemerkungen, die weitere Analysen oder Nachprüfungen erfordern. Lassen Sie sich bei Bedarf weitere Ansprechpersonen nennen, die mehr Informationen zu bestimmten Themen haben. Begrenzen Sie Interviews auf 60–90 Minuten und vereinbaren Sie bei Bedarf lieber Folgetermine. Zwischen zwei solcher Interviews sollten Sie für sich selbst 15 Minuten Pause einplanen, damit Sie ganz kurz reflektieren können, Ihre Notizen kennzeichnen und sich für das nachfolgende Interview mental sammeln können.

Externe Schnittstellen

Analysieren Sie im Rahmen Ihres Reviews die Außenwelt des Systems, also dessen externe Schnittstellen. Stellen Sie dazu erstmal sicher, dass Sie überhaupt sämtliche Außenschnittstellen kennen – gerade in Business-Informationsssytemen können das oft mehrere Dutzende sein. Fragen Sie nach dem Kontextdiagramm) – und falls es keines gibt, haben Sie schon einen hilfreichen Verbesserungsvorschlag.

Welche dieser externen Schnittstellen verursachen im laufenden Betrieb Probleme? Hier müssen Sie möglicherweise die Verantwortlichen der Nachbarsysteme befragen – weil unser System ja eventuell bei Anderen Probleme verursacht. Hinterfragen Sie eventuelle Service-Level Agreements dieser Schnittstellen bezüglich Verletzungen. Sie können versuchen, externen Schnittstellen im laufenden Betrieb „auf die Finger“ zu schauen, indem Sie Logfiles oder Monitoring nach Auffälligkeiten untersuchen. Prüfen Sie die Implementierung externer Schnittstellen durch gezielte Codereviews.

Besonderes Augenmerk widmen Sie solchen externen Schnittstellen, deren Nutzung direkte Kosten verursacht (etwa: Aufrufe kostenpflichtiger Dienste), oder deren Definition oder Spezifikation sich häufig ändert.

Qualität im Griff?

Sie sollten untersuchen, inwieweit das System seine Qualitätsanforderungen erfüllt oder welche Qualitätseigenschaften nicht angemessen erreicht werden. Offensichtlich müssen Sie dazu erstmal die Qualitätsanforderungen genau kennen: In vielen Jahren Review-Praxis habe ich nur wenige Systeme erlebt, bei denen es eine halbwegs aktuelle Übersicht davon gab. Meist mussten wir die spezifischen Qualitätsanforderungen ihm Rahmen des Reviews erst aufarbeiten. Zum Glück gibt es dafür im Software- und Requirements-Engineering etablierte Methoden, beispielsweise ATAM und req4arc), die wir in Reviews in vereinfachter Form anwenden können. Zur Beschreibung von Qualitätsanforderungen verwenden wir so genannte Szenarien (siehe Abbildung 3). Sie beschreiben in Umgangssprache, wie das System sich bei bestimmten Ereignissen verhalten soll. Falls Ihnen das zu abstrakt klingt – in Tabelle 2 finden Sie einige Beispiele.

Mit solchen konkreten Qualitätsanforderungen gestaltet sich die Analyse relativ einfach: Gemeinsam mit Architekten oder dem Entwicklungsteam untersuchen Sie, ob das System oder dessen Architektur die definierten Szenarien (= Qualitätsanforderungen) erfüllen kann. Lassen Sie sich dazu die zugehörigen Architekturentscheidungen und -ansätze erläutern. Spielen Sie gemeinsam mit Beteiligten aus dem Entwicklungsteam diese Szenarien in Form von Walkthroughs durch, möglichst detailliert und feingranular. Finden Sie heraus, wie die Bausteine des Systems zur Erreichung dieses Szenarios zusammenspielen und welche Entwurfsentscheidungen das jeweilige Szenario unterstützen. Dabei können Sie sich einen Eindruck verschaffen, wie sicher die jeweiligen Qualitätsanforderungen erreicht werden können.

Meiner Erfahrung nach bekommen Sie bereits in den Interviews viele Hinweise, welche Qualitätseigenschaften im System die meisten Probleme bereiten – so dass Ihre detaillierte Analyse dann im Grunde die Bestätigung (oder Widerlegung) der bereits geäußerten Defizite darstellt.

Architektur prüfen

Bevor wir auf Details zu diesem wichtigen Aspekt von Reviews eingehen, lassen Sie uns kurz zusammenfassen, was wir unter dem Begriff „Softwarearchitektur“ verstehen, und was wir demzufolge unter der Rubrik Architektur untersuchen möchten. Unter Architektur fassen wir die folgenden Aspekte:

• Interne Struktur des Systems: Die Modularisierung, den Schnitt des Systems, die Zerlegung in Subsysteme oder Komponenten. Idealerweise entspricht dieser Schnitt der fachlichen Struktur, neudeutsch der Domänenstruktur. Hierzu zählt auch das große Thema der internen Schnittstellen.
• Querschnittliche Konzepte: Vorgaben zu Themen, die übergreifenden Charakter besitzen und sicherstellen, dass die Implementierung des Systems passenden Regeln folgt. Beispiele sind Aufbau und Gestaltung von Benutzungsschnittstellen (UI), Mechanismen zur Persistenz, Monitoring/Logging, Integration von Fremdsystemen. Details siehe arc42-konzepte

Über die Prüfung der internen Struktur gibt’s ganze Bücher [1] – kurz gefasst müssen Sie dazu intensiv in den Code gucken (oder für ganz Mutige: Der hoffentlich vorhandenen Dokumentation glauben – wovon ich dringend abrate!). Vermutlich ist der Code Ihres Systems jedoch so umfangreich, dass Sie für das Review lieber ein Analyse-Werkzeug (wie Sonargraph, Structure-101, Resharper, Sotograph, Lattix), einsetzen, dass aus dem Code eine Übersicht von Komponenten und deren Abhängigkeiten erzeugen kann.

Abbildungen 4 und 5 zeigen zwei Beispiele solcher Analysen. Ihnen bleibt die anspruchsvolle Aufgabe, diese grafischen Darstellungen zu interpretieren: Ist diese Komponentenstruktur respektive diese Abhängigkeiten angemessen für das System? Wo besteht zu enge Kopplung, und stellt die wirklich ein Problem dar?

Code-Reviews

Mit der Analyse der Softwarearchitektur rein auf Grundlage des vorhandenen Quellcodes ist es leider nicht getan. Es ist ein Irrglaube, dass alle Informationen im Code stehen. Das klingt zunächst kontra-intuitiv. Was sollte wichtiger sein als Quellcode? Nachfolgend finden Sie ein paar (mögliche) Gründe, warum andere Dinge noch wichtiger sein könnten:

• Möglicherweise haben Sie eine hervorragend strukturierte, nach allen Regeln der Kunst durchgeführte Implementierung einer äußerst schlechten Idee vor sich, z. B. weil es für den gleichen Einsatzzweck bessere, fertige Komponenten gibt.
• Vielleicht würde der ein oder andere problematische oder vielleicht sogar besonders elegante Teil der Software gar nicht benötigt, wenn man eine technische Anforderung hinterfragen würde.
• Manchmal befindet sich ein großer Teil der wichtigen Information nicht in „klassischem“ Quellcode, sondern in Konfigurationsdateien oder „Glue-Code“, der auf den ersten Blick gar nicht ins Auge fällt.
• Vielleicht ist die Laufzeitarchitektur des Systems äußerst elegant, führt aber zu enormen Herausforderungen im Entwicklungsprozess – oder andersherum.
• Unter Umständen spielt die Aufteilung in verschiedene Teilkomponenten in einem verteilten System eine sehr viel größere Rolle als die Implementierung der einzelnen Systeme.
• Vielleicht entstehen Probleme durch eine suboptimale Aufteilung zwischen Hardware- und Softwarekomponenten (besonders bei Embedded-Systemen) oder durch eine verbesserungswürdige Verwendung von Standardsoftware.

Die genannten Fälle unterscheiden sich sehr, und ist ein spannender Aspekt von Reviews: Sie müssen sich in das System hineindenken und es aus unterschiedlichen Perspektiven hinterfragen. Es gibt leider kein Standardrezept und auch die mächtigen Analysewerkzeuge können nur einen Teil der möglichen Probleme aufdecken.

Dennoch: Sie sollten Code analysieren – weil Sie damit natürlich eine Reihe gravierender Probleme finden können: Schwer verständliche Teile, verursacht durch übermäßige Größe oder komplizierte Implementierung, Abweichungen von Code-Konventionen oder schlicht handwerklich schlecht implementierte Teile. Sie finden Code, der verschwenderisch mit CPU oder Speicher umgeht, Stellen ohne automatisierte Tests, oder Stellen, die von den vereinbarten Architekturkonzepten abweichen.

Viele solcher Probleme können Sie mit statischer Codeanalyse herausfinden. SonarQube, TeamScale, ReSharper oder Checkstyle seien hier als Beispiele für Tools genannt. Achten Sie bei solchen statischen Analysen besonders auf negative Ausreißer bei Code-Komplexität (etwa: zyklomatische Komplexität) oder Kopplung. Ganz wesentlich bleibt bei Code-Reviews allerdings Ihre menschliche Expertise und Einschätzung!

Hotspot-Analyse

Eine besonders hilfreiche Art der Code-Analyse sollten Sie auf jeden Fall durchführen – die Hotspot-Analyse: Ein Hotspot ist ein Baustein, der häufig geändert wird, und gleichzeitig eine hohe innere Komplexität besitzt (siehe [2]). Die Änderungshäufigkeit können Sie aus Ihrer Versionsverwaltung, git, subversion und Co. abfragen, die Komplexität von Code relativ einfach über statische Analysen Messen. Adam Tornhill hat in [2] entsprechende Analysewerkzeuge als Open-Source veröffentlicht. Ein Beispiel solcher Hotspot-Analysen finden Sie in Abbildung 6.

Durch Hotspot-Analysen finden Sie hochgradig riskante Teile Ihres Systems: Komplexe Stellen besitzen ein sehr hohes Fehler- und Änderungsrisiko, und sind tendenziell auch viel aufwändiger in der Wartung. Das kombiniert mit hoher Änderungsfrequenz ist fast schon eine Garantie, dass bei diesen Bausteinen gravierende Probleme auftreten werden!

Anwendungsdaten

Die zuverlässige Speicherung und Bereitstellung von Daten gehört für die meisten Anwendungen zu den Kernaufgaben. Die Daten einer Anwendung leben oft länger als der Quellcode. Quellcode lässt sich vergleichsweise einfach erweitern, refaktorieren oder auf eine neue Frameworkversion anpassen, Bugfixes lassen sich meist relativ einfach deployen. Fehlerhafte oder verlorene Daten lassen sich dagegen nur schwer und aufwendig reparieren. Änderungen an den Strukturen eines produktiven Datenbestands sind oftmals zeitintensiv und erfordern sorgfältige Planung. Fehler in der Datenmodellierung werden Sie entsprechend länger verfolgen. Auch der Wechsel einer Datenbank ist teuer und zeitintensiv. Ein Wechsel von MySQL zu PostgreSQL ist aufwendig, weil alle datenbankspezifischen Funktionen gefunden und ersetzt werden müssen. Ein Wechsel von MongoDB auf MySQL noch aufwendiger, weil es einen kompletten Wechsel des Datenmodells und des Schemamanagements erfordert. Im Rahmen Ihres Reviews ist es Ihre Aufgabe herauszufinden, ob die Auswahl der datenspeichernden Systeme, die Modellierung der Daten und Ihre Übermittlung, Transformation und Qualität den Erfordernissen der jeweiligen Anwendung entspricht.

Verschaffen Sie sich zuerst einen Überblick über alle datenspeichernden Komponenten sowie der dazu eingesetzten Software. Passen die verwendeten Datenmodelle und -strukturen noch zur aktuellen Domäne? Oder werden die aktuellen Business-Daten in irgendwelche historische Strukturen „gequetscht“? Werden Daten redundant gehalten oder häufig synchronisiert? Gibt es Integrationsdatenbanken – die heute eher als Anti-Pattern gelten? Suchen Sie nach Problemen mit Antwortzeiten bei Abfragen: Laufen manche Anfragen extrem lange oder extrem häufig?

Garbage-in…

Wenden Sie nun Ihren Blick vom Code respektive der Technik hin zu den Entwicklungsprozessen, und dabei konkret auf die Anforderungen: Gibt es für Ihr System ein vernünftiges, angemessenes „Requirements Engineering“ – oder purzeln Change-Requests rein zufällig auf das Entwicklungsteam? Gibt es einen ordentlich gepflegten Backlog, der den Namen auch verdient?

Auf Basis mangelhafter Anforderungen mit ständig wechselnden Prioritäten können auch hervorragende Entwicklungsteams keine gute Software produzieren – eben garbage in, garbage out. Typische Schwierigkeiten mit Anforderungsprozessen sind etwa folgende:

• Sie wissen nicht was sie wollen: Anforderungen bleiben vage, unpräzise, grob. Das Resultat: Entwicklungsteams implementieren stark konfigurierbare Systeme und verschieben damit die Entscheidungen über die konkrete Bedeutung von Anforderungen auf die Laufzeit.
• Sie wollen dauernd etwas anderes: Hohe Volatilität in Anforderungen, sodass Entwicklungsteams häufig umbauen müssen.
• Verschiedene Stakeholder*innen fordern widersprüchliche Dinge: Das können verschiedene Anforderungen an Daten, Validierungs- oder Geschäftsregeln bis hin zu unterschiedlichen Algorithmen sein.
• Anforderungen benötigen innerhalb der gesamten Organisation zu lange bis sie beim Entwicklungsteam landen. Es gibt zu viele beteiligte Personen, zu viele Gremien oder zu viele Abstimmungsprozesse.

Layer-8 Probleme

Sicherlich haben Sie auch schon mal Abstimmungs- oder Kommunkationsprobleme in Teams durchlitten – und solche können gravierende Auswirkungen auf die betroffenen Systeme haben. Im Rahmen Ihrer Reviews sollten Sie auch die betroffenen Arbeitsprozesse und (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? Suchen Sie innerhalb von Entwicklungsprozessen nach Aufgaben, an denen ungebührlich viele Personen beteiligt sind, die ungebührlich lange dauern oder mit denen Stakeholder sonstige Probleme berichten. Wir alle arbeiten unter Zeit- und/oder Budgetdruck – das allein lassen wir erstmal nicht als „Ursache aller Probleme“ gelten. Allerdings können Organisationen bzw. Entwicklungsteams diesen Druck leicht übertreiben.

Schauen Sie auf Entwurfs- und Testprozesse, betrachten Sie Build/Release und Deployment aber auch organisatorische und betriebliche Themen. Sind Agilität und DevOps wirklich umgesetzt oder bleibt es beim Lippenbekenntnis? Gibt es automatisierte Tests, und finden diese Test überhaupt relevante Fehler?

Weitere Analysen

Bis hierhin haben wir schon in vielen Ecken des Systems nach Problemen gesucht – aber Probleme sind ungeheuer erfinderisch und verstecken sich auch an anderen Stellen: Bisher haben wir zum Beispiel die technische Infrastruktur respektive Hardware ausgeklammert, das Monitoring/Logging oder auch das leidige Thema Dokumentation. Zu Beginn des Artikels haben wir Ihnen die Breitensuche vorgeschlagen – nun müssen Sie für sich entscheiden, ob Sie bereits in ausreichender Breite gesucht haben, oder ob es für Ihr konkretes System noch weitere Analysen geben sollte. Schauen Sie im Buch „Software Reviews“ nach, dort finden Sie noch ein paar Vorschläge.

Resultate kommunizieren

Am Ende eines Reviews steht normalerweise ein Abschlussbericht, den Sie in einer Präsentation den beteiligten Personen vorstellen. Das möglicherweise das wichtigste Resultat des gesamten Reviews ist dabei eine kompakte Zusammenfassung („Management Summary“). Stellen Sie darin maximal drei Handlungsempfehlungen mitsamt Herleitungen dar. Schreiben Sie diese Zusammenfassung erst zum Schluss, wenn Ihre Resultate feststehen.

Beginnen Sie eine Präsentation mit dieser Zusammenfassung. Erklären Sie, wie Sie an Ihre Ergebnisse gekommen sind, bringen Sie Beweise bei! Teilen Sie die gefundenen Probleme in drei Kategorien ein: Schlimm (hohe Mehrkosten oder starke Verzögerungen), mittel (Kosten oder Verzögerungen) und störend. Entsprechend dieser Prioritäten schlagen Sie Verbesserungs- oder Abhilfemaßnahmen vor.

Denken Sie daran, auch das Gute ausdrücklich zu benennen, das Sie vorgefunden haben: Gute Entscheidungen, gute Strukturen, gute Prozesse – darüber freuen sich Auftraggeber und das Entwicklungsteam.

Gemäß dem nachfolgenden Vorschlag können Sie Ihre Abschlusspräsentation oder Ihren Abschlussbericht von Reviews aufbauen.

1. Ein kurzes, sehr prägnantes Management-Summary (Hinweise dazu finden Sie im Text)
2. Zusammenfassung organisatorischer Aspekte des Reviews:
   • Was genau waren die Ziele und Scope des Reviews?
   • Welche Beschränkungen gibt es?
   • Wie sind Sie vorgegangen? Wieviel Zeit haben Sie (circa) worin investiert?
   • Mit wem haben Sie worüber gesprochen, inklusive Daten und Dauer?
   • Welche Review-Aktivitäten haben Sie neben Gesprächen und Interviews durchgeführt.
3. Welche Aspekte am System und dessen Entwicklung fanden Sie positiv (keep, don’t change)?
4. Eine Zusammenfassung der Probleme und Risiken, Top-down beschrieben:
   • In welchen Kategorien haben Sie Probleme und Risiken gefunden?
   • Welche Probleme haben Sie gefunden, 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 schlagen Sie Maßnahmen vor?
   • Welche unterschiedlichen Optionen gibt es?

Fazit

Mit Reviews können Sie Probleme in Ihrem System und dessen Umfeld systematisch und zuverlässig identifizieren. Das benötigt zwar etwas Zeit, birgt aber sehr hohes Nutzenpotential. Die gute Nachricht: Die meisten Analysen können Sie ohne den Einsatz teurer oder komplizierter Werkzeuge durchführen – mit Hirn, Erfahrung und Motivation. Hauptsache, Sie suchen in die Breite. In diesem Sinne – möge die Macht methodischer Reviews mit Ihnen sein.

Teile dieses Artikels basieren auf dem Buch „Software-Reviews“, das Gernot gemeinsam mit Markus Harrer, Christine Koppelt und Ben Wolf geschrieben hat.

Literatur