Die Beziehung zwischen User Story, Feature und Epic?

Als jemand, der noch neu in der agilen Entwicklung ist, bin ich mir nicht sicher, ob ich die Beziehung oder den Unterschied zwischen User Story, Feature und Epic vollständig verstehe.

Laut dieser Frage ist ein Feature eine Sammlung von Stories. Eine der Antworten besagt, dass ein Feature eigentlich ein Epos ist. Werden Features und Epen also als dasselbe betrachtet, nämlich als eine Sammlung von zusammenhängenden User Stories?

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

Episch -> Features -> Anwenderberichte

Und dass grundsätzlich alle Benutzergeschichten in diese Struktur fallen müssen. Daher müssen alle User Stories unter ein übergeordnetes Feature fallen und alle Features unter ein Epic.

Für mich klingt das sehr umständlich. Kann mir bitte jemand erklären, wie User Stories, Features und Epics zusammenhängen? Oder gibt es einen Artikel, in dem die Unterschiede klar herausgestellt werden?

Sie sind eigentlich ein sehr allgemeiner Begriff. Es gibt viele Möglichkeiten, sie zu interpretieren, unterschiedlich in der Literatur und wie die Leute sie sehen. Nehmen Sie alles, was ich sage, mit einem großen Körnchen Salz.

Normalerweise umfasst ein Epic eine sehr globale und nicht sehr gut definierte Funktionalität in Ihrer Software. Sie ist sehr breit angelegt. Es wird normalerweise in kleinere User Storys oder Features aufgeteilt, wenn man versucht, sie in einer agilen Iteration zu verstehen und anzupassen. Beispiel:

Epic

  • Dem Kunden die Möglichkeit geben, sein eigenes Konto über das Web zu verwalten

Feature und User Story sind spezifischere Funktionen, die Sie leicht mit Akzeptanztests testen können. Es wird oft empfohlen, dass sie so granular sind, dass sie in eine einzige Iteration passen.

Features beschreiben in der Regel, was Ihre Software tut:

Feature

  • Bearbeitung der Kundeninformationen über das Webportal

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

Benutzergeschichte Als Bankangestellter, möchte ich in der Lage sein, die Kundeninformationen zu ändern so dass ich sie 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 Benutzergeschichte kann eine spezifische Begründung für eine Funktion sein, oder eine spezifische Art und Weise, sie zu tun. Es kann aber auch andersherum sein. Ein Feature kann ein Weg sein, eine User Story zu realisieren. Oder sie können dasselbe bezeichnen. Sie können beides verwenden: User Stories, um zu definieren, was einen geschäftlichen Nutzen bringt, und Feature, um die Einschränkungen der Software zu beschreiben.

Benutzergeschichte: Als Kunde möchte ich mit den gängigsten Kreditkarten bezahlen Feature: Unterstützung der GOV-TAX-02 XML API der Regierung.

Es gibt auch die Frage der Szenarien, die in der Regel eine Art und Weise sind, wie eine Feature/User Story ausgeführt wird. Sie lassen sich in der Regel sauber auf einen spezifischen Akzeptanztest abbilden. Zum Beispiel

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

So definieren wir diese Begriffe wo ich arbeite. Diese Definitionen sind weit von einer mathematischen Definition oder einem standardisierten Begriff entfernt. Es ist wie der Unterschied zwischen einem rechten und einem linken Politiker. Es kommt darauf an, wo man lebt. Was in Kanada als rechts gilt, kann in den Vereinigten Staaten als links angesehen werden. Es ist sehr variabel.

Im Ernst, ich würde mir nicht zu viele Gedanken darüber machen. Wichtig ist, dass sich alle im Team auf eine Definition einigen, damit man sich gegenseitig verstehen kann. Einige Methoden wie Scrum neigen dazu, sie formeller zu definieren, aber wählen Sie aus, was für Sie funktioniert und lassen Sie den Rest. Geht es bei agilen Methoden nicht um Individuen und Interaktionen statt Prozesse und Werkzeuge und funktionierende Software statt umfassender Dokumentation?

Kommentare (7)

Episch: Eine sehr umfangreiche Benutzergeschichte, die schließlich in kleinere Geschichten unterteilt wird.

User Story: Eine sehr detaillierte Definition einer Anforderung, die gerade genug Informationen enthält, damit die Entwickler eine vernünftige Schätzung des Implementierungsaufwands vornehmen können.

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

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

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

Kommentare (0)

Es ist nur eine Problemzersetzung. Es sind einfach Geschichten, nur in unterschiedlichen Größen.

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

Kommentare (0)