Definition of Done verständlich erklärt
Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.
Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?
Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen “Definition of Done”. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.
Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.
Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:
- Habe ich Unit Tests entwickelt?
- Wurde die Dokumentation erweitert?
- Sind die Codekonventionen eingehalten?
- usw.
In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.
Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.
Diese – in Scrum übliche – DoD ist allzu trivial und schafft mehr offene Fragen als Lösungen. Die fundamentale Fehlannahme nämlich ist, dass eine “User Story” nur einen einzhigen “Done”-Status kennt und danach abgeschlossen ist.
So etwa gibt es neun “Technology Readiness Levels (TRLs)”:
• Basic – the lowest level of technology readiness where theory awaits practical implementation
• Technology concept formulated – some basic principles demonstrated, but still essentially theoreticalf • Proof-of-concept – some physical validation of parts of the design
• Subsystem/Component validation – laboratory environment integration of whole parts of the system
• Subsystem/Component validation in a relevant environment -technological components tested in a simulated environment
• System prototype – relevant demonstration – a simulated operational environment demonstration
• System prototype – operational demonstration – the demonstration of an actual system prototype in an operational environment
• System completed – technology qualified through test and demonstration in expected conditions
• Successful mission operations – Application of the technology under mission conditions.
Und Brian Wernham schlägt in seinem Buch “Agile Project Management for Government; Maitland and Strong Publishing London – New York – Sydney” diese “Hierarchy of delivery for Agile Projects” vor:
1 Specification Prototype A working model of some aspects of the solution.
2 Emerging Solution A partially constructed solution that conforms to technical standards, but still has functions missing required for real-world use.
3 Shippable A partially constructed solution that could be used.
4 Consumable A partially constructed solution that is ready for use.
5 Piloted An increment of the solution deployed and in use in a limited locality, customer segment and/or for a limited time
6 Implemented An increment of the solution that is in wide-scale rollout/use.
Hallo Hans-Peter, danke für Deine Anmerkung! Eine zu Deinem Thema verwandte Thematik kenne ich unter dem Begriff des “Level of Done”, also der Fragestellung, welche Qualitätskriterien auf welcher Fertigstellungsebene (Story / Sprint / Release) greifen. Um den Blogeintrag jedoch überschaubar zu halten, habe ich eine weitere Differenzierung weggelassen. Als ScrumMaster finde ich es auch hilfreich, hier weiter zu differenzieren. Die Art der Differenzierung ist da vermutlich je Coach unterschiedlich – im Endeffekt geht es ja immer darum: was funktioniert für uns in diesem einen Kontext.