The Art of Software Reviews: Probleme und Risiken zielsicher identifizieren

Inhaltsverzeichnis

Getreu dem Bonmot "Besser geht immer" leidet praktisch jede 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 verbessern.

Wer dieses Verbesserungspotenzial seines Systems heben möchte, sollte auf jeden Fall zuerst ein explizites, konkretes und spezifisches Verständnis der vorhandenen Probleme erarbeiten. Dabei lässt sich 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.

Der Artikel stellt die Breitensuche als den zentralen Ansatz methodischer Software-Reviews vor und beleuchtet einige der wesentlichen Untersuchungsansätze.

Fünf Phasen

Schematisch sollten Reviews immer in fünf Phasen stattfinden:

1. Vor Beginn sollten Teams 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 definiert man auch das konkrete Vorgehen: Welche Interviews und Analysen braucht es zu welchem Zeitpunkt und mit welcher Beteiligung?
2. In einem Kick-off erläutern die Verantwortlichen 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 bieten sich nach Bedarf weitere Analyseschritte an, in denen man gezielt auf die Suche nach Problemen und Risiken bestimmter Kategorien geht. 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 arbeitet man die Ergebnisse, Schlussfolgerungen und Empfehlungen auf und stellt diese den Beteiligten vor.

Wer führt Reviews durch?

Vor dem Review sollte überdacht werden, 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"). Abbildung 2 stellt einige Vor- und Nachteile der beiden Varianten gegenüber – mit dem Fazit, für Reviews interne und externe Beteiligte zu mischen – so bekommt man ein "best of both worlds": Sie schließen Befangenheit und Betriebsblindheit aus und kommen zeiteffektiv und inhaltlich fundiert zu konkreten Resultaten.

Erfolgreiche Reviews beginnen mit einer klaren Formulierung von Zielen, die das Review erreichen soll. Solche Ziele sollten Projektverantwortliche mit den Auftraggebern des Reviews gemeinsam erarbeiten. Sie sollten fragen, was jemanden überhaupt zu einem Review motiviert oder welche Probleme es ausgelöst hat. Diese Ziele sollte man schriftlich festhalten – sonst geraten sie allzu schnell in Vergessenheit.

Neben den Zielen müssen die Beteiligten den Betrachtungsgegenstand des Reviews klären. Was genau sollen sie untersuchen? Eine Formulierung wie „das System X“ könnten verschiedene Personen unterschiedlich auslegen, daher legen sie gemeinsam mit den Auftraggebern fest, was genau sie untersuchen sollen. Typische Punkte dabei könnten sein:

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

iX Developer – Moderne Softwarearchitektur

Dieser Artikel stammt aus dem Sonderheft "iX Developer – Moderne Softwarearchitektur". Es bildet auf 148 Seiten einen Querschnitt zu wichtigen Themen zeitgemäßer Softwarearchitektur. Einen Überblick bekommen Interessierte hier. Die gedruckte Ausgabe kosten 14,90 Euro, die PDF-Ausgabe 12,99 Euro.

Die Beteiligten sollten in diesem Vorgespräch dafür sorgen, dass Scope und Ziele zusammenpassen. Ebenso klären sie, welche Personen mitarbeiten. Das gilt auch für die Mitwirkung der Auftraggeber sowie Termine.