Erste Schritte mit einer Definition of Done

Das erste Thema in meiner Arbeit mit einem neuen Team ist deren definition of done. Mit agilem Vorgehen unerfahrene Teams tun sich hier zu Beginn oft schwer. Wozu braucht man eine DoD, wie startet man, was ist zu beachten?

DoD, die ersten Schritte: Was muss getan werden

Was aber ist »fertig«? Diese Frage beantwortet das Development-Team mit einer definition of done. Eine DoD ist eine Checkliste, die man gegen jedes Ticket, jede Story halten und prüfen kann, ob dieses Ticket erledigt ist, oder nicht.

Hier ein Beispiel:

  • All assets are finalized and available as agreed
  • Code style is met
  • Implementation tests out in Unity Editor
  • No errors related to implemented feature
  • Report error for other features
  • If possible, feature is reviewed by assigned reviewer (see Task Definition in DoR)
  • If feature is UI related it must be viewed in device simulator
  • New and previously created Unit tests passed
  • Committed & pushed to current branch with appropriate comment(s)
  • Commits are part of a build
  • Build working on Unity Cloud Build
  • Create a release notes for changes in the build
  • Feature is reviewed by assigned reviewer on a device
  • Create enduser documentation for features in Confluence

Diese DoD ist vier Sprints alt, also noch frisch. Man bemerkt das an den sehr konkreten, kleinteiligen Spiegelstrichen. Dennoch kann das Team damit arbeiten jede Aufgabe prüfen: »done or not done.«

Der Software Development Lifecycle und die DoD

Schematische Darstellung des Software Development Lifecycles.

Die Definition of Ready ist für die Aufgaben nützlich, die auf Verständnis und Lösungsoptionen abzielen. In der Umsetzung hilft dann die Definition of Done.

Man nutzt den SDLC im Zusammenhang mit der DoD zur Prüfung der Zusammenstellung des Development-Teams. Tauchen in der DoD Aufgaben auf, für die dem Team die passende Expertise fehlt, sollte dem nachgegangen werden. Wird das nicht geprüft, könnte das Team nicht in der Lage zu sein, seine Aufgabe zu erfüllen. Es wäre immer wieder von anderen Teams abhängig, und könnte somit nicht selbst-organisiert arbeiten.

#NoEstimates

Ob eine Aufgabe innerhalb eines Sprints länger dauert als eine andere, spielt keine Rolle. Wenn das Team als Teil des Refinements zeitliche Schätzungen abgeben soll, damit Sie als Product-Owern*in das Backlog anhand dieser Angaben sortieren können, zum Beispiel um möglichst viele Backlog-Items umsetzen zu können, verringern Sie im Zweifel den lieferbaren Wert. Selbst wenn das nicht zuträfe, es bleibt dabei: Eine Schätzung als explizit angegebener Zeit schafft keine Mehrwert gegenüber einer implizite Abwägung des Teams anhand der DoD.

Zumal über das Planning hinaus die explizite zeitliche Schätze keine relevante Kenngröße mehr ist. Für Abweichungen gibt es immer Gründe — im Zweifel solche, die nicht im Team selbst liegen.

Definition of Done im Überblick

Das ist wichtig für das Team, um einschätzen zu können, wie viele beziehungsweise welche Backlog-Items es für einen Sprint auswählen kann.

Wenn ein Team zum ersten Mal zusammenkommt, um an ihrer DoD zu arbeiten, werden verschiedene Aspekte und Details zur Sprache kommen. Das Team hat die Wahl, sich zu Beginn auf wenige Aspekte zu konzentrieren, in der Regel auf diejenigen, die am meisten mit der Produktqualität zu tun haben. Mit der Zeit wird ein Team an ihrer DoD arbeiten und immer mehr Aspekte einbeziehen. Auf diese Weise hilft ein DoD dem Team, wertvollere Software zu entwickeln. Bestimmte DoD-Angaben, wie im obigen Beispiel »Code style is met«, helfen bei der Automatisierung, was wiederum Zeit freiräumt.

Und wenn wir keine DoD haben?

Die definition of done hilft, den vollen Umfang der nötigen Arbeit zu verstehen, die zur Erfüllung eines Backlogs-Items getan werden muss.

Wenn Sie keine DoD haben, müssen Sie immer wieder, für jede Aufgabe neu überlegen und formulieren, was zu tun ist, um dieses Stück Arbeit bis zur Releasefähigkeit zu entwicklen. Das ist anstrengend und fehlerfällig. Leicht geht vergessen, dass ja noch Integrationstests machen, Dokumentation zu schreiben, Assets komprimiert, Konfigurationsangaben zu ändern sind. Eine Stunde vor dem geplanten Release ist es dafür zu spät.

Hat man nicht diese gesamte Arbeit auf dem Schirm, kann das Team auch keine belastbare Aussage über den Umfang der im Sprint leistbaren Arbeit treffen. Sprintziele werden nicht erreicht oder es bleibt keine Zeit für Bugfixing, am Ende kann das Team nicht liefern, was es liefern wollte.

Ihr Sascha A. Carlin

Als Agile Coach verhelfe ich Führungskräften in der Softwareentwicklung zu mehr Wirksamkeit.

Kontaktaufnahme jederzeit via E-Mail oder Telefon +49 30 40782375.

Als Organisationsberater verhelfe ich agilen Führungskräften in der Softwareentwicklung zu sichtbar mehr Anteil am Unternehmenserfolg. https://nvsbl.cm/

Als Organisationsberater verhelfe ich agilen Führungskräften in der Softwareentwicklung zu sichtbar mehr Anteil am Unternehmenserfolg. https://nvsbl.cm/