Wozu dient die „Definition of Done“?

Wozu dient die „Definition of Done“?

Der Definition of Done (DoD) kommt im Scrum eine hohe Bedeutung zu. Es handelt sich nicht um eine festgelegte Vorschrift, sondern um die Absprache des Teams, wann eine Aufgabe als „fertig“ betrachtet werden darf. Sicher ist das von den konkreten Umständen im Projekt abhängig, so dass sich ein Team schon gleich zu Beginn auf eine solche Definition of Done festlegen sollte.

Wer hat nicht schon solche Diskussionen erlebt, wenn es um die Frage ging, …

„Wann ist denn Aufgabe xyz fertig?“
„Wir sind fertig.“
„Ah, super, dann können wir ja sofort ausliefern?“
„Nein, wir müssen erst noch testen.“
„Also seid ihr noch nicht fertig?“
„Doch, es ist alles fertig programmiert, nur noch nicht getestet.“

Wie jetzt? Ist die Aufgabe nun fertig oder nicht? Aus dem scheinbar uneingeschränkten „fertig“ wird im Laufe der Diskussion zunächst die Einschränkung „fertig programmiert“, und später kommt vielleicht noch ein „ja, es ist alles fertig getestet, nur dokumentieren müssen wir noch“ hinzu. Hier wird sicher klar, dass dieses Team kein gemeinsames Verständnis von „fertig“, also keine „Definition of Done“ hat. Solche kreativen Interpretationen eines Begriffes kommen sicher nicht selten vor. Daher leuchtet es ein, dass ein „Commitment“ des Teams auf eine klare Definition Vorteile bringt.

Was bedeutet „fertig“?

Wie oben schon bemerkt, sind die Kriterien, wann eine Aufgabe wirklich erledigt ist, von den konkreten Umständen des Projektes abhängig. Wenn es in einem Projekt bereits ausreicht, etwas programmiert zu haben und die bestehenden Unit-Tests zu starten, sind in einem anderen Projekt vielleicht zusätzlich noch Handbuch und Online-Hilfe zu aktualisieren, oder es müssen Auslieferungsdokumente erstellt werden, ohne die die Software nicht herausgegeben werden darf. Vielleicht muss ein behobener Bug auch erst die Testabteilung durchlaufen. Oder geschieht das erst kurz vor einem Release?

Wie gelangt man zu einer DoD?

Wenn es die Möglichkeit gibt, Kollegen nach bereits erfolgreich durchgeführten Aufgaben zu befragen, dann kann das helfen, eine Checkliste zu erstellen. Vielleicht gibt es auch eine allgemeine Vorschrift in dem Unternehmen, die man zu Rate ziehen kann.

Ganz im Sinne des agilen Vorgehens könnte man auch sagen, wir machen zunächst mal nichts. Wenn dann jemand sich beschwert, ändern wir es und sind beim nächsten Durchlauf besser. Aber das führt zwangsläufig zu vielen Beschwerden, und das drückt die Stimmung.

Vielleicht sollte eine Mischung zwischen beidem gewählt werden: Möglichst gute Recherche vorher, agiles Anpassen, wenn doch noch Fehler gemacht werden. Voraussetzung dafür ist, dass man die Checkliste, also unsere „Definition of Done“, an gut sichtbarer Stelle aufhängt. So kann jeder Entwickler immer mal einen Blick darauf werfen und damit sicher stellen, dass nichts vergessen wurde. Und wenn jemandem mitten im Sprint etwas einfällt, was hier noch nicht drauf steht, kann es (nach einer kurzen Abstimmung im Team) unbürokratisch dazugeschrieben werden und somit sofort zu einer Verbesserung der Arbeit führen.


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

zwanzig − 13 =