Ich bin ein Anfänger und suche nach einer besten Möglichkeit, User Stories für mein Projekt zu erstellen, und ich brauche einen Rat. Es geht um ein Geldtransferprojekt, bei dem ich einen Überweisungsfluss erstellen muss: Überweisung konfigurieren, Empfänger hinzufügen, Zusammenfassung und Abschluss.
Sind dies nur vier User Storys für diesen Prozess, bei denen alle Details im Detailbereich einer JIRA-User Story angegeben werden sollten, oder sollte ich die erste aufteilen? Zum Beispiel:
und so weiter, oder es sollte nur sein:
Es gibt einige grundlegende Richtlinien, um Geschichten in kleinere Geschichten aufzuteilen. Dieses Mantra funktioniert fast immer. Es braucht jedoch wenig Zeit, um sich daran zu gewöhnen.
Folgen Sie INVEST
Ich liebe auch diese Story-Split-Muster . Das Verständnis dieser Muster und die Auswahl des richtigen Musters für Ihren Story-Typ könnte jedoch anfangs wenig herausfordernd sein.
Sie haben die Spezifikationen einer Implementierung mit einer User Story verwechselt. Bei User Stories geht es nicht darum , wie etwas erreicht wird; Stattdessen konzentriert sich eine gute User Story darauf, ausreichend Kontext über das Ziel des Benutzers bereitzustellen, um die Implementierung des Entwicklungsteams zu leiten.
Sie geben beispielsweise folgende Spezifikationen an:
- Als Benutzer möchte ich einen Überweisungsbetrag hinzufügen
- Als Benutzer möchte ich die Art der Überweisung wählen
- Als Benutzer möchte ich die Gesamtkosten einer Überweisung sehen
Dies sind eindeutig Implementierungsdetails Ihres Systems. Es ist unwahrscheinlich, dass der Benutzer in diesen Begriffen denkt.
Während es für jemanden, der nicht am Prozess beteiligt ist, schwierig ist, sicher zu wissen, was Ihre Benutzer tun möchten oder wie sie denken – Sie haben sie gefragt, oder?! Benutzerperspektive. Betrachten Sie die folgende Alternative:
Als Bankmitglied an einem Geldautomaten
möchte ich Geld von meinen Ersparnissen auf mein Girokonto überweisen
, damit ich sicher sein kann, dass auf diesem Konto genug Geld ist, um einen Scheck zu decken, den ich heute ausstelle.
Wer? Beachten Sie, wie die erste Zeile ein detailliertes Porträt des Wertkonsumenten für diese Geschichte liefert. Es ist nicht nur ein "Benutzer", es ist ein Benutzer mit klar definierten Merkmalen, die den Kontext für den Rest der Geschichte liefern. Dies liefert einen wesentlichen Kontext, der die Geschichte von einem Benutzer unterscheiden kann, der Online-Banking nutzt, einen Kassierer besucht oder einen bewaffneten Bankräuber besucht, von denen wahrscheinlich nicht jeder die gleichen Elemente des Prozesses wertschätzen möchte.
Was? Die zweite Zeile definiert das Ziel und liefert weiteren Kontext. Aus Sicht des Nutzers ist das Feature schließlich nicht nur „Geld überweisen“; Der Benutzer hat ein bestimmtes Ziel vor Augen. Vielleicht handelt es sich um Überweisungen, ACH, Überweisungen zwischen Bankkonten, Bestechungsgelder am Schalter oder nigerianische 419-Betrugszahlungen.
Warum? Ihre aktuellen Aufzählungszeichen beschreiben nicht, warum ein Benutzer möglicherweise Geld überweisen möchte. Wie eine Funktion implementiert wird, kann je nach Kontext variieren. Indem Sie Ihrer Geschichte eine Warum-Aussage hinzufügen, helfen Sie, die Implementierung so zu steuern und einzuschränken, dass sie dem Benutzer am besten dient. In diesem Fall kann der Kontext nahelegen, dass das Anzeigen der Kontostände vor und nach der Überweisung Teil der Implementierung sein sollte, da es nicht wirklich darauf ankommt, das Geld zu überweisen . Das eigentliche Ziel des Benutzers ist es, einen ausstehenden Scheck abzudecken , und dieser Zweck kann erfüllt werden oder auch nicht, wenn Sie sich zu eng nur auf die Überweisungsfunktion konzentrieren.
Kurz gesagt, eine großartige User Story beschreibt die Aktionen, die ein Benutzer in Richtung eines konkreten Ziels unternimmt, und den Wert, den der Benutzer vom Abschluss der Aktivität erwartet. Es ist sicherlich möglich, andere Arten von User Stories zu schreiben, aber wenn der Großteil Ihrer User Stories keine Wertaussage für einen Wertverbraucher liefert, schreiben Sie wahrscheinlich nur technische Spezifikationen in einem weniger prägnanten Format. Tu das nicht!
Eine Faustregel, die ich gewohnt bin, lautet:
Wird sich mein Benutzer über die Funktionalität X freuen?
Also, in Ihrem Kontext, "wird Ihr Benutzer glücklich sein, wenn er (nur) eine Übertragung konfigurieren kann ?" Ich würde sagen, das wird er nicht. Vielleicht ist das in Ihrem Kontext die „Story“.
Als Nutzer möchte ich Geld überweisen.
Das ist es. Einfach. Vielleicht möchten Sie es anreichern, um bei Ihrer Definition von erledigt zu helfen, wie:
Als Benutzer möchte ich Geld überweisen, eine Überprüfung vor der Bestätigung haben und die Möglichkeit haben, eine Favoritenlieferliste zu verwenden.
Je mehr Details Sie in Ihrer Geschichte haben, desto genauer wird Ihr Produkt sein. In der ersten Geschichte „Ich möchte Geld überweisen“ wird nicht erwähnt, ob Benutzer vor der Bestätigung noch einmal überprüfen können oder ob sie eine Favoritenliste haben (zwei sehr häufige Funktionen), sodass Sie die erste ohne sie liefern und trotzdem mit Ihrem Benutzer besprechen können, dass „ Sie haben die Anforderungen erfüllt“ (tun Sie es nicht, es erzeugt nur Frustration). Benutzerbedürfnisse besser verstehen und einen Punkt erreichen, an dem die Geschichte für beide Seiten klar ist.
Ich weiß nicht, aus welcher Methodik User Stories stammen. Ich kenne die sogenannten Use Cases .
Für den Anwendungsfall unterteilen Sie also jeden Fall in die Schritte, die ein Benutzer ausführen würde, und was das System tun muss, um dies zu unterstützen.
Beispiel
Benutzer zum Überweisen von Geldern zwischen Konten
Ein Teil davon ist, dass dies die Akteure in dieser Interaktion erfasst. Daher kann es wichtig sein, zu unterscheiden, ob der Kunde einen Geldautomaten oder seinen Heimcomputer verwendet. Die Anzeigen wären mit ziemlicher Sicherheit anders. Aber in beiden Fällen findet die Kommunikation mit einem Hintergrundsystem statt. Eine Fallart hat also Benutzer, Geldautomat und System, und die andere Fallart hat Benutzer, Heimcomputer und System. Beachten Sie auch, dass der Heimcomputer ID und PW verwendet, während der Geldautomat die Geldautomatenkarte und die PIN verwendet.
Vergessen Sie nicht den „damit“-Teil der User Story. Es ist wichtig, dass eine User Story eine Beschreibung des Werts enthält, der dem Endbenutzer geliefert wird. Dies hilft technisch nicht versierten Personen, den Grund zu verstehen, warum an einer User Story gearbeitet wird.
Die größere Geschichte, die Sie erwähnt haben, könnte etwa so lauten:
Als Benutzer möchte ich meine Übertragung konfigurieren und einen Empfänger hinzufügen, damit ich eine Übertragung erfolgreich abschließen kann
Nun ist es möglich, dass diese Geschichte ziemlich groß wird und möglicherweise mehr als einen Sprint braucht, um sie zu liefern. In diesem Fall könnte es als Epos beschrieben und dann in kleinere Geschichten zerlegt werden.
Ein guter Ansatz zum Schreiben von Geschichten ist, der INVEST- Mnemonik zu folgen . Dazu gehört auch sicherzustellen, dass Stories klein sind .