Sollten gemeinsame Funktionalitäten als sehr ähnliche Geschichten in jedem Kontext wiederholt werden, in dem sie benötigt werden?

Nehmen wir an, für ein System gibt es mehrere Geschichten, die sich durchgehend wiederholen würden, jedoch in unterschiedlichen Kontexten.

zB Suche

„Als [Rolle einfügen] möchte ich eine Datenliste durchsuchen, damit ich leicht finde, wonach ich suche.“

Dasselbe gilt für das Anmelden, Filtern, Bearbeiten des Profils usw. All dies sind Geschichten, die jede Rolle ausführen müsste, um ein bestimmtes Epic abzuschließen (oder sind Epics an sich).

Ich bin mir nicht sicher, ob ich all diese Geschichten für jede Rolle wiederholen soll (und sie als „Anmeldethema“ oder „Suchthema“ kennzeichnen soll) oder ob ich EIN separates „Suchepos“ erstellen soll, auf das ich mich beziehen würde, wann immer ich es tun würde müssen (was natürlich User Stories zum Suchen enthält).

Gedanken?

Ich denke, Sie müssen sich fragen, warum all diese Dinge in Ihrem speziellen Umfeld drastisch unterschiedliche Aktivitäten sind. Warum ist ein Login nicht gleich ein Login? User Stories sind keine Spezifikationsdokumente!

Antworten (4)

Ein Benutzer des Systems kann gleichzeitig mehrere Rollen haben, die eine Hierarchie von einer sehr generischen Rolle zu einer spezifischen Rolle bilden.
Ist ein Benutzer beispielsweise als Administrator angemeldet, hat er zu diesem Zeitpunkt auch die Rolle „Angemeldeter Benutzer“ und „Benutzer“.

Wenn Sie eine Reihe von Geschichten haben, die bis auf die in den Geschichten erwähnte Rolle gleich sind, sollten Sie zuerst nach einer allgemeineren Rolle suchen, die all diese Geschichten auf eine einzige reduzieren kann.
Sie möchten nicht ein Dutzend Geschichten „Als X-Rolle möchte ich mein Profil bearbeiten, um es auf dem neuesten Stand zu halten“, wenn Sie eine einzelne „Als eingeloggter Benutzer möchte ich bearbeite mein Profil, um es auf dem neuesten Stand zu halten" für ungefähr die gleiche Komplexität wie eine einzelne Geschichte aus dem Set.

Wenn sich die Geschichten nicht ähnlich genug sind, um unter einem einzigen Benutzer zusammengefasst zu werden, zum Beispiel weil die Ziele unterschiedlich sind, dann hängt es von ihrer Beziehung zu anderen Geschichten im Projekt ab, ob und zu welchem ​​Thema oder Epic sie gehören.

Wenn der einzige Unterschied in der Geschichte die Rolle ist und die Rollen keine unterschiedlichen Suchfähigkeiten oder Benutzeroberflächen benötigen, verwenden Sie einen allgemeinen Begriff, der „alle Rollen“ bedeutet, und schreiben Sie eine Geschichte. ("Als eine Person, die mit dem System interagiert" vielleicht)

Wenn einige Rollen unterschiedliche Suchfunktionen oder Benutzeroberflächen benötigen, schreiben und implementieren Sie zuerst die generische Story und schreiben Sie dann eine oder mehrere zusätzliche Storys, um die zusätzlichen Funktionen abzudecken. ("Als Systemadministrator möchte ich versteckte Daten durchsuchen, damit ich ..." oder "Als fortgeschrittener Benutzer möchte ich nach mehreren Parametern suchen, damit ich schneller finde, wonach ich suche")

Ich beschäftige mich gerade mit etwas ähnlichem in einem Projekt.

Vergessen wir nicht, dass Agile im Kern ein Iterationsprozess ist. Daher sollten Sie sich nicht verpflichtet fühlen, sich mit diesen Geschichten im Voraus auf einen Ansatz festzulegen.

Ich würde argumentieren, dass die Fähigkeit, nach x zu suchen, die richtige Geschichte ist, und die Fähigkeit, nach y zu suchen, eine andere. Sie müssen nicht für jeden Benutzer eine bestimmte Geschichte haben, um jede Suche durchzuführen. Das ist eine Geschichte, die diese Suchregeln basierend auf dem Benutzertyp definiert.

Beim Unboxing muss dann möglicherweise jemand (Sie?) mit Ihren Entwicklern in die Sache einsteigen, um die Geschichte bei Bedarf in Aufgaben aufzuteilen.

Vertraue hier auf deinen Instinkt und probiere etwas anderes aus, wenn es nach ein paar Sprints keine Trittfrequenz bekommt!

Wenn nur die Rolle, die die Aktion ausführt, unterschiedlich ist und die Aktionen (Hinzufügen, Suchen, Bearbeiten usw.) sowie der Kontext (Benutzerprofil, Rechnungen usw.) der Aktionen gleich sind, dann sprechen Sie von nur einem Benutzer Geschichte.

Sie können einen breiteren Namen für diese Rollen verwenden oder einfach alle eingeben, wenn es nicht zu viele sind. zB Als Staff User möchte ich nach ABC suchen, damit ich XYZ kann. Oder vielleicht wollen wir als IT-Mitarbeiter oder Management-Mitarbeiter ABC, damit wir XYZ können.

Rollen müssen keine tatsächlichen Rollen in Ihrem System darstellen.

Es hilft auch, wenn Ihre Geschichten die INVEST- Eigenschaften haben, wenn sie zur Auswahl bereit sind.