Agile Methode: Definition of Done (Definition von fertig, Done)
Innerhalb jeder Timebox, bzw. innerhalb jedes Sprints sollte mindestens ein potentiell auslieferbares Produktinkrement erstellt werden.
Durch die Definition of Done wird festgelegt, was das Entwicklerteam unter "potentiell auslieferbar" versteht. Das "Done" beschreibt den angestrebten Zustand der Arbeit, der am Ende des Sprints erreicht werden soll.
Diese Definition of Done wird von dem Entwicklerteam gemeinsam festgelegt.
Die Definition of Done basiert also auf einer Entscheidung des Entwicklerteams. Natürlich findet hier ein Abstimmungsprozess mit dem Product Owner und anderen Stakeholdern statt. Aber es handelt sich hier um eine Festlegung des Entwicklerteam. In der Philosophie des Agil gibt es keine unternehmensweite Definition of Done, die auf Vorgaben von außen beruht und von allen Teams angewendet werden muss. Dabei werden funktionale und nicht funktionale Anforderungen des Unternehmens natürlich berücksichtigt.
Die Definition of Done ist kein starres Dokument, das am Anfang einmal definiert wurde und anschließend nicht weiter verändert werden darf. Es ist ein Living Document, das sich im Zeitverlauf entwickelt, den Gegebenheiten und der Erfahrung des Teams angepasst wird und im Zeitverlauf meistens genauer und detaillierter wird.
Die Minimalanforderung einer Definition of Done orientiert sich daran, was unter einem Inkrement zu verstehen ist. Ein Inkrement ist ein komplettes "Stück Funktionalität", dass:
- entworfen,
- gebaut,
- integriert,
- getestet und
- dokumentiert wurde und
- nachweislich einen Wert erbringt.
Klingt einfach - ist es aber nicht. Nehmen wir das Beispiel "getestet". Was versteht das Team jetzt genau unter "getestet". Bedeutet das, dass das Modul einmal funktioniert hat - oder dass es im Zusammenhang mit allen anderen Modulen einmal funktioniert hat. Oder das es z.B. einem Motor, über 1000 Stunden bei Höchstleistung nur einmal innerhalb der Laufzeit ausfällt und dann innerhalb von 2 Minuten wieder repariert werden kann? Und wie geht das Team mit dem Test von Modulen um, die zusammenarbeiten sollen, von denen aber einige erst in einem späteren Sprint erstellt werden?
In Tests, die einen längeren Zeitraum benötigen, liegt eine besondere Herausforderung. Ein Test, der über 1500 Stunden läuft, kann kaum innerhalb einer Timebox von 14 Tagen durchgeführt werden. Der Test muss zwangsweise außerhalb der Sprints stattfinden. Sonst müsste mit dem Beginn eines neuen Sprints gewartet werden, bis der Test abgeschlossen ist, was die Produktentwicklung ziemlich in die Länge ziehen würde. Aber wie geht das Team dann damit um, wenn dieser Test Fehler erkennen lässt.
Natürlich ist es extrem Aufwändig, solche Leistungstests in jedem Sprint durchzuführen. Einfach wäre es, einen Testsprint zu planen und dann alles zusammen zu testen. Aber was macht das Team dann, wenn sich heraus stellt, dass es doch einige Fehler gibt, so das Technische Schulden aufgebaut wurden?
Eine Definition of Done sinnvoll zu erstellen, setzt viele Vorentscheidungen voraus und kann ausgesprochen komplex werden. Eine eineindeutig beste Lösung wird sich wohl nicht ergeben. Ein Kompromiss zwischen verschiedenen Alternativen ist hier eher wahrscheinlich.
Bei einer Definition of Done handelt es sich zumeist um eine Checkliste.
Was führt zu einer Veränderung der Definition of Done?
Manchmal bestehen am Anfang eines Projektes organisatorische Hürden, z.B. für die Durchführung von Nutzertests, weil die Nutzer nicht zur Verfügung stehen, oder weil es keine ausreichenden Testdaten gibt, etc. Im Verlauf der Leistungserstellung können diese Hürden beseitigt und damit die Definition of Done verändert werden. Es ist aber auch möglich, dass das sich eine bestehende Definition of Done als nicht detailliert genug erweist und darum geändert werden muss.
Wichtig ist hierbei, dass die Veränderung in der Entscheidung des Teams liegt und nicht von außen vorgeschrieben wird.
Definition of Done und Akzeptanzkriterien
Die Definition of Done legt fest, wann ein Inkrement vorliegt. Also welcher Zustand vorliegen muss, damit das Team etwas für "potentiell auslieferbar" hält. Die Definition of Done gilt dabei für alle Inkremente. Ob die Definition of Done erfüllt ist, prüft das Team vor dem Review durch den Product Owner.
Akzeptanzkriterien werden für jede User Story vom Product Owner formuliert. Sie gelten für eine bestimmte Funktionalität, die sich aus der User Story ergibt. Damit bekommt jedes User Story ihre eigene Checkliste mit Akzeptanzkriterien. Ob die Akzeptanzkriterien erfüllt sind, wird durch den Akzeptanztest geprüft, der spätestens im Review durch den Product Owner stattfindet.
Die Definition of Done und die Akzeptanzkriterien sind also unabhängig von einander und existieren bei der Leistungsentwicklung nebeneinander.
Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org