it-swarm.com.de

Beziehung zwischen User Story, Feature und Epos?

Als jemand, der noch nicht mit Agilität vertraut ist, bin ich mir nicht sicher, ob ich die Beziehung oder den Unterschied zwischen User Story, Feature und Epos vollständig verstehe.

Nach diesem Frage ist ein Feature eine Sammlung von Geschichten. Eine der Antworten legt nahe, dass ein Feature tatsächlich ein Epos ist. Werden Features und Epen also als dasselbe angesehen, dh als Sammlung verwandter User Stories?

Unser Projektmanager besteht darauf, dass es eine hierarchische Struktur gibt:

Episch -> Features -> User Stories

Und dass grundsätzlich alle User Stories in diese Struktur fallen müssen. Daher müssen alle User Stories unter ein Dach-Feature fallen und alle Features müssen unter ein Epos fallen.

Für mich klingt das unangenehm. Kann jemand bitte klären, wie User Stories, Features und Epics zusammenhängen? Oder gibt es einen Artikel, der die Unterschiede klar umreißt?

117
nivlam

Sie sind eigentlich ein sehr allgemeiner Begriff. Es gibt viele Möglichkeiten, sie zu interpretieren, je nachdem, wie die Menschen sie sehen. Nimm alles, was ich sage, mit einem riesigen Salzkorn.

Normalerweise umfasst ein Epic eine sehr globale und nicht sehr genau definierte Funktionalität in Ihrer Software. Es ist sehr breit. Es wird normalerweise in kleinere User Storys oder Features unterteilt, wenn Sie versuchen, einen Sinn daraus zu ziehen und sie in eine agile Iteration zu integrieren. Beispiel:

episch
- Ermöglichen Sie dem Kunden, sein eigenes Konto über das Web zu verwalten

Feature und User Story sind spezifischere Funktionen, die Sie problemlos mit Abnahmetests testen können. Es wird oft empfohlen, dass sie granular genug sind, um in eine einzelne Iteration zu passen.

Funktionen beschreiben normalerweise, was Ihre Software tut:

Feature
- Bearbeiten der Kundeninformationen über das Webportal

User Stories drücken in der Regel aus, was der Benutzer tun möchte:

ser Story
Als Bankangestellter,
Ich möchte die Kundeninformationen ändern können
damit ich es auf dem neuesten Stand halten kann.

Ich glaube nicht, dass es wirklich eine Hierarchie zwischen den beiden gibt, aber Sie können eine haben, wenn Sie wollen oder wenn es zu Ihrer Arbeitsweise passt. Eine User Story kann eine bestimmte Rechtfertigung für ein Feature oder eine bestimmte Art und Weise sein, dies zu tun. Oder es kann umgekehrt sein. Eine Funktion kann eine Möglichkeit sein, eine User Story zu realisieren. Oder sie können dasselbe bezeichnen. Sie können beides verwenden: User Stories, um zu definieren, was geschäftlichen Wert und Funktion bringt, um die Einschränkungen der Software zu beschreiben.

ser Story: Als Kunde möchte ich mit den beliebtesten Kreditkarten bezahlen
Feature unterstützt die GOV-TAX-02 XML API der Regierung.

Es gibt auch die Frage nach dem Szenario, in dem normalerweise eine Feature-/User-Story ausgeführt wird. Sie werden normalerweise sauber einem bestimmten Abnahmetest zugeordnet. Zum Beispiel

Szenario: Geld abheben
Vorausgesetzt, ich habe 2000 $ auf meinem Bankkonto
Wenn ich 100 $ abhebe
Dann erhalte ich 100 $ in bar
Und mein Guthaben beträgt 1900 $

So definieren wir die Begriffe , in denen ich arbeite . Diese Definitionen sind weit entfernt von einer mathematischen Definition oder einem standardisierten Begriff. Es ist wie der Unterschied zwischen einem rechten oder einem linken Politiker. Es kommt darauf an, wo du lebst. In Kanada kann das, was als rechter Flügel angesehen wird, in den Vereinigten Staaten als linker Flügel angesehen werden. Es ist sehr variabel.

Im Ernst, ich würde mir keine Sorgen machen. Wichtig ist, dass sich alle im Team auf eine Definition einigen, damit Sie sich gegenseitig verstehen können. Einige Methoden wie Scrum definieren sie eher formal, aber wählen Sie die Arbeit für Sie aus und lassen Sie den Rest. Ist nicht agil über Individuen und Interaktionen über Prozesse und Tools und Arbeitssoftware über umfassende Dokumentation?

99

Episch : Eine sehr große User Story, die schließlich in kleinere Storys zerlegt wird.

User Story: Eine sehr allgemeine Definition einer Anforderung, die gerade genug Informationen enthält, damit die Entwickler eine vernünftige Schätzung des Aufwands für die Implementierung erstellen können .

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

Merkmal : Ein Unterscheidungsmerkmal oder eine Fähigkeit einer Softwareanwendung oder Bibliothek (z. B. Leistung, Portabilität oder Funktionalität).

http://en.wikipedia.org/wiki/Software_feature

38
Robert Harvey

Ich warne Sie davor, eine zu starre Hierarchie auf diese Begriffe anzuwenden. Das haben wir in meinem vorherigen Job versucht. Zweimal. Beide Versuche waren unterschiedlich und beide Male stellten wir fest, dass wir uns unnötig eingeschränkt hatten. Die einzige Konstante war die Definition eines ser Story . Aus planerischer Sicht ist eine Geschichte der Grundbaustein eines Projekts. Die größeren Begriffe (Epos, Feature usw.) sind praktisch nur Tags . Tags sind eine einfache Möglichkeit, eine Story als Teil mehrerer Epics und mehrerer Features gleichzeitig existieren zu lassen. Es lohnt sich nicht, strenger zu sein.

Tags funktionieren für Stack Exchange und sie können auch für Sie arbeiten.

28

Wir arbeiten wie folgt mit Epics, Stories und Features

Zu Beginn des Projektzyklus haben wir Epics. Hierbei handelt es sich um sehr hochrangige, fast marketingorientierte Funktionspunkte. Die Art von Dingen, die Sie in einer Zusammenfassung verwenden können, wie z.

Auf unserer neuen Website können Kunden Produkte durchsuchen, Verfügbarkeit und Preise anzeigen, Bestellungen aufgeben und ihre vergangene Bestellhistorie anzeigen

Dies führt zu Epen wie

  • Produktkatalog durchsuchen
  • Verfügbarkeit anzeigen
  • Preise anzeigen
  • Bestellung aufgeben
  • Bestellverlauf anzeigen

Diese werden als User Stories geschrieben (z. B. als Kunde möchte ich den Produktkatalog durchsuchen, damit ich eine fundierte Kaufentscheidung treffen kann), dienen jedoch nur als Starter für zehn für das, was tatsächlich entwickelt und veröffentlicht wird.

Diese Epen werden dann weiter unterteilt in ser Stories. Hierbei handelt es sich um tatsächliche End-to-End-Benutzerreisen, deren Umfang sehr begrenzt ist und die so definiert werden können, dass geschätzt und geplant unabhängig voneinander und entwickelt, getestet und freigegeben in einem Veröffentlichungszyklus.

Die User Story ist die Liefereinheit. Es ist die User Story, die vollständig oder nicht vollständig ist, live geht oder nicht live geht.

Ein Epos kann zu einer großen Anzahl von User Stories führen, nicht alle werden gleichzeitig entwickelt oder veröffentlicht.

Beispielsweise kann das Epos Produktkatalog durchsuchen in unterteilt werden

  • Navigieren Sie zur Kategoriehierarchie
  • Über Schlüsselwort suchen
  • Filtern nach Produktattributen (z. B. Preisspanne, Marke, Farbe, Größe usw.)

Wiederum würde jedes von diesen in dem Format geschrieben sein, z. Als Kunde möchte ich in der Kategoriehierarchie navigieren, damit ich Produkte durchsuchen und einen Drilldown zu dem Produkt durchführen kann, das für meine Anforderungen am besten geeignet ist.

Im Allgemeinen haben wir für die meisten unserer Projekte Dutzende von Epen und Hunderte von Geschichten.

Während wir den Lebenszyklus der Geschichte durchlaufen, kennzeichnen wir diese Geschichten mit Feature s. Beispielsweise werden alle Such- und Bestands- sowie Lager- und Preisberichte beispielsweise mit "Produktkatalog" gekennzeichnet. Bestellberichte, die mit dem Bezahlen mit Kreditkarte zu tun haben, können mit einem "Kreditkarten" -Label gekennzeichnet sein, und diejenigen, die mit dem Bezahlen mit Paypal zu tun haben, werden mit einem "Paypal" -Label gekennzeichnet.

Diese Labels dienen dazu, zusammengehörige Geschichten zu gruppieren, nicht weil es sich um verschiedene Arten der Ausführung derselben Aktivität handelt (z. B. alle Geschichten zur Ortsbestellung), sondern weil sie zusammen veröffentlicht werden sollten.

Zum Beispiel gehört die Geschichte "Bestellung per Kreditkarte aufgeben" zum selben Epos wie die Geschichte "Bestellung per Paypal bezahlen", muss aber nicht zusammen veröffentlicht werden.

Während die Geschichte "Bestellung per Kreditkarte aufgeben", die Geschichte "Rückerstattung auf eine Kreditkarte verarbeiten" und die Geschichte "Kunden die Möglichkeit geben, ihre gespeicherten Kreditkarten auf ihrem Konto zu verwalten" miteinander zu gehören scheinen . Sie wären alle mit dem Funktionsetikett "Kreditkarte" versehen worden. d.h. sie würden alle zur Funktion "Kreditkarte" gehören. Es ist nicht sehr hilfreich, die Möglichkeit freizugeben, eine Bestellung per Kreditkarte aufzugeben, wenn eine Rückerstattung an Paypal nicht möglich ist oder wenn es nicht möglich ist, Ihre gespeicherten Kreditkarten auf Ihrem Konto zu verwalten

Anmerkung: In der Regel also. Dies ist letztendlich eine Geschäftsentscheidung. Wenn die Markteinführungszeit wichtig ist, kann es einen legitimen Grund geben, mit einem dieser Produkte und nicht mit dem anderen live zu gehen.

So dienen Epics dazu, in (verwandte, aber separate) Geschichten zu zerlegen, die unabhängig voneinander entwickelt werden können, während Features dazu dienen, Geschichten zu gruppieren, die zusammen veröffentlicht werden sollen.

Man könnte sagen, dass Epics in User Stories zerfallen und User Stories in Features. Die Geschichten, die zu einem Feature gehören, sind normalerweise epikübergreifend. Daher sind Epics und Features orthogonal und nicht in einer strengen Hierarchie.

In unserer Arbeitsweise verlieren die Epen ihren Zweck, sobald sie in Geschichten zerlegt wurden. Wir schätzen oder planen keine Epics. Wir verfolgen keine Fortschritte bei Epics. Wir veröffentlichen keine Epics. Wir schätzen, planen und verfolgen User Stories. Und wir veröffentlichen Features.

27
Vihung

Ich stimme wie viele Antworten zu, dass es wirklich keine richtigen Antworten gibt, da dies nur Begriffe sind, die je nach dem agilen Camp, auf dem Sie basieren, variiert werden können und Sie definitiv Ihr eigenes Camp zusammenstellen können solange alle in Ihrem Team, einschließlich der externen Stakeholder, verstehen, was sie bedeuten. Es ist nur eine Möglichkeit, Ihre Anforderungen zu organisieren.

Die Antwort, die ich mag, stammt aus Mike Cohns Lager und ist ziemlich einfach.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

  • Epos ist nur eine große Geschichte (hierarchisch)
  • Thema ist nur eine Gruppe von Geschichten (ziemlich ähnlich wie Tag)

Er vermeidet tatsächlich den Begriff "Feature". Ich gehe davon aus, dass dies hauptsächlich darauf zurückzuführen ist, dass es in der traditionellen Wasserfallwelt ein gebräuchlicher Begriff war. Viele Agile Camps verwenden unterschiedliche Begriffe, um die Unterschiede hervorzuheben.

In der Definition Ihres PM befindet sich Feature also irgendwo in der Mitte der Epic-Story-Hierarchie.

Hier ist meine Infografik dieser Definition aus meinem InfoQ-Artikel http://www.infoq.com/articles/visualize-big-picture-agile ;-)

enter image description here

10

Features und Epics sind nicht dasselbe.

  • Ein Feature ist keine User Story.
  • Ein Epos ist eine User Story.
  • Eine User Story kann ein Epos sein.
  • Eine User Story kann viele Funktionen enthalten.
  • Ein Feature kann 1 bis viele User Stories erfüllen.

In den Planungsphasen führen die Diskussionen zu ser Stories, die normalerweise als Epics bezeichnet werden, da der Aufwand für die Implementierung von Lösungen für sie zu groß ist, um sie in wenigen Tagen zu erreichen. Produkt Merkmale werden in dieser Phase identifiziert. Aber das ist nur ein Nebenprodukt der Diskussion. Features werden dann verwendet, um eine Produkt-Roadmap zu planen, die eine separate Diskussion darstellt.

Die Epics werden weitergeführt und diskutiert, was zu ser Stories für jedes Epic führt. Die Features und Epics werden verwendet, um Diskussionen in Backlog Refinement und Sprint Planning Sitzungen anzuregen. Zu diesem Zeitpunkt sind die ser Stories, die aus diesen Diskussionen hervorgehen, verfeinert, priorisiert und in Sprint Planning , zur Implementierung in Sprints aufgenommen.

6
Joey Guerra

Es ist nur eine Problemzerlegung. Sie sind nur Geschichten, außer mit unterschiedlichen Größen.

Ich persönlich bevorzuge es, ihre Größen nicht zu kennzeichnen, aber wenn Sie das tun, ist das auch in Ordnung. Fragen Sie PM, wie die Definition in Ihrem Arbeitsbereich lautet.

5
Martin Wickman

Unsere Organisation hat über 2.000 Entwickler, daher ist die Antwort auf diese Frage wichtig für eine flüssige und klare Kommunikation zwischen den Hunderten von agilen Teams, die wir gemeinsam an unserem gemeinsamen Produkt arbeiten. Für eine sehr kleine Organisation können Sie eine sehr einfache Struktur haben, die nicht einmal hierarchisch sein muss (wie andere geantwortet haben). Für große Organisationen besteht jedoch definitiv ein Bedarf an einer organisierten, skalierten, konsistenten Hierarchie - und darin liegt das Problem, eine Hierarchie aus etwas zu machen, das nicht streng hierarchisch ist.

Im Übrigen bezeichnen wir jede dieser unterschiedlichen Ebenen als "Arbeitselemente". Einige Organisationen (einschließlich einiger der oben genannten Befragten) bezeichnen unterschiedliche Ebenen als Stories oder User Stories (und wir haben dies auch in der Vergangenheit getan), aber wir fanden dies zu zweideutig, sodass wir sie jetzt allgemein als Work Items bezeichnen.

Das Beste, was wir bisher "offiziell" getan haben, ist, Dean Leffingwells SAFe-Struktur von Anlagethemen und Geschäftsepics zu folgen, die an der Spitze (und an zweiter Stelle von oben) der Hierarchie steht, dann Features darunter und schließlich Stories unter Features. Laut Agile stehen Aufgaben immer unter "Geschichten", daher achten wir darauf, diesen Begriff nicht weiter oben wiederzuverwenden. Wir haben uns für SAFe entschieden, um zumindest EINIGE Konsistenz in allen unseren Teams zu erreichen.

Dies reicht jedoch für unsere Bedürfnisse immer noch nicht aus. Wir definieren eine Funktion als eindeutig wertvolles Ergebnis für einen Verbraucher unseres Softwareprodukts (d. H. Wir listen diese Funktionen in unseren Ankündigungen für kommende Versionen auf). Und wir definieren eine Story als eine kleinere Menge an Umfang und Arbeit, die in einem einzigen Sprint von einem einzigen agilen Entwicklerteam geliefert werden kann. Wir beginnen jetzt auch damit, die SAFe-Definition von Anlagethema und Geschäftsepos auf Portfolioebene (und nicht unter dieser Ebene) zu befolgen. Und wir fangen an, unsere ALTEN Definitionen von "Theme" und "Epic" NICHT zu verwenden.

Wir entwickeln uns jetzt langsam in diese Richtung, aber die Räder des Fortschritts schleifen langsam. Wir haben immer noch Probleme damit, die Arbeit in mundgerechte Teile aufzuteilen, damit wir die Arbeit definieren und von mehreren Teams reibungslos erledigen können. Dazu benötigen wir ein "Unter-Feature", das kleiner als ein Feature, aber größer als eine Story ist. Unter-Features können für Arbeitsblöcke verwendet werden, die von JEDEM EINZELNEN Team an einem Feature ausgeführt wurden, oder für Arbeitsblöcke, die von einem EINZELNEN Team zu unterschiedlichen Zeiten (in verschiedenen Sprints oder sogar in verschiedenen Releases) ausgeführt wurden.

Wir brauchen auch mehrere Hierarchieebenen zwischen Feature und Business Epic, aber wir haben diese noch nicht gelöst, außer sie einfach "Themes" zu nennen - was wir wissen, ist nicht der richtige Begriff, da er leicht mit SAFe Investment Themes verwechselt werden kann. Für einige große Projekte (Releases) haben wir bis zu 5-8 verschiedene Hierarchieebenen, von denen jede die Arbeit in immer kleinere Teile aufteilt. Sie können sich diese Themen als "Feature-Gruppen" vorstellen, aber das ist auch nicht unbedingt der richtige Begriff.

Ich denke, es ist wichtig zu versuchen, Begriffe zu verwenden, die Klarheit und nicht Mehrdeutigkeit bieten. Jeder, der sich auf eine Story bezieht, bedeutet die kleinste Arbeitseinheit, die in einem einzelnen Sprint ausgeführt werden kann (mit Ausnahme der Aufgaben unter der Story), und Unter-Feature bedeutet die kleinste Arbeitseinheit an einem Feature, die von einem einzelnen ausgeführt werden kann Mannschaft. Ebenso ist eine Feature-Gruppe eine Hierarchieebene über Feature. Darüber hinaus wird es etwas unscharf, daher nennen wir sie normalerweise nur Themen und erlauben Themen als Eltern und Kinder anderer Themen. Wir versuchen, die Ebenen "Feature", "Sub-Feature" und "Story" auf jeweils eine Ebene zu beschränken (Features sollten keine Kinder anderer Features sein), aber wir sind noch nicht zu 100% erfolgreich darin, dies einzuschränken.

Ich weiß, dass wir "Tags" verwenden könnten, um einiges davon zu organisieren, aber Tags geben uns nicht die organisatorische Arbeitsstruktur, die wir benötigen, um die Arbeit zwischen all unseren Teams zu kategorisieren. Per Definition sind Tags mehrdeutig (viele-zu-viele-Beziehungen), aber eine Hierarchie ist streng eins-zu-viele.

Das Fazit ist, dass dies für uns noch in Arbeit ist und wir immer noch damit zu kämpfen haben. Wenn wir uns jedoch an die SAFe-Definitionen von Thema, Epos, Feature und Story halten, bewegen wir uns in die richtige Richtung!

2
Kirk Bryde

Die Product Backlog-Hierarchie hängt weitgehend von der Produktgröße und ihrer Modularität ab (Anzahl der definierten Produktbereiche).

Für kleine Projekte: Epic> Story ist mehr als genug; und Sie nennen entweder die "Funktion".
Große Projekte könnten sich ähneln wie folgt: Roman> Thema> Epos> Feature> Story

Das beste Beispiel könnte das folgende sein:
Roman = MS Office
Theme = MS Word/MS Excel ...
Episch = Tabellen/Schriftverzeichnis ...
Funktionen = Grundlegendes Tabellen-/Tabellenfarbschema/Operationen mit Zellen ...
Stories (für die Funktion 'Basic Tables' in 'Tables' Epic) = Tabelle hinzufügen/Tabelle zeichnen/Raw einfügen/Spalte einfügen. ..

Was ich für vorteilhaft halte, wenn Sie Ihre eigene Skalierung für den Rückstand definieren, ist:
1. Story : a) immer innerhalb eines Sprints machbar; b) nicht immer für Endbenutzer testbar
2. Episch/Feature: a) passt nicht zu einer Sprintdauer und muss zerlegt werden; b) sollte immer für Endbenutzer testbar sein; c) immer versandfähig, kann monetarisiert werden - ROI dafür berechnen lassen
. Wenn Sie überlegen, Epic hinzuzufügen oder nicht> Feature Abschnitt oder halten Sie sich an Epic> Story: Ich würde empfehlen, Feature nur zwischen Epic und Story einzufügen Wenn: Epic passt nicht einmal zu 1 Release, daher müssen Sie ein versandfähiges Element definieren, das zu 1 Release-Dauer passt .

Hoffe das ist hilfreich.

1
Dmitriy Bibikov