Als Scrum/Agile-System-Student finde ich die Situation, in der man eine User Story in klassischer Form schreiben und gleichzeitig das Verhalten paralleler Workflows beschreiben muss, sehr schwierig. Als ein sehr einfaches und allgemeines Beispiel, das die Situation beschreiben kann, können wir diese User Story schreiben:
Als Benutzer, der einen Artikel kaufen möchte, möchte ich mit MasterCard bezahlen können, damit die gekaufte Bestellung auf den Status „Liefern“ gesetzt werden kann.
In dieser User Story gibt es unzählige verschiedene "alternative Arbeitsabläufe für Benutzeraufgaben" oder Situationen, die unterschiedliche Prozesse (nicht notwendige Fehler) definieren können, wie zum Beispiel:
Während ein Kunde eine Bestellung aufgibt, ist seine Kreditkarte fehlgeschlagen
Während ein Kunde eine Bestellung aufgibt, läuft seine Benutzersitzung ab
Während ein Kunde einen Geldautomaten benutzt, gehen dem Automaten die Quittungen aus und er muss den Kunden warnen
Während ein Kunde eine Bestellung aufgibt, existiert seine Kreditkartennummer nicht
Während ein Kunde eine Bestellung aufgibt, ist die PIN fehlgeschlagen
(sind vielleicht nicht die besten Beispiele, aber nur um Nebenwirkungen zu beschreiben).
Im Agile/Scrum-System kann man nur das gewünschte Verhalten beschreiben, nicht aber die Nebeneffekte/parallele Arbeitsabläufe.
Meine Fragen:
Wie raten Sie mir, die Backlog-Geschichten einzufügen, die diese Situationen abdecken?
Wie raten Sie mir, Geschichten zu erstellen, die einem „Task Process Workflow Diagram“ folgen? (Diese zweite Frage ist anders, aber verwandt)
Eine der netten Techniken, die Teams verwenden, ist das Schreiben von Verifizierungskriterien für die User Story auf die Rückseite eines Haftnotizzettels oder in zusätzliche Informationen der User Story (wenn Sie ein elektronisches Tool verwenden). All diese detaillierten Szenarien, die Sie erwähnen, eignen sich gut als Überprüfungskriterien, und wenn Sie sie als solche verwenden, gehen Ihnen diese zusätzlichen Informationen nicht verloren.
Persönlich würde ich nicht dazu raten, sie als separate User Stories zu erstellen, da Sie so sehr ins Detail gehen würden, dass Sie sich mit viel Mühe konfrontiert sehen müssten, alle Stories zu jonglieren, obwohl man dies auch als praktikable Alternative betrachten könnte.
Und vor allem sollten Sie sich nicht zu sehr an ein bestimmtes Format von User Storys binden . Wenn Sie zusätzliche Informationen benötigen und möchten, schreiben Sie sie einfach auf und hängen Sie sie irgendwie an. Ihr Ziel sollte ein gemeinsames Verständnis der zu erledigenden Arbeit sein und nicht einer Buchdefinition der User Story folgen. Die User Story ist nur ein Mittel, um ein gemeinsames Verständnisziel zu erreichen. Solange das Team also den Einfluss der Story auf alternative Arbeitsabläufe versteht, machen Sie es richtig.
Sie haben eine gute Frage, und ich denke, ein Blick auf die User Story kann helfen, einige Teile des Problems aufzuschlüsseln. Meine erste Reaktion ist, als Benutzer interessiert Sie der Status der Bestellung nicht, das ist Ihnen nicht wichtig.
Die User Story kann viel einfacher und As a user you want to be able to use Mastercard to purchase an article. Dies impliziert:
Zusätzliche User Stories:
Aus Ihrem Beispiel gibt es folgende, die untersucht werden müssen:
While a customer places an order, their user session times out
As a user when I place my order, I expect not be charged twice nor get multiple orders without paying, und ebenso `Ich sollte in der Lage sein, meine Bestellung nachzuschlagen und den Status zu verstehen.While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer
As a user when I ask for a receipt but there are none, I expect to emailed the receiptAs a user I expect a transaction to be declined if there are no receipts available but I want one.While a customer places an order, their credit card number doesn't exist
As a user, when I enter an invalid credit card (for whatever reason) I should be notified before the order is placed, so I can correct itAs the finance department when a invalid credit card is entered send an automated email to the user to indicate their order will be cancelled unless they fix the credit card number. Finance kann auch Ihr Benutzer sein, nicht nur Ihr Kunde.While a customer places an order, the PIN failed
As a user when I enter an invalid PIN, I should be alerted to enter a valid oneif this happens more than 3 times, I want my card to be destroyed in case of theft.Für die konkrete Beratung:
Wie raten Sie mir, die Backlog-Geschichten einzufügen, die diese Situationen abdecken?
and also all other user stories, das ist de facto wahr.Wie raten Sie mir, Geschichten zu erstellen, die einem „Task Process Workflow Diagram“ folgen? (Diese zweite Frage ist anders, aber verwandt)
Ben K