Wir haben ein Startteam, das Scrum verwendet, und wir verstehen den Wert einer klaren „Definition of Done“ in unserer Entwicklung. Wir haben die Menge an Dingen oder Prozessen ausgewählt, die eine Aufgabe als „erledigt“ betrachten muss, aber eigentlich haben wir keinen klaren Weg, wie wir damit umgehen sollen.
Müssen wir die Definition von erledigt in die Akzeptanzkriterien aller Aufgaben aufnehmen? als Teilaufgabe festlegen, die wir erledigen müssen, oder einfach als Dokumentation zu diesem Produkt behandeln, die jeder kennen muss?
Die traditionelle Scrum-Lösung wäre, das Team zu fragen. Da sich das Scrum-Team selbst organisiert, sollten viele der spezifischen Methoden, um Dinge zu tun, dem Team überlassen werden, wobei der Scrum Master das Team coacht, um sicherzustellen, dass die Werte, Prinzipien und Absichten des Scrum Guides eingehalten werden.
In der Praxis würde ich eine leichtgewichtige Dokumentation bevorzugen, anstatt sie jeder Aufgabe oder jedem Product Backlog Item in einem Ticket-Tracking-Tool zuzuweisen. Wenn Sie den Prozess nicht weitgehend automatisieren können, scheint es, als würde das Einfügen Ihrer Definition of Done in ein Task- oder Ticket-Tracking-Tool viel Overhead verursachen und die Tracking-Arbeit am Ende erschweren. Eine Wiki-Seite oder etwas Ähnliches kann die Informationen so zusammenfassen, dass das gesamte Team darauf zugreifen kann, und sie können im Laufe der Zeit geändert werden, wenn das Team seine Definition of Done im Laufe der Zeit verbessert.
Etwas, das ich hinzufügen möchte, um die anderen Antworten hier zu unterstützen, ist, dass die Definition von "Done" (DoD) möglicherweise nicht vollständig dem Scrum-Team "gehört":
Wenn ein Product-Backlog-Eintrag oder ein Inkrement als „Done“ bezeichnet wird, muss jeder verstehen, was „Done“ bedeutet … Wenn die Definition von „Done“ für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, alle Scrum-Teams müssen es als Minimum befolgen... Wenn mehrere Scrum-Teams an der System- oder Produktfreigabe arbeiten, müssen die Entwicklungsteams aller Scrum-Teams gemeinsam die Definition von „Fertig“ definieren. - Der offizielle Scrum-Leitfaden
Ich würde vorschlagen, dass "jeder", der an Qualität interessiert ist, nicht nur die Entwicklungsorganisation, sondern auch die Stakeholder umfasst. Daher ist es wahrscheinlich notwendig, das DoD allen Parteien zugänglich zu machen.
Aus praktischer Sicht fand ich ein DoD in Form einer Checkliste am nützlichsten. Auf diese Weise können die DoD-Elemente abgehakt werden, wenn ein Mitglied des Scrum-Teams ein Sprint-Backlog-Element als „erledigt“ bestätigt. Halten Sie das DoD daher in einem Format bereit, in dem es leicht auf einem Bildschirm angezeigt oder auf ein Blatt Papier gedruckt werden kann.
Zunächst stimme ich dem zu, was andere über das Team sagen, das die Definition von erledigt festlegt. Sie müssen dieses Buy-in und dieses gemeinsame Verständnis bekommen, wenn Sie bei der Implementierung von DOD erfolgreich sein wollen.
Es gibt zwei Möglichkeiten, wie wir die Definition of Done ansprechen. Einer ist aus einer Workflow-Perspektive (a la Jira Boards). Wir haben zunächst damit begonnen, dass der Code abgeschlossen war, aber als sich unsere CI-Bereitstellungsfunktionen verbesserten, haben wir dies zu „In Produktion“ verschoben. Dies funktioniert für 90 % unserer Arbeit, die auf der Codierung für ein vorhandenes Produkt basiert, bei dem wir etwas modifizieren, das bereits in der Produktion funktioniert.
Für SPIKES oder Stories, die zu MVP fortschreiten, aber noch nicht produktionsbereit sind, verbringen wir mehr Zeit mit der Dokumentation der Annahmebedingungen (COA), da diese Aufgaben nicht der Workflow-Definition von „Done in Production“ entsprechen.
Beispiele wären: Forschungsergebnisse auf der Wiki-Seite dokumentieren. Zukünftige Staatsarchitektur grafisch darstellen und Genehmigung durch CTO dokumentieren
Wenn es sich um beobachtbare, konkrete Ergebnisse handelt, sollte es kaum Unklarheiten darüber geben, ob die Aufgabe die Kriterien erfüllt oder nicht.
Es zu tun und es zu erledigen sind keine getrennten Aufgaben (oder Unteraufgaben).
Ein Backlog kann aus nichts anderem als Definition-of-Dones bestehen. Oft ist es vager, und diese Definition wird im Sprint erstellt, dann ist es erledigt. Diese beiden Aktivitäten sollten jedoch nicht als zwei Aufgaben erscheinen.
Möglicherweise haben Sie Meinungsverschiedenheiten darüber, was getan aussieht. Ich mag für Test-Driven-Development plädieren, der Rest des Teams mag für etwas weniger Strenges plädieren. Lautes Schreien funktioniert nicht. Daher akzeptiere ich die Teamdefinition, werde dies aber nachverfolgen, wenn Funktionen erneut aufgegriffen werden. Wenn wir zu häufig auf Funktionen zurückgreifen, zeige ich dem Team, dass unsere Definition-of-Done nicht funktioniert. (Es kann andere Gründe geben, die Definition-of-Done neu zu bewerten, z. B. zunehmende technische Schulden und Angst vor Refactoring.
Das Hinzufügen eines Vertreters der Kunden, der den Fortschritt kennt und die erledigte Aufgabe validiert, kann die Transparenz erhöhen und die Definition der erledigten Aufgabe verfeinern.
Barnaby Golden