Wie definiere ich komplexe Geschäftsregeln mithilfe von User Stories?

Eine schnelle und schmutzige Definition von User Story :

"As a <role>, I want <goal/desire> so that <benefit>"

In dieser allgemein akzeptierten Definition gibt es wenig Platz zum Definieren von Geschäftsregeln, Einschränkungen oder Benutzereingaben.

Triviales Beispiel nur zur Veranschaulichung:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Wo würde man in diesem albernen Beispiel die Felder definieren, die bei der Registrierung eines Buches benötigt werden? Sollte es irgendwo geschrieben werden? Oder sollten die erforderlichen Geschäftsregeln vom Product Owner als Mundpropaganda weitergegeben werden?

Die Felder sind Teil des Gesprächs , das geführt werden sollte. Sie können aufgeschrieben werden, wenn dies nützlich ist, aber das ist ein Urteilsspruch. Die Dokumentation auf dem neuesten Stand zu halten, kann eine Herausforderung sein, während die funktionierende Software in gewissem Maße als Dokumentation angesehen werden kann.

User Story - Ein Versprechen, ein Gespräch zu führen, wäre ein Blogeintrag darüber.

Ihr triviales Beispiel enthält einige Punkte, von denen ich nicht weiß, wie gut Sie dies bemerken würden. Was bedeutet es, "neue Bücher zu registrieren"? Was ist "Finden Sie ihre Verfügbarkeit online?" Hier beginnt das Gespräch, und sobald die Geschichte fertig ist, kann es zu neuen Geschichten kommen, da diese Registrierungen möglicherweise gespeichert oder regelmäßig Berichte erstellt werden müssen.

Die vorherigen Antworten enthalten gültige Punkte, insbesondere in Bezug auf eine User Story , die daran erinnert, ein Gespräch zu führen . Andere Dinge zu beachten:

1. Wenn die Geschichte zu komplex ist, ist es wahrscheinlich ein Epos . Sie können Epen jetzt oder nach Priorisierung im Product Backlog in kleinere Storys aufteilen

2. Details, die Testfälle implizieren, werden von der Geschichte selbst getrennt. [ Mike Cohn ]

   Sie können auf der Rückseite der Story-Karte hinzufügen, kleine Notizen machen, wenn sie wirklich wichtig sind, oder sie in das Dokument mit den Abnahmetests einfügen .

Als Richtlinie zur Bewertung, ob Ihre User Stories gut sind, können Sie dem Vorschlag von Bill Wake folgen :

• Ich bin unabhängig (von anderen Geschichten)
• N egotiable
• V aluable (an den Benutzer oder Kunden)
• E stimulierbar (in guter Näherung)
• S mall (genug, um abschätzbar zu sein)
• T estable

Vielleicht möchten Sie das Kapitel 2 "Geschichten schreiben" des Buches "User Stories Applied" von Mike Cohn lesen .

Normalerweise versuche ich, in einer umfassenden User Story mit vielen Facetten das allgemeinste Beispiel für die Story zu erhalten, und erstelle dann für Einzelheiten untergeordnete User Stories, die davon erben. Viele agile Projektmanagement-Tools wie RallyDev ermöglichen es Ihnen, dies einfach zu tun, und ich finde es sinnvoll.

Das Registrieren neuer Bücher ist weitreichend, daher gibt es vielleicht 10 andere untergeordnete Benutzergeschichten darüber <role>, wie Bücher registriert werden sollen.

Extreme Details dieser Dinge oder bizarre Randdetails, die ich normalerweise in einer oder mehreren Aufgaben unter dieser User Story definiere. Die Aufgaben helfen dabei, Entwicklungs- und Entwurfsarbeiten zu definieren, die (allgemein) durchgeführt werden müssen, um diese User Story zu erfüllen (z. B. Validator schreiben, um sicherzustellen, dass die Eingabe in das Beschreibungsfeld weniger als 50 Zeichen umfasst ...). BEARBEITEN: Ich wollte nur hinzufügen dass es wahrscheinlich besser ist, extreme Details aus User Stories herauszuhalten, da es einem Benutzer wahrscheinlich nicht wirklich wichtig ist. Benutzer möchten Software allgemein erklären und sind darauf angewiesen, dass Softwareentwickler die Details herausfinden und vor ihnen verbergen.

So gehe ich das Problem an, aber ich bin mir sicher, dass es verschiedene Möglichkeiten gibt.

Die Antwort ist einfach: Integrieren Sie die Geschäftsregeln in Akzeptanzkriterien.

Triviales Beispiel nur zur Veranschaulichung:

Als Bibliothekar möchte ich neue Bücher registrieren, damit die Schüler ihre Verfügbarkeit online finden können

Ich bin zufrieden, wenn: * ich die folgenden Felder registrieren kann: - ISDN - Autor - Dewey Decimal bla bla * Ich kann die Bestätigung sehen, dass das Buch vom System registriert wurde * Ich kann das Buch im System anzeigen

Wie definiere ich komplexe Geschäftsregeln mithilfe von User Stories?

Dafür sind User Stories nicht gedacht. Es handelt sich nicht um Softwareanforderungen, die alle Details oder Geschäftsregeln erfassen, die zum Schreiben der Implementierung erforderlich sind. Sie sind nur eine Beschreibung dessen, was die Anwendung aus Sicht des Benutzers tun sollte.

Denken Sie daran, was wichtig ist: Erstellen der richtigen Software. Sie verwenden alles, was dazu erforderlich ist, und User Stories dienen nur dazu, sicherzustellen, dass Sie die erforderlichen Funktionen der Anwendung gesammelt haben, damit Sie darüber sprechen, Prioritäten setzen, sie schätzen usw. Der fehlende Teil des klassischen Benutzers In der Geschichte (als ... ich will ... damit) geht es um die Kommunikation zwischen den am Erstellen der Software Beteiligten.

Die Details als Akzeptanzkriterien, Untergeschichten, technische Aufgaben, die mit der User Story verbunden sind, in einem Spezifikationsdokument oder was auch immer, gehen über das hinaus, was Ihnen die User Story hilft. Der User Stoy ist nur das "Gesprächsthema" bei der Entscheidung, wie die Software erstellt werden soll.

In dem angegebenen Beispiel gibt es viele Details der Buchregistrierung, über die Entwickler wenig wissen müssen, wie z. B. Dewey oder andere Klassifizierungssysteme, ISBNs, Erwerbsnummern, Kopien / Titel / Autoren, andere Ausgaben usw. Für ein neues System, solche Details müssen vom Kunden zur Verfügung gestellt werden (und Bibliothekar, alle Menschen, wird sicherlich um sie kümmert).

Um Steve O'Connell zu zitieren: "Es ist erschreckend, darüber nachzudenken, wie viel Geschäftspolitik von Entwicklern erstellt wird, denen die erforderlichen Details in den Spezifikationen fehlten, also haben sie es einfach selbst wieder gut gemacht."