Ich habe mich kürzlich mit einer Diskussion über die Nützlichkeit von Akzeptanzkriterien in einer User Story beschäftigt. Denken Sie daran, dass das betreffende Team kein Feature-Team ist, sondern ein Team für technische Komponenten (falls sich dadurch etwas ändert).
Die Teammitglieder haben ein oder zwei Seiten mit Dingen geschrieben, die sie bauen werden; weniger ein Spezifikationsdokument als vielmehr ein Definitionsdokument dessen, was getan werden muss. Darin ist es ziemlich klar, was die Tragweite der Geschichte ist. Das Fazit war also, dass man sich keine Gedanken über Akzeptanzkriterien (zB im Jira-Ticket) machen musste.
Dies scheint mit dem Team zu funktionieren, da es keine Unklarheiten bei der Implementierung gab (und wenn es welche gibt, wird das Team untereinander diskutieren), daher bin ich verwirrt darüber, was die Akzeptanzkriterien zu dieser User Story hinzufügen würden und ob es so wäre lohnt es sich, das durchzusetzen.
Es gibt kein einheitliches Formular für Akzeptanzkriterien. Wenn Ihr Dokument detailliert genug beschreibt, was getan werden muss, um Tests zu schreiben, dann ist dieses Dokument Ihr Akzeptanzkriterium.
Denken Sie daran, dass eine Geschichte aus drei Teilen besteht – Karte, Gespräch und Bestätigung. Die Karte ist eine Möglichkeit, das Team an die Arbeit zu erinnern. Das Gespräch (und alle erforderlichen Notizen oder Details, die aus diesen Gesprächen hervorgehen) helfen dem Team, auf eine Lösung hinzuarbeiten. Mit der Bestätigung stellen Sie sicher, dass die Arbeit erledigt ist, häufig durch automatisierte Tests. Es gibt verschiedene Möglichkeiten, das zu Erfassen, was Sie aus den zugehörigen Konversationen testen müssen.
Sie können natürlich ein Design- oder Anforderungsdokument als Grundlage für Ihre Akzeptanzkriterien verwenden. Sie müssen diese Informationen nicht erneut in einer Geschichte aufzeichnen, wenn Sie sie bereits haben. Bei Dokumenten kann die Änderungskontrolle jedoch schwierig sein. Wenn sich Ihr Backlog ändert und Sie neue Storys erstellen, möchten Sie möglicherweise an den vorherigen Versionen Ihrer Dokumente festhalten. Es kann für mehrere Personen schwierig sein, dasselbe Dokument gleichzeitig zu bearbeiten und gleichzeitig Klarheit darüber zu bewahren, welche Version für eine bestimmte Geschichte relevant ist. Aus diesen Gründen greifen viele Menschen nur dann auf Dokumente zurück, wenn sie müssen, und verlassen sich ansonsten auf Geschichten als den bevorzugten Ort, um Akzeptanzkriterien festzulegen.
Abnahmekriterien sind das, woran die Abnahmetests (auf Kundenseite!) durchgeführt werden. Es kann , muss aber nicht zu 100 % den Anforderungen entsprechen. Es sollte nicht mehr sein (da dies bedeuten würde, dass die Anforderungen nicht vollständig wären), sondern könnte eine Teilmenge von Anforderungen sein, insbesondere für die schrittweise Entwicklung.
Abnahmekriterien werden vom Kunden festgelegt, da er aufgrund des Ergebnisses des Abnahmetests die Leistung entweder annimmt oder ablehnt. Deshalb:
Um das Obige zu wiederholen ... "Akzeptanzkriterien" stellen dar, was das Geschäft(!) akzeptieren wird!"
Sie „sitzen da unten in Ihrem Code-Entwicklungsdungeon“, verstehen die Feinheiten des Quellcodes, den Sie entwickeln, vollständig. Aber das Geschäft muss nicht – und muss nicht – „und das ist der Punkt.“
Stattdessen formulieren sie ihre "Akzeptanzkriterien". (Und seien Sie sehr dankbar, dass sie es getan haben.) Weil Ihr Quellcode, wenn er ihnen schließlich geliefert wird, "ein Werkzeug in ihren Händen" sein wird. Es muss sie tatsächlich in die Lage versetzen, ihre Arbeit zu erledigen. (Nicht Ihre.) Sie müssen absolut sicher sein , dass die Software, die Sie ihnen schließlich liefern, sie in all diesen geschäftlichen (!) Punkten vollständig zufriedenstellt. Sonst hast du deinen Job überhaupt nicht gemacht.
Sie sollten bedenken, dass die Abnahme eine Kombination aus funktionalen und nicht funktionalen Kriterien sein kann – dh sowohl „was“ die Lösung liefert als auch „wie“ sie es liefert – was Leistung, Kapazität, Zuverlässigkeit, Wartbarkeit usw. sein kann An. Diese sollten alle erfasst werden. Wenn sie alle in der Design-Spezifikation enthalten sind, benötigen Sie möglicherweise keine separaten Akzeptanzkriterien (gemäß Ihrer ursprünglichen Frage).
Wenn diese nicht angegeben sind, würde ich vorschlagen, dass Sie ein Abnahmedokument erstellen, um Argumente wie „Sie haben nie gesagt, dass es mit 20.000 gleichzeitigen Benutzern fertig werden muss!“ oder „Ich dachte, es wäre offensichtlich, dass die System sollte trotz Hardware-Upgrades weiterlaufen." Oder sogar "Warum haben Sie es mit so viel freier Kapazität gebaut? Es wird nie mehr als 10.000 Einträge in der Datenbank verarbeiten müssen!"
Iain9688
dqm