Ich verstehe nicht, was der Unterschied zwischen beiden ist. Sie scheinen mir ähnlich zu sein. Ich habe zum Beispiel diese typische Benutzergeschichte zum Anmelden/Registrieren. Können Sie einige DOD-Beispiele nennen?
Als Benutzer
Ich möchte mich registrieren und einloggen
Damit ich mich bei der Bewerbung registrieren und mit der Nutzung des Cloud-Speichers beginnen kann
Akzeptanzkriterium:
Ich sollte in der Lage sein, die URL zu treffen
Ich sollte in der Lage sein, die Schaltfläche "Registrieren" anzuzeigen und auszuwählen
Ich sollte zum Formular "Registrieren" weitergeleitet werden
Nachdem der Benutzer das Formular abgeschickt hat, wird eine E-Mail an seine registrierte E-Mail-ID gesendet, diese E-Mail enthält das Kontopasswort
Dieses Passwort kann geändert werden
Nach Abschluss meiner Registrierung kann ich ein für mich passendes Paket auswählen.
Ich kann mich auch über Facebook, Twitter, Google anmelden.
Die Aufnahmekriterien, die Sie aufgelistet haben, sind wirklich eine Mischung aus Geschichten und Aufgaben.
Angesichts Ihrer Beispielgeschichte:
Als Benutzer möchte ich mich registrieren und anmelden, damit ich mich bei der Anwendung registrieren und mit der Nutzung des Cloud-Speichers beginnen kann
Ich würde das aufschlüsseln in:
Als Benutzer möchte ich mich registrieren, um Zugang zum Cloud-Speicher zu erhalten und ihn zu nutzen
und
Als Benutzer möchte ich mich anmelden, damit ich sicher auf mein Cloud-Speicherkonto zugreifen kann
Einige Ihrer Akzeptanzkriterien sind auch User Stories. Zum Beispiel:
Als Benutzer möchte ich mein Passwort ändern können, damit mein Konto sicherer ist
und
Als Benutzer möchte ich mich über Facebook registrieren können, damit ich mich schnell und bequem registrieren kann, ohne alle meine Daten erneut eingeben zu müssen
...usw.
Akzeptanzkriterien sind geschichtenspezifische Anforderungen, die erfüllt sein müssen, damit die Geschichte abgeschlossen werden kann. Sie sind eine Technik zum Hinzufügen funktionaler Details zu User Stories. Akzeptanzkriterien werden oft während der Backlog-Verfeinerung oder während des Sprint-Planungsmeetings hinzugefügt.
Einige Beispiele für Akzeptanzkriterien:
Es sollte kein Passwort länger als 16 Zeichen erlaubt sein
Die Mehrwertsteuer sollte in allen Zahlen enthalten sein
Diese Akzeptanzkriterien fügen der User Story Details hinzu und bieten außerdem eine praktische Anleitung zum Testen der Vollständigkeit der Story.
Als Teil einer User Story können Sie einige Unteraufgaben definieren, die sich auf die Implementierung beziehen . Beispielsweise könnte das Entwicklungsteam als Teil der Registrierungs-User-Story eine Unteraufgabe hinzufügen:
Fügen Sie eine „Registrieren“-Schaltfläche hinzu, auf die die Benutzer klicken können
und
Fügen Sie eine HTTP-Umleitung für nicht registrierte Benutzer zur Registrierungsseite hinzu
Aufgaben werden vom technischen Team verwendet, um ihnen bei der Organisation der Arbeit an der Story zu helfen. Typischerweise sind Aufgaben für Laien uninteressant.
Die Definition of Done ist eine Liste von Dingen, die abgeschlossen werden müssen, damit eine Story als erledigt gilt.
Die Definition of Done wird im Team vor Arbeitsbeginn abgestimmt. Es deckt ab, was das Team für notwendig hält, um eine Geschichte als abgeschlossen zu betrachten.
Beispiele könnten sein:
Regressionstest abgeschlossen
Benutzerdokumentation aktualisiert, um die neue Geschichte widerzuspiegeln
Vom Product Owner gesehen und genehmigt
Leistungstest-Benchmark erreicht
Architektur aktualisiert
Peer-reviewed
Die Akzeptanzkriterien sollen sicherstellen, dass die neue Funktion wie von den Stakeholdern erwartet funktioniert. Sie werden besser Business Facing Tests genannt .
Ein geschäftsbezogener Test ist ein Test, der als Hilfsmittel für die Kommunikation mit nicht programmierenden Mitgliedern eines Entwicklungsteams wie Kunden, Benutzern, Geschäftsanalysten und dergleichen gedacht ist
Die Definition of Done besteht darin, zu sehen, ob das Feature bereit ist, in der Produktion und nur für Mitglieder des Programmierteams bereitgestellt zu werden. Die Definition könnte beinhalten, dass das Feature Tests enthält, die Dokumentation aktualisiert wird, Versionshinweise geschrieben werden, die Versionskontrolle bereinigt wird und alles, was Ihr Team tun muss, um dieses Feature veröffentlichen zu können. Manche nennen es auch DoneDone wie in wirklich erledigt.
Beispiel Definition of Done aus der Scrum Shock Therapy :
Meine anfängliche Definition von "Fertig" ist diese:
- Funktion abgeschlossen
- Code abgeschlossen
- Keine bekannten Mängel
- Vom Product Owner genehmigt
- Produktion bereit
Sehen Sie sich auch die Definition von ready an, die verwendet wird, um zu prüfen, ob User Stories bereit sind, vom Entwicklungsteam übernommen zu werden. Es sollte beinhalten, dass die Akzeptanzkriterien geschrieben wurden.
Dies ist eine ausgezeichnete Frage, die meiner Meinung nach für viele Teams und Product Owner verwirrend ist.
Der einfachste Weg, sich an den Unterschied zu erinnern, besteht darin, sich einfach diese Frage zu stellen:
Ist diese Geschichte spezifisch oder müssen alle Geschichten dies tun, bevor sie als abgeschlossen gelten?
Wenn die Antwort lautet, dass es geschichtenspezifisch ist, dann ist es ein Akzeptanzkriterium für die Geschichte.
Wenn die Antwort lautet, dass dies im Allgemeinen alle Storys tun müssen, bevor sie als erledigt gelten, dann ist dies ein perfekter Kandidat für die Definition of Done, die Sie dem Team zur Prüfung vorlegen sollten.
Die Definition of Done sollte sich im Laufe der Zeit ändern, und ich empfehle, dass Sie Ihr Team etwa alle 2 Monate einen neuen Blick darauf werfen lassen, um sicherzustellen, dass sie ihnen gut dient.
Manchmal wird etwas, was einst Akzeptanzkriterien waren, Teil ihrer Definition of Done.
Ich habe eine Antwort, die auf meiner Erfahrung basiert, aber nachdem ich ein wenig herumgegoogelt habe, scheint die Antwort das zu sein, was für Sie in Ihrem Prozess am besten funktioniert. Wie David Espina in seiner Antwort erwähnte, können sie gleich oder unterschiedlich sein.
Durch meine Erfahrung:
Acceptance Criteriasind eine Reihe von Aussagen, jede mit einem klaren Pass/Fail-Ergebnis, die funktionale Anforderungen (z. B. minimale marktfähige Funktionalität) spezifizieren. Diese Anforderungen stellen „Zufriedenheitsbedingungen“ dar. Es gibt keine Teilakzeptanz: Entweder ein Kriterium ist erfüllt oder nicht.
Definition of Doneist ein Satz von Aussagen, die nichtfunktionale (z. B. minimale Qualitäts-) Anforderungen spezifizieren. Diese Anforderungen stellen „Zufriedenheitsbedingungen“ dar. Es gibt keine Teilakzeptanz: Entweder ein Kriterium ist erfüllt oder nicht.
Der Unterschied zwischen den beiden ist funktional vs. nicht funktional. Die nicht-funktionalen Bedingungen bestehen normalerweise unter anderem aus Dingen wie Code-Reviews und Unit-Tests, die keinen traditionellen Wert liefern, sondern Maßnahmen sind, um ein qualitativ hochwertiges Produkt sicherzustellen.
Meiner Meinung nach gibt es keinen Unterschied. Definition of Done und Akzeptanzkriterien werden synonym verwendet. Sie können die Definition von erledigt nicht erfüllen, wenn nicht alle Kriterien erfüllt sind, und Sie können nicht nicht erledigt sein, wenn alle Kriterien erfüllt sind. Wenn Sie sich im letzteren befinden, dann haben Sie aus unbekannten Gründen einfach zwei Kriteriensätze.
Eine Definition of Done ist etwas, an das sich alle Ihre Geschichten halten sollten.
Ein Akzeptanzkriterium ist spezifisch für die Story , an der Sie arbeiten werden.
Es gibt zwei Autos auf einer Produktionslinie.
Die Definition of Done ist, dass jedes Auto fertig aufgebaut sein muss, seiner jeweiligen Spezifikation entspricht, fahrbereit ist und alle Tests bestanden hat.
Die Akzeptanzkriterien (Spezifikation) für das erste Auto (Mini) umfassen Sitzbezüge aus Polyester, Armaturenbrett aus Kunststoff und manuelle Fensterheber.
Zu den Abnahmekriterien des Zweitwagens (Roller) gehören Bügel, Ledersitze, Sitzwärmer, Panzerglas, Schleudersitz und charmanter Begleiter.
QED
Die Definition of Done bezieht sich laut Scrum Guide auf das Produktinkrement. DoD funktioniert nicht für User Stories, Akzeptanzkriterien jedoch schon.
Somit beschreiben Akzeptanzkriterien Funktionalitäten, die nur von der spezifischen User Story oder Aufgabe verlangt werden.
Das Ziel der Definition of Done ist es, innerhalb des Teams ein gemeinsames Verständnis hinsichtlich Qualität und Vollständigkeit eines gebauten Produkts aufzubauen und sicherzustellen, dass jedes ausgelieferte Inkrement von hoher Qualität ist. Die Liste kann Folgendes enthalten: - Code wird in der Testumgebung bereitgestellt - Unit-Tests werden ausgeführt und alle bestanden - Code Peer-Review durchgeführt - Vom QA-Team (Umgebung) getestet - Fehler behoben - Akzeptanzkriterien erfüllt - Story wird dem PO vorgeführt und akzeptiert - usw Wir müssen die Definition of Done erfüllen, um Qualität zu gewährleisten.
Akzeptanzkriterien sind eigentlich ein Teil von DoD. Das Ziel der Akzeptanzkriterien besteht darin, zu klären, was das Team aufbauen sollte, und sicherzustellen, dass alle ein gemeinsames Verständnis über die Funktion und das Ergebnis haben
Universalgelehrter