Ein Review in der Softwareentwicklung ist das strukturierte Lesen eines Dokuments oder Artefakts mit dem Ziel, Fehler aufzudecken, bevor sie in die nächste Entwicklungsphase rutschen. Gutachter arbeiten dabei mit Lesetechniken wie Checklisten oder perspektivenbasiertem Lesen. Je früher ein Fehler gefunden wird, desto günstiger ist seine Beseitigung.
Das Wichtigste in Kürze
- Fehler, die erst beim Kunden auftauchen, kosten ein Vielfaches dessen, was eine frühe Aufdeckung im Review gekostet hätte, weil sich die Behebungskosten von Phase zu Phase verzehnfachen.
- Vorgesetzte gehören nicht in Review-Sitzungen, weil ihre Anwesenheit das Verhalten aller Beteiligten verändert und die Ergebnisse zur Leistungsbewertung missbraucht werden könnten.
- Die Qualitätsverantwortung für ein Dokument bleibt beim Autor, auch wenn Reviewer Befunde liefern: Reviewer benennen das Problem, der Autor entscheidet die Lösung.
- Perspektivenbasiertes Lesen steigert die Treffsicherheit eines Reviews, weil jeder Gutachter gezielt die Anforderungen einer bestimmten Zielgruppe, etwa Entwicklung, Test oder Marketing, prüft.
- Zwei Tage Moderatorenausbildung plus begleitete Praxissitzungen reichen aus, damit ein Review-Moderator eigenständig arbeitet.
Was ein Review wirklich ist
Ein Review ist das gezielte Lesen eines Prüfgegenstands, um darin Fehler aufzudecken. Der Gegenstand ist meist ein Dokument, kann aber auch ein Modell, eine Zeichnung oder ein anderes Artefakt sein. Entscheidend ist die Absicht: nicht überfliegen, sondern Befunde sichern.
Das unterscheidet ein Review vom kurzen Drüberschauen an der Kaffeemaschine. Wer ein Dokument informell prüft, liefert an einem guten Tag viele Befunde, am nächsten kaum noch welche, weil Zeit, Konzentration oder Lust fehlen. Ein Review macht das Ergebnis unabhängiger von der Tagesform.
Im Vordergrund stehen schwergewichtige Befunde. Gemeint sind Probleme mit echten Konsequenzen: Fehler, die wehtun, wenn sie unbemerkt in eine spätere Phase der Softwareentwicklung durchrutschen. Kommafehler und holprige Formulierungen sind nachrangig.
Wie ein strukturiertes Review abläuft
Ein Review beginnt mit einer Person, die es moderiert. Sie schaut sich das Dokument vorab an, spricht kurz mit dem Autor und klärt drei Dinge: Was ist das für ein Dokument, wer nutzt es später, und welche Fehler will diese Zielgruppe auf keinen Fall darin sehen.
Danach stellt der Moderator ein kleines Team zusammen, oft zwei bis drei Gutachter, bei wichtigen Dokumenten auch mehr. Jeder Gutachter zieht sich mit dem Dokument und seinen Hilfsmitteln zurück und liest aufmerksam, gestützt auf eine Lesetechnik. Jeder Befund landet in einer Liste.
Die Befundlisten werden zusammengeführt, Duplikate herausgefiltert, die schwerwiegenden Punkte markiert. Über diese Punkte spricht das Team in einer Sitzung. Der Dialog hat einen eigenen Wert: Der Gutachter erklärt, was er meinte, der Autor fragt nach, beide lernen.
Den Ton der Sitzung gibt der Moderator vor, nicht der Autor. Er führt durch das Prüfobjekt oder durch die Befundliste und sorgt dafür, dass die Diskussion sachlich und fokussiert bleibt.
Die Verantwortung für die Qualität bleibt beim Autor
Gutachter helfen, sie übernehmen aber nichts. Sie legen das Problem dar, sie schlagen keine Lösung vor. Wie mit jedem Befund umgegangen wird, entscheidet der Autor nach der Sitzung selbst.
Diese klare Aufteilung schützt vor einem Missverständnis: Ein Review nimmt dem Autor nicht die Arbeit ab und entlastet ihn nicht von der Verantwortung. Es macht sein Ergebnis besser, ohne dass es aufhört, sein Ergebnis zu sein.
Genau darin liegt der Punkt, an dem viele Autoren ihre anfängliche Skepsis verlieren. Das Dokument bleibt ihres, nur ist es nach dem Review schlicht besser. Andere haben geholfen, dass es besser wird.
Wie Lesetechniken das Fehlerfinden steuern
Lesen für Fehler ist eine eigene Disziplin. In der Schule lernen alle zu lesen, zu interpretieren, Inhalte zu verstehen. Gezielt Fehler aufzudecken lernt kaum jemand. Lesetechniken füllen diese Lücke.
Die einfachste Technik ist die Checkliste. Sie stellt Fragen, und wer die Fragen beantwortet, stößt auf Schwachstellen im Dokument. Stärker ist das perspektivenbasierte Lesen: Der Gutachter nimmt nacheinander die Rollen der späteren Nutzer ein.
Bei einem Anforderungsdokument sind das etwa Entwicklung, Test, Projektleitung und Marketing. Jede Rolle prüft anderes:
- Entwickler: Ist es umsetzbar und eindeutig beschrieben?
- Tester: Ist es prüfbar, lässt sich ein Testfall ableiten?
- Marketing: Gibt es einen Markt dafür, lässt es sich verkaufen?
Erfüllt das Dokument die Ansprüche aller Zielgruppen, ist es gut genug. Die Perspektiven zwingen den Gutachter, Rollen einzunehmen, die er von sich aus nicht hätte.
Welche Review-Arten es gibt und wann sie passen
Reviews unterscheiden sich vor allem im Formalitätsgrad. Vom informellen Drüberlesen bis zur durchstrukturierten Inspektion gibt es mehrere Stufen, und welche passt, entscheidet jedes Projekt für sich.
| Review-Art | Vorbereitung | Wer prüft | Typischer Einsatz |
|---|---|---|---|
| Informelles Review | keine feste | beliebig | schnelle Gegenprüfung |
| Walkthrough | gering | Autor führt durch | Erklären, Fragen, erste Befunde |
| Inspektion | im stillen Kämmerlein, mit Lesetechnik | mehrere Gutachter | systematisch, nachhaltig, mit Befundlisten |
| Technisches Review | je nach Tragweite | Experten, Chefarchitekt | Dokumente mit großer Tragweite, Architekturentscheidungen |
Beim Walkthrough leitet meist der Autor durch das Dokument, erklärt seine Gedanken und fordert zu Alternativen und Fragen auf. Befunde landen oft direkt als Kommentar im Dokument.
Die Inspektion ist die systematische Form. Jeder Gutachter bereitet sich allein vor, schließt seine Befundliste ab, danach werden die Listen zusammengeführt und die schwerwiegenden Punkte in einer Sitzung besprochen.
Das technische Review zielt auf Dokumente mit Tragweite für das Unternehmen, etwa ein Konzept für Mehrsprachigkeit, Mandantenfähigkeit oder eine plattformübergreifende Architektur. Hier sitzen nicht die Kollegen des Autors, sondern die Fachexperten, weil hier Entscheidungen fallen, oft zwischen mehreren vorgestellten Alternativen.
Warum sich Reviews wirtschaftlich rechnen
Der stärkste Hebel ist der Zeitpunkt der Fehlerbehebung. Ein Fehler, der kurz nach dem Einbau gefunden und behoben wird, kostet einen Bruchteil dessen, was er später kostet. Barry Boehm hat formuliert, dass sich die Kosten eines Fehlers von Phase zu Phase grob verzehnfachen.
Ein Beispiel macht das greifbar: Ein Widerspruch zwischen zwei User Stories, der nicht gefunden wird, wandert ins Design, in die Implementierung, durch den Test. Findet ihn am Ende der Kunde, ist er um ein Vielfaches teurer geworden.
Der zweite Hebel ist Lernen. Die besten Reviews sind die, nach denen Autoren bestimmte Befunde gar nicht mehr produzieren. Sie lernen aus ihren Fehlern, und manchmal entsteht daraus eine Vorlage oder ein Hilfsmittel, das den Fehler künftig verhindert.
Auch Gutachter profitieren. Sie setzen sich intensiv mit einem Dokument auseinander und eignen sich dabei Wissen an, das sie für ihre eigene Arbeit ohnehin gebraucht hätten. Sie tun es nur früher.
Die häufigsten Gründe, warum Reviews scheitern
Zu wenig Zeit für den einzelnen Gutachter ist der erste Killer. Wer den Auftrag bekommt, ein Dokument bis morgen nebenbei und am besten außerhalb der Arbeitszeit zu lesen, weil das Projekt vorgeht, liefert kein verlässliches Ergebnis. Reviewzeit ist Arbeitszeit.
Der zweite Killer ist die Anwesenheit von Vorgesetzten in Inspektion oder Walkthrough. Sitzt ein Vorgesetzter im Raum, verhalten sich Autor und Gutachter anders. Es entsteht der Anreiz, gut dazustehen oder andere schlecht aussehen zu lassen. Und die Ergebnisse dürfen nur zur Korrektur des Dokuments dienen, niemals zur Leistungsbewertung. Beides spricht dafür, Vorgesetzte aus diesem Prozess herauszuhalten.
Der dritte Killer ist ein fehlender oder schwacher Moderator. In einer Review-Sitzung bleibt pro Befund maximal eine bis drei Minuten. Eine Minute ist schnell vorbei. Ein guter Moderator fokussiert, verhindert ausufernde Diskussionen und sorgt dafür, dass die richtigen Leute über einen Befund sprechen. Häufig sitzen genau die nicht im Raum, die einen Befund lösen müssten.
Womit du beim ersten Review anfängst
Ein gutes erstes Übungsobjekt ist ein Kinderbuch. Es ist kurz, jeder fühlt sich als Experte, und der zu kritisierende Autor ist nicht im Raum. Trotzdem wird die Befundliste lang, obwohl das Buch längst gedruckt ist. Das zeigt, wie viel auftaucht, wenn man wirklich gründlich auf Fehler liest.
Für das erste echte Review eignet sich ein frühes Dokument am besten, aus dem Bereich Anforderungen oder Design. Dort hat ein Befund noch Tragweite, dort lässt sich noch etwas beheben. Wähle bewusst kein Dokument, das schon vollständig umgesetzt ist, sondern eines mitten im Projekt, damit das Projekt direkt profitiert.
Die besten Reviews sind eigentlich die, wo die Autoren die Befunde, die sie da eingebaut haben, nicht mehr machen in Zukunft. Sie lernen aus dem, was sie falsch machen, und es wird an sich besser. — Maud Schlich
Ein Lerntrick aus der Zeit großer Pflichtenhefte: absichtlich eingebaute Fehler. Autor und Moderator schleusen Fehler ein und schauen, was gefunden wird und was nicht. Autoren sind regelmäßig überrascht, wie viele andere Befunde auftauchen, an die sie nicht gedacht hatten. Gutachter sind überrascht, wie viel sie übersehen, obwohl es im Text steht.
Künstliche Intelligenz ersetzt den Gutachter nicht
KI puzzelt aus vorhandenen Daten etwas Neues zusammen. Sie kann helfen, die Ausgangsbasis besser zu machen, mit der sie gefüttert wird. Einen Gutachter ersetzt sie damit nicht.
Der Grund liegt in der Erfahrung, die ein Gutachter mitbringt. Im stillen Kämmerlein greift er auf Bücher, frühere Projekte und Diskussionen zurück, die nirgends aufgeschrieben sind. Ein Wissen wie “in einem früheren Projekt ist genau das passiert” steckt in keinem Trainingsdatensatz.
Hinzu kommt die Intuition beim Lesen. Aus dem Erfahrungsschatz entsteht eine Assoziation, ein Gefühl, dass an einer Stelle etwas nicht stimmt. Genau hier tut sich eine KI bisher schwer. Dass KI und Reviews künftig viel miteinander zu tun haben, ist heute nicht absehbar.
