Ich bin Entwickler in einem Scrum-Team und es fällt mir schwer, das Endziel zu verstehen und mich darin einzufühlen, wenn Geschichten mit „Wie das System“ beginnen. Diese Geschichten sollten einfach sein, weil ich als Entwickler in der Lage sein sollte, die Akzeptanzkriterien zu erfüllen, aber ich finde, dass sie mir nach der Überprüfung häufig zurückgeschoben werden, weil die Bedürfnisse einiger Stakeholder nicht erfüllt wurden.
Als Beispiel gab es eine solche Geschichte, die eine Reihe von Grenzfällen beinhaltete und von Tag zu Tag an Komplexität zu gewinnen schien. Als ich tiefer nachforschte, um zu verstehen, warum wir diese Grenzfälle abdecken, stellte sich heraus, dass Funktionen für einen Stakeholder und Funktionen für einen völlig anderen Stakeholder erstellt wurden. Was wahrscheinlich viele Kommunikationswege zwischen dem PM und mir hätte sparen können, wenn sie als zwei Geschichten definiert worden wären.
Kurz gesagt, sollten wir es vermeiden, Geschichten zu verwenden, die mit „Wie das System“ beginnen?
Ja. Es ist schlecht, „das System“ als Benutzer in Geschichten zu verwenden.
Der springende Punkt des "als ... ich will ... damit ..."-Formats ist es, dem Entwickler einen Einblick in den Grund für die angeforderte Funktion zu geben. Dies sollte es ihnen ermöglichen, die Lücken in den Spezifikationen zu füllen.
Anstatt "den Button rot zu machen", hätten Sie "als Kunde möchte ich, dass der Kaufen-Button rot ist, damit ich ihn leicht identifizieren und leicht anklicken kann".
Wenn Sie also die Anfrage erhalten und sehen, dass der Hintergrund unter Bedingung X ebenfalls rot ist. Sie gehen nicht einfach blind vor und machen die Schaltfläche unsichtbar.
Sie sollten darauf bestehen, dass der BA/PM/SM oder wer auch immer eine Liste der Benutzer des Systems erstellt und dass jede Geschichte einen der Benutzer aus dieser Liste verwendet.
User Stories sind ein agiler Ansatz für Anforderungen, die den Wert des Endbenutzers betonen.
Alle User Stories sind in der Sprache des Endbenutzers geschrieben, so dass sie von einer nicht-technischen Person verstanden werden können, die den Wert, den die Story liefert, sofort „versteht“.
Der Grund dafür ist, dass es den nicht-technischen Endbenutzern hilft zu verstehen, welche Fortschritte das Team macht, und die Arbeit zu priorisieren.
Etwas, das mit „As the system…“ beginnt, ist keine User Story. Es ist eine technische Aufgabe, die im User-Story-Format verpackt ist.
Wo passen also technische Aufgaben hinein?
Typischerweise erstellt der Product Owner User Stories, die den Wert des Endbenutzers darstellen. Sie priorisieren sie und präsentieren sie dann dem Team als Teil der Backlog-Verfeinerung oder der Sprint-Planung .
Das technische Team kann oft nicht auf eine User Story schauen und genau verstehen, was es liefern muss. Denn eine User Story ist eine Einladung zu einem Gespräch . Der Product Owner führt das technische Team durch die User Story. Dabei unterteilt das technische Team die Geschichte oft in eine oder mehrere technische Aufgaben . Diese technischen Aufgaben müssen von den Endbenutzern nicht verstanden werden, können in einem Nicht-Story-Format geschrieben werden und können hochtechnischer Natur sein.
Angenommen, ich habe die folgende User Story:
Als erstmaliger Benutzer der Website möchte ich mich registrieren, damit ich Zugriff auf die Website erhalten kann
Das technische Team könnte sich diese Geschichte ansehen und sie in eine Reihe technischer Aufgaben aufschlüsseln:
Erstellen Sie eine Benutzertabelle in der Datenbank
Gestalten Sie die Registrierungsseiten
Validierung zu Eingabefeldern hinzufügen
...usw.
Es sollte wenige oder keine technischen Aufgaben geben, die sich nicht auf eine Geschichte beziehen. Sogar sowas wie:
Richten Sie die Entwicklungsumgebung ein
kann in die erste User Story integriert werden, die Endnutzerwert liefert.
Das Ziel dieses Ansatzes ist:
User Stories sollten vertikale Slices sein, die einem Endbenutzer einen Mehrwert bieten. Das System ist eine hirnlose Maschine, die sich nicht um den Wert kümmert, daher helfen Ihnen Benutzergeschichten, die mit „als System“ beginnen, im Allgemeinen nicht dabei, zu verstehen, warum wir etwas aus der Perspektive des Unternehmens oder eines Kunden tun.
Es wird also Geschichten geben, in denen Sie „als System“ schreiben, die zunächst technisch sehr komplex erscheinen mögen, oder 100 % Backend, die keinen greifbaren Wert für den Endbenutzer haben. Schauen Sie genauer hin und versuchen Sie wirklich zu verstehen, warum wir wollen, dass das System etwas tut oder sich auf eine bestimmte Weise verhält, denn das System ist immer darauf ausgelegt, irgendwann mit einem Menschen zu interagieren und diesem Menschen zu helfen, irgendeine Art von Entscheidung zu treffen.
Ja, als Product Owner, der ständig User Stories für ein SEHR großes Projekt schreibt, das in unserer Branche als agiler Vorreiter gilt, kann ich sagen, dass wir niemals „Als System …“ schreiben würden.
Eine User Story ist eine Geschichte über einen Benutzer . Wenn Sie die Logik durchgehen, warum etwas benötigt wird, gibt es irgendwo darunter immer einen Menschen, und um diese Person geht es in der Geschichte. Selbst in Fällen, in denen Sie eine Geschichte über einen externen Dienst schreiben, der Daten mit uns im Backend teilen muss, gibt es zwangsläufig irgendwo einen Benutzer dieses Dienstes.
Ich bin ziemlich zuversichtlich, weil unser Projekt als Ganzes viel Mühe in die Praxis gesteckt hat, nützliche User Stories zu erstellen, und wir Product Owner regelmäßig unsere Stories einem Peer-Review unterziehen. Wenn einer von uns "Als System ..." schreiben würde, würde ich garantieren, dass er in der Peer-Review-Sitzung in Stücke gerissen wird. Schlimmer noch, wenn die Geschichte tatsächlich Funktionalität für zwei verschiedene Kunden liefern würde, würden sie noch schlimmer in Stücke geschnitten werden. Eine bewährte Vorgehensweise besteht darin, die Geschichte auf das kleinste nützliche vertikale Segment zu reduzieren, und sie sollte sich immer auf die Bedürfnisse eines Benutzers (oder einer Klasse von Benutzern) konzentrieren, die klar definiert sind.
Auch die Tatsache, dass Ihre Geschichte „von Tag zu Tag an Komplexität zunahm“, deutet darauf hin, dass bei Ihrem Story-Grooming-Prozess etwas dysfunktional vor sich geht. Eine User Story sollte klein gehalten werden, um eine bessere Verfolgung der Teamgeschwindigkeit, eine einfachere Planung und (in einer idealen Welt) etwas Lieferbares (wenn auch kleines) in jedem Sprint zu ermöglichen. Eine User Story sollte sich auf einen möglichst kleinen Benutzer konzentrieren und vom Ersteller der Story losgelassen werden, sobald die Entwicklung beginnt. Ich musste die Akzeptanzkriterien schon während des Fluges ändern (während eine Geschichte in der Entwicklung ist), aber ich tue dies nur sehr ungern und werde dem Entwickler sehr deutlich machen , warum dies getan werden muss. Wenn etwas Neues auftaucht, das die Dinge ändert, nachdem die Geschichte im Gange ist, wird es in 99 % der Fälle einfach zu einem neuen Element im Backlog.
Alles in allem denke ich wirklich, dass ihr wahrscheinlich noch einmal überdenken solltet, wie ihr an die Story-Erstellung, Story-Grooming und Planung herangeht.
Kurz gesagt, nicht unbedingt, aber es hat einen "schlechten Geruch".
Es hört sich so an, als ob das Grundproblem darin besteht, dass sie möglicherweise schlecht geschrieben und, was noch wichtiger ist, schlecht verstanden werden. Es hört sich so an, als müsste die Kommunikation über den Zweck und das Ziel dieser Elemente verbessert werden.
Der Sinn der Aussage „Als … möchte ich“ besteht darin, zu zeigen, wem die Geschichte hilft, und dem Entwickler Informationen darüber zu geben, wen er bitten muss, sie fertigzustellen. „Als System“ zu sagen impliziert, dass sich das System (wirklich?) darum kümmert und tatsächlich als Teil der Anforderungen lösungsorientiert ist (Sie gehen davon aus, dass dies eine Art nicht interaktives Teil ist).
Sie müssen darüber nachdenken, wem Sie helfen müssen, die Geschichte aus ihrer Sicht schreiben und dann darüber nachdenken, wie Sie sie lösen können.
Ich würde argumentieren, dass alles davon abhängt, was das Ziel dieser speziellen Anforderung ist. Es gibt einige Fälle oder Anforderungstypen, die wir hier berücksichtigen könnten, z.
Als Randbemerkung würde ich sagen, dass Ihre Frage ein sehr breites Thema berührt. Verwenden Sie einen Ansatz zur Dokumentation von Anforderungen, der Klarheit in Ihren Entwicklungsprozess bringt, Verwirrung bei allen beteiligten Parteien reduziert und keinen unnötigen Overhead mit sich bringt. Ich habe hier absichtlich nicht explizit erwähnt, dass der Fokus auf die Dokumentation des Werts gelegt wird – nicht weil es unwichtig ist, sondern weil die Fokussierung auf den Benutzerwert auf verschiedene Weise erreicht werden kann und den „damit“-Teil der User Story dokumentiert und „als System“ vermeidet. Geschichten, ist nur eine davon.
Ja, das ist einfach falsch, ich würde es als Anforderungsphasenfehler ablehnen.
Betrachten Sie das Problem, das User Stories anzugehen versuchen – unerfahrene Leute, die versuchen, Use-Cases zu schreiben, die nur Funktionen aufzählen und den Geschäftszweck hinter der Anforderung nicht berücksichtigen.
Betrachten Sie dann das Problem, das Anwendungsfälle zu lösen versuchen - unerfahrene Leute, die versuchen, funktionale Anforderungen zu schreiben, indem sie nur Funktionen aufzählen und den Geschäftszweck hinter den Anforderungen nicht berücksichtigen ...
Es ist nicht so, dass ein Akteur kein Computersystem sein kann, es ist so, dass die Kennzeichnung nicht mit einem realen Geschäftszweck verbunden ist.
Mike Robinson