In der agilen Softwareentwicklung gibt es unterschiedliche Arten von Reviews. Doch nicht alle verfolgen die gleichen Ziele oder richten sich an die gleiche Zielgruppe. Je nach Kontext – ob auf Team-Ebene oder team-übergreifend – unterscheiden sich die verschiedenen Review-Formate in ihrer Durchführung, ihren Zielen und den beteiligten Stakeholdern.
In diesem Blog Post betrachten wir 4 wichtige Review-Arten genauer:
- Das Code-Review,
- das Sprint Review, sowie
- das Scaled Review und die System Demo.
Code-Review: Qualitätssicherung auf Code-Ebene
Was ist ein Code-Review?
In einem Code-Review wird der Code eines oder mehrerer Entwickler von anderen, bislang nicht mit diesem Code vertrauten, Entwicklern betrachtet und Feedback gegeben. Dieser Prozess kann formal oder informell, synchron oder asynchron stattfinden und ist ein zentraler Bestandteil moderner Softwareentwicklungspraktiken.
Ziele des Code-Reviews
- Frühe Fehleridentifikation: Probleme im Code werden entdeckt, bevor sie in die Produktion gelangen
- Qualitätssicherung: Sicherstellung, dass der Code den im Team und/oder Team-Übergreifend vereinbarten Standards entspricht
- Wissensaustausch: Verteilung von Wissen über die Codebasis und Best Practices im Team
- Kostenersparnis: Reduzierung der Kosten durch frühzeitige Fehlererkennung
- Effizientere Entwicklung: Reduzierung technischer Schulden und Verbesserung der Code-Struktur
Zielgruppe
Die Zielgruppe für Code-Reviews sind die Dev-Teams bzw. Entwicklerteams selbst.
Sprint Review: Feedback zum Produktfortschritt
Was ist ein Sprint Review?
Das Sprint Review ist ein klassisches Scrum-Event am Ende jedes Sprints. Hier präsentiert das Team seinen End-Anwendern und Stakeholdern das im Sprint Erreichte und sammelt Feedback.
Ziele des Sprint Reviews
- Transparenz schaffen: Offenlegung des konkret nutzbar Erreichten
- Ausrichtung an der Produktvision: Sicherstellung, dass das Entwickelte mit den Geschäftszielen übereinstimmt
- Feedback einholen: Sammeln von Feedback der End-Anwender für neue und bestehende Product-Backlog-Items (Priorisierung und Art der Umsetzung)
- Kontinuierliche Verbesserung: Identifikation von Anpassungsbedarf aktueller Überlegungen und Vorgehensweisen (bspw. Usability)
- Zusammenarbeit fördern: Stärkung der Beziehung, insbes. des Vertrauens, zwischen Team, End-Anwendern und Stakeholdern
Zielgruppe
Das Sprint Review richtet sich an das Scrum Team (Dev-/Entwicklungsteam, Scrum Master, Product Owner) sowie an für das Team relevante End-Anwender und Stakeholder (Auftraggeber, Product Manager, Chief Product Owner, Management, …)
Scaled Review/System Demo: Koordination in Multi-Team-Umgebungen
Was ist ein Scaled Review?
In skalierten Scrum-Umgebungen, in denen
- mehrere Teams an einem gemeinsamen Produkt arbeiten oder
- mehrere Teams mit eigenen Produkten im Rahmen einer gemeinsamen Strategie arbeiten,
wird oft ein spezieller Review-Prozess genutzt, um Arbeit mehrerer Teams zu verbinden/”alignen”. Frameworks wie Scrum@Scale, LeSS (Large-Scale Scrum) und Nexus bieten hierzu jeweils eigene Ansätze:
- Scrum@Scale: Scaled Review
- SAFe: System Demo
- LeSS: Sprint Review (=> Ergebnis der Arbeit mehrerer Teams)
Ziele des Scaled Reviews
- Gemeinsamer Fortschritt: Das Zusammenspiel der Ergebnisse der Teams (in SAFe: ART) wird sichtbar und Feedback zu Anpassungsbedarfen möglich
- Identifikation von Abhängigkeiten: Erkennen und Managen von Schnittstellen zwischen Teams
- Vereinheitlichung der Produktvision: Sicherstellung, dass alle Teams auf dasselbe Ziel hinarbeiten
- Vermeidung von Redundanzen: Minimierung von doppelter Arbeit und widersprüchlichen Lösungen
Zielgruppe
Die Zielgruppe variiert je nach Framework:
- In Scrum@Scale: Das Product Owner Team unter Führung des Chief Product Owner
- In Nexus: Ausgewählte Vertreter aller Teams und relevante Stakeholder
- In LeSS: Alle Teams, die am Produkt arbeiten, und relevante Stakeholder
Unterschiede und Gemeinsamkeiten der Review-Arten
| Review-Typ | Fokus | Ebene | Hauptziel | Häufigkeit |
|---|---|---|---|---|
| Code-Review | Code-Qualität | Team / Technisch | Bessere Code-Qualität | Kontinuierlich |
| Sprint Review | Funktionalität | Team / Produkt | End-Anwender-Feedback | Ende jedes Sprints |
| Scaled Review / System Demo | Zusammenspiel | Multi-Team / Produkt | Überprüfung des integrierten Inkrements | Ende jedes Sprints oder jeder Iteration |
Was ist es?
Je nachdem was im Review gemacht wird, ist erkennbar um welche Art von Review es sich handelt:
Fazit
Reviews sind ein unverzichtbarer Bestandteil agiler Entwicklungsprozesse – vom Code-Review bis hin zum umfassenden Scaled Review in skalierten Umgebungen. Jeder Review-Typ hat seine spezifischen Ziele und Zielgruppen und trägt auf seine Weise zur kontinuierlichen Verbesserung bei.
Die Kunst besteht darin, die richtige Balance zu finden:
Ziel und Zielgruppe der Reviews sollten klar sein, um ihren Zweck zu erfüllen. Ein gut implementierter Review-Prozess – auf jeder Ebene – fördert nicht nur die Qualität, sondern auch das gemeinsame Lernen und die Zusammenarbeit im Team.
Welche Review-Praktiken habt ihr etabliert? Welche Erfahrungen habt ihr mit Reviews, besonders in skalierten Umgebungen, gemacht?