Code-Review-Retrospektive Template (Free)

Was ist eine Code-Review-Retrospektive?

Eine Code-Review-Retrospektive ist ein Meeting, in dem sich euer Team anschaut, wie es Code reviewt, und nicht den Code selbst. Pull Requests, die tagelang liegen bleiben, Kommentare ohne Kontext, Reviews, die nur den Stil prüfen: Solche Probleme kommen in einer normalen Sprint-Retro selten zur Sprache, weil sie sich über die Woche aller verteilen, statt an einem einzelnen Ereignis festzuhängen. Das Board hat vier Spalten. „Was läuft gut?“ sammelt die Review-Gewohnheiten, die ihr beibehalten wollt, etwa eine hilfreiche Checkliste oder einen respektvollen Umgangston. „Was läuft nicht gut?“ deckt die Schmerzpunkte ab, von zu großen Pull Requests bis zu uneinheitlichen Standards. „Was können wir verbessern?“ macht daraus konkrete Änderungen, zum Beispiel eine Obergrenze für die Änderungsgröße oder eine vereinbarte Bearbeitungszeit. „Welche Fragen sind aufgekommen?“ hält offene Fragen fest, die das Team erst klären muss, bevor es entscheiden kann. Führt sie nach einem großen Release durch, wenn Verzögerungen bei Reviews die Auslieferung bremsen oder wenn neue Leute dazukommen und die ungeschriebenen Review-Standards des Teams aufgeschrieben werden sollten. Bleibt dabei schuldfrei: Es geht um den Prozess, nicht um die Kommentare einer bestimmten Person zu einem bestimmten Pull Request.

Format der Code-Review-Retrospektive

Was läuft gut? Was funktioniert bei unseren Code Reviews gut?: Fangt mit dem an, was funktioniert. Fragt nach konkreten Review-Praktiken, die geholfen haben, und würdigt die Leute, deren Reviews etwas bewirkt haben.
Was läuft nicht gut? Welche Herausforderungen oder Schmerzpunkte gab es bei Code Reviews?: Sorgt dafür, dass man Probleme ansprechen kann, ohne jemandem die Schuld zu geben. Fragt nach konkreten Beispielen, etwa einem Review, das Tage gedauert hat, oder einem Kommentar, mit dem man nichts anfangen konnte.
Was können wir verbessern? Wie können wir unseren Code-Review-Prozess und unsere Praktiken verbessern?: Bittet um konkrete, umsetzbare Vorschläge. „Bessere Reviews“ ist keine Maßnahme, „Pull Requests aufteilen, die mehr als ein Feature betreffen“ schon.
Welche Fragen sind aufgekommen? Welche neuen Fragen oder Themen zum Weiterverfolgen sind entstanden?: Schreibt die Fragen auf, die das Team heute nicht beantworten kann, und vereinbart, wer sich bis zur nächsten Retro um welche kümmert.

Wann sollte diese Retrospektive durchgeführt werden?

Wenn Reviews die Auslieferung bremsen oder für Reibung sorgen und ihr herausfinden wollt, warum.
Wenn Entwickler die Review-Praktiken teilen sollen, die für sie funktionieren.
Nach großen Releases oder Projekten, um zu sehen, wie sich die Reviews unter Druck bewährt haben.
Wenn neue Leute dazukommen und sich das Team auf Review-Standards, Erwartungen und Bearbeitungszeiten einigen muss.

Vorschläge für Fragen zum Icebreaker

Was ist der interessanteste Code, den du in letzter Zeit reviewt hast?
Wenn du deinem Code-Editor ein Feature hinzufügen könntest, welches wäre das?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

Haltet die Diskussion schuldfrei, damit die Leute ehrlich über Reviews sprechen, die ihnen schwergefallen sind.
Würdigt gutes Reviewen, etwa klare Kommentare oder eine schnelle Rückmeldung, und nicht nur die Probleme.
Bezieht alle ein, die Code schreiben oder reviewen, auch Tester.
Einigt euch auf ein oder zwei konkrete Änderungen statt auf eine lange Liste guter Vorsätze.
Verfolgt die Action Items nach und prüft den Fortschritt in euren nächsten Retrospektiven.
Wechselt die Moderation, damit unterschiedliche Perspektiven die Diskussion leiten.

Häufig gestellte Fragen

Was ist eine Code-Review-Retrospektive?

Ein Meeting, in dem euer Team darüber nachdenkt, wie es Code reviewt: was gut läuft, was nicht, was sich verbessern lässt und welche Fragen noch offen sind. Ziel sind Reviews, die schneller gehen und für die Person, die sie erhält, hilfreicher sind.

Wann sollte man eine Code-Review-Retrospektive durchführen?

Nach einem großen Release oder Projekt, wenn Verzögerungen bei Reviews die Auslieferung bremsen, oder regelmäßig, um Review-Standards zu vereinbaren, bevor sich Gewohnheiten festsetzen.

Welche Fragen sollte man in einer Code-Review-Retrospektive stellen?

Beginnt mit den vier Fragen auf dem Board: Was läuft gut, was läuft nicht gut, was können wir verbessern und welche Fragen sind aufgekommen? Hilfreiche Anschlussfragen sind etwa, wie lange Pull Requests auf ein erstes Review warten und ob Kommentare erklären, warum eine Änderung nötig ist.

Wie lange dauert eine Code-Review-Retrospektive?

Plant 45–60 Minuten ein. Wenn es im Team viele Probleme mit Reviews gibt, konzentriert euch auf die zwei oder drei Themen mit den meisten Stimmen.

Worin unterscheidet sie sich von einer Sprint-Retrospektive?

Eine Sprint-Retrospektive behandelt alles, was im Sprint passiert ist. Eine Code-Review-Retrospektive betrachtet eine einzelne Praxis im Detail, sodass Probleme, die in einem einzelnen Sprint klein wirken, etwa langsame Reviews, genug Aufmerksamkeit bekommen, um sie zu lösen.

Was ist eine Code-Review-Retrospektive?

Format der Code-Review-Retrospektive

Was läuft gut?

Was läuft nicht gut?

Was können wir verbessern?

Welche Fragen sind aufgekommen?

Wann sollte diese Retrospektive durchgeführt werden?

Vorschläge für Fragen zum Icebreaker

Ideen und Tipps für Ihre Retrospektive

Häufig gestellte Fragen

Verwandte Vorlagen