Akzeptanzkriterien, Gegeben/Wann/Dann-Format verringern die Lesbarkeit der User Story?

Ich erstelle Akzeptanzkriterien für User Stories.

Da dies in meiner derzeitigen Firma die Hauptmethode zu sein scheint.

Ich habe das Gefühl, dass Given/When/Then die Lesbarkeit der User Story immer herabsetzt und unnötige Kommunikation erhöht.

Kennt jemand dieses Problem oder nur ich?

Wenn es das tatsächliche Problem ist, gibt es ein paar Optionen, die mir einfallen

  1. Schreiben Sie den vereinfachten Aufzählungspunkt AC und schreiben Sie G/W/T als Testfall für jeden Aufzählungspunkt (verbrauchen viel Zeit für PO und verlieren möglicherweise den Fokus für die Verfeinerung des Produkts).

  2. Schreiben Sie das vereinfachte Bullet-Point-AC und wenn das Team das wirklich braucht, erstellen Sie es einfach selbst. (Verbraucht viel Zeit für das Team und kann den Fokus auf die Lieferung verlieren).

  3. Oder sollte ich darauf drängen, es vollständig loszuwerden, und diese vereinfachten Stichpunkte als Testfälle verwenden.

Welche Option werden Sie vorschlagen, warum? Und kann ich sonst noch etwas tun?

Das ist eine sehr häufige Beschwerde. BDD ist auf den ersten Blick ein nettes Konzept, aber in der Praxis ist es von allen Seiten so ineffektiv - BA, QA, Dev. Bringen Sie das mit dem Team zur Sprache, denken Sie darüber nach, ob das, was Sie darüber gehört haben, wirklich wahr ist oder ob es nur ein weiteres Marketing-Märchen ist.
Der Product Owner ist ein vollwertiges Mitglied des Scrum Teams. Sie sollten mit den Entwicklern zusammenarbeiten, um Geschichten zu verfeinern und Akzeptanzkriterien zu identifizieren. Die Zeit des PO ist nicht wichtiger als die des restlichen Scrum-Teams, und der PO sollte auch nicht isoliert arbeiten. Beides sind Framework-Implementierungsgerüche.

Antworten (2)

Das Gegeben/Wann/Dann-Format ist nützlich, wenn Sie Ihre Akzeptanzkriterien automatisieren und Tests schreiben, um sie zu überprüfen. Sie schreiben im Grunde einen Test für jedes Ihrer Given/When/Then .

Sie haben Ihre Frage als BDD markiert, also möchten Sie vielleicht bei diesem Format bleiben. Der Vorteil ist, dass Sie ein paar Minuten damit verbringen, Ihre Akzeptanztests herauszufinden und sie dann zu schreiben. Wenn Sie Listen mit Aufzählungszeichen verwenden, wie viele Akzeptanztests werden Sie von jedem Aufzählungspunkt ableiten? Und wer entscheidet, der Entwickler, der PO? Sie könnten am Ende mit dem gleichen Ergebnis enden, also warum nicht etwas Mühe im Voraus aufwenden, als später nicht einige Testfälle zu verpassen?

Aber es hängt wirklich davon ab, wie Sie sie verwenden. Wenn Sie dieses Format nur als ausgefallene Art verwenden, Akzeptanzkriterien aufzulisten und keine ausführbaren Akzeptanztests daraus zu schreiben, dann würde eine Liste mit Aufzählungszeichen in einer natürlicheren Sprache vielleicht besser funktionieren.

Sie können Ihr Team jederzeit fragen, welche Methode es bevorzugt, und Sie können auch beide Methoden ausprobieren und bei der Methode bleiben, die besser funktioniert.

Given-when-then ist eher eine Möglichkeit, Szenarien als User Stories zu beschreiben.

Ein gängiges Format besteht darin, eine User Story gefolgt von einem oder mehreren gegebenen-wenn-dann-Szenarien zu haben, die dieser Story zugeordnet sind. Tatsächlich wird das gegebene Wann-dann zum Akzeptanzkriterium für die Geschichte.

Akzeptanzkriterien, Gegeben/Wann/Dann-Format verringern die Lesbarkeit der User Story?
AntwortenHierDatenschutz-Bestimmungen1y, 0v