Oder:
Wie und warum wir in SCRUM Qualitätsstandards definieren
Soll eine Story oder ein Tasks als „done“ bezeichnet werden, müssen alle das gleiche Verständnis darüber haben, was „done“ bedeutet. Obschon es hierbei signifikante Abweichungen zwischen verschiedenen Scrum Teams gibt, müssen die Mitglieder eines Teams zur Gewährleistung der Transparenz ein gemeinsames Verständnis haben was es bedeutet, wenn eine Arbeit abgeschlossen ist. Dafür sorgt die „Definition of Done“.
Die Definition of Done (DoD) ist eine Checkliste von Aktivitäten, die zur Implementierung einer User Story gehören und die Qualität der Software beeinflussen. Dazu gehört beispielsweise das Schreiben von Kommentaren, Unit Tests und Design-Dokumenten. Die DoD wird von den Beteiligten zu Beginn eines Projektes festgelegt, kann aber im Laufe der Entwicklung angepasst werden. Die DoD hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen. Am Ende des Sprints dient die DoD neben den detaillierten Anforderungen für eine spezifische User Story dazu, zu entscheiden, ob eine User Story als done akzeptiert wird.
–> DoD = Qualitätsstandards
Daraus folgt:
Eine Story (Task) ist nicht “done” bis sie die definierten Qualitätsstandards erfüllt. – Seeber, 2012
1. Entwicklung einer DoD anhand des Sprint-Ziels “shippable product”
Frage: What is a potentially shippable product?
“A shippable product is one that has been designed, developed and tested and is therefore ready for distribution to anyone in the company for review or even to any external stakeholder.” – Dhaval Panchal, 2011
Die DoD ist immer ein elementarer Bestandteil eines Vertrages zwischen ProductOwner (oder dem Kunden) und dem Team und regelt den Lieferumfang für jede Einzelbeauftragung durch Stories in jedem Sprint sowie für das Gesamtprodukt.
–> Team und PO entwickeln gemeinsam die Qualitätsstandards (DoD)
2. Die DoD ist nicht statisch
Eine DoD ist nicht in Stein gemeißelt und kann sich über die Dauer eines Projektes verändern:
Preparing a single definition of done that suits every situation is impossible. Each team should collaborate and come up with the definition that suits its unique environment.
Organisationen bzw. Teams finden es oftmals schwierig zu Beginn einer agilen Vorgehensweise eine fertige DoD zu erstellen – daher ist sollte man step by step vorgehen um die eigene DoD stetig anzupassen und zu verbessern. Feedback aus dem Retrospektive Meeting kann hier helfen die DoD weiterzuentwickeln.
–> Wichtig: Falls Anpassung/ Weiterentwicklung der DoD, dann nur VOR Beginn eines neuen Sprints und in Absprache zwischen Team & PO
3. Beispiele für DoDs
a) Sehr einfach:
Code Complete
Test Complete
Approved by Product Owner
b) Komplexer:
Code Complete
Unit tests written and executed
Integration tested
Code reviewed
Performance tested
Documented (just enough)
c) Noch komplexer:
Der Code erfüllt die Code-Konventionen und ist sauber geschrieben (Refaktoriert, aussagekräftige Namen, keine Duplizierung, inline Kommentare und Code-Dokumentation)
Alles (Buttons, Hilfe, Tooltips, Fehlermeldungen, …) ist in deutsch und englisch
Es gibt für alle nichtrivialen Klassen Unit Tests, die fehlerfrei durchlaufen.
Der Code + Unit-Test sind eingecheckt.
Der Code wurde auf dem Integrationserver getestet.
Die Hilfe ist erstellt.
Tipp: Keep it Simple (as possible) – keiner möchte unzählige Checklisten durchgehen.
Fragen? Best Practices?
Follow @tinoseeber
Follow me on Twitter, Facebook, Xing or Linkedin.
