it-swarm-eu.dev

Was ist der Unterschied zwischen User Stories und Features?

Beim Spielen mit icescrum wurde mir klar, dass ich den Unterschied zwischen User Stories und User Features nicht verstehe.

Kann jemand den Unterschied erklären?

25
BЈовић

Ein Feature ist ein eigenständiges Funktionselement, das dem Unternehmen Funktionen bieten kann.

Eine Story ist ein kleiner Aspekt einer Funktion, mit der Sie Feedback von Ihren Stakeholdern erhalten und herausfinden können, ob Sie etwas falsch machen.

Eine Funktion könnte beispielsweise "Benutzern erlauben, Artikel zu kommentieren" sein. Die mit dieser Funktion verbundenen Geschichten könnten dann sein:

  • kommentare speichern
  • filterkommentare für unhöfliche Wörter
  • begrenzen Sie Kommentare auf 400 Zeichen und geben Sie Feedback an Benutzer
  • fügen Sie Captchas hinzu, um zu verhindern, dass Bots die Site spammen
  • nutzern erlauben, sich über die Google-ID anzumelden

usw.

In jeder Phase können wir dann Feedback erhalten, ob die Richtung, in die wir gehen, nützlich ist.

Einige Teams machen sich nicht die Mühe, Features in Geschichten aufzuteilen. Das ist ok.

23
Lunivore

Features == User Stories.

Die Aussprache wird durch die gegebene Agile Methodik diktiert.

Die verschiedenen Methoden verwenden unterschiedliche Begriffe, um auf Funktionen zu verweisen. Es ist Sache des Teams, zu entscheiden, welche Methodik oder Terminologie verwendet werden soll. Extreme Programming (XP) verwendet die Begriffe User Stories oder Stories, um Features darzustellen. Scrum verwendet Product Backlog, um eine Funktionsliste zu beschreiben. Feature-Driven Development verwendet Feature. und DSDM verwendet die Anforderung. In ähnlicher Weise gibt es verschiedene leichtgewichtige Versionen des Unified Process oder Agile UP, die die Anforderung und/oder den Anwendungsfall verwenden, um inkrementell bereitstellbare Funktionen zu definieren. Letztendlich ist das Ziel dasselbe - regelmäßig in kleinen Schritten und eher früher als später Geschäftswert zu liefern.

16
Aaron McIver

A ser Story ist eine informelle Aussage in der Sprache des Kunden, die die Absicht von etwas erfasst, das der Kunde erreichen möchte. Sie können sich ein ser Story als informelle Anforderungserklärung vorstellen.

A Software Feature ist ein charakteristisches Merkmal der Software, das zum Gesamtdesign und zur Funktionalität der Software beiträgt.

Einige wichtige Überlegungen:

  • Ein Story kann ein Feature beschreiben, aber ein Feature beschreibt niemals ein Story.
  • A Story beschreibt möglicherweise nicht direkt ein Feature.
  • A Story kann die Aufnahme einer Reihe von Features bedeuten.
  • Ein Feature - entweder einzeln oder als Mitglied einer Sammlung von Features - kann die Absicht eines Story erfassen.

In diesem Sinne neige ich dazu, Geschichten als Beschreibungen zu betrachten. Grundsätzlich informelle Anforderungen, die mir sagen, was der Kunde will. Auf der anderen Seite stelle ich mir eher eine Spezifikation vor, die mir sagt, wie ein System funktionieren soll, um die Kundenanforderungen zu erfüllen.

7
S.Robins

Die beiden Begriffe sind eng miteinander verbunden, es gibt jedoch einige Unterschiede.

Erstens kommen sie aus verschiedenen Bereichen. Der Begriff "Feature" ist ein ziemlich allgemeiner Begriff für einen Teil der Funktionalität einer Software, während "User Story" erfunden wurde und eigentlich nur im Kontext der agilen Softwareentwicklung verwendet wird.

In der Praxis fallen sie sehr oft zusammen, da eine User Story darin besteht, eine bestimmte Funktion zu implementieren.

In einigen Situationen können sie jedoch unterschiedlich sein:

  • Oft ist eine Funktion zu viel Arbeit für eine einzelne User Story. User Stories sollten nicht zu groß sein (in der Regel nicht länger als ein paar Tage, maximal 1-2 Wochen Arbeit). Offensichtlich sind viele Funktionen viel größer. In diesem Fall wird eine Funktion in vielen User Stories implementiert. Einige Leute verwenden "Epen", um User Stories zu gruppieren. In diesem Fall könnte man sagen, dass die Funktion ein Epos ist.
  • Nicht funktionale Anforderungen (Leistung, Sicherheit, Kompatibilität usw.) können auch als User Stories behandelt werden (obwohl dies nicht allgemein akzeptiert wird). In diesem Fall wird das Ergebnis der User Story normalerweise nicht als Feature bezeichnet (es sei denn, Sie nennen "Unsere Anwendung stürzt selten ab").
3
sleske