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?
Ein Code-Review ist ein Peer-Review, bei dem ein Entwickler den Code eines anderen Entwicklers überprüft. 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?