Was ist der Unterschied zwischen einer User Story und einem Feature in Agile Terminologie? [geschlossen]

Question

Ich denke, ein Merkmal, so etwas wie „Kreditkartenautorisierung“ sein könnte, während ein Benutzer Geschichte sein kann.

„Kreditkarte für paypal genehmigen“

So ist eine User Story eine Teilmenge einer Funktion?

Answer 1

Ja, so etwas wie eine Teilmenge. Dieser Artikel ist gut zu lesen:
Eigenschaften vs Geschichten

Auszug:

  

Ich erkannte, dass ich heute nicht gemacht hatte   explizit der Unterschied in meinem Kopf   zwischen Features und Geschichten und es ist   ein wichtiger Unterschied. Im Wesentlichen,   ein Merkmal ist eine Gruppe von Geschichten, die   ein Paket von verwandt sind und liefern   Funktionalität, die Endverbraucher würden   im Allgemeinen erwartet, dass alle auf einmal zu bekommen.   Zum Beispiel Redimensionierung Inline-Tabelle ist   ein Merkmal (Anmerkung: Dies ist die Fähigkeit,   ziehen Tabellen, Zeilen, um die Größe und   Spalten - versuchen Sie es in Word). In dem   ersten Durchgang, dann würden Sie wahrscheinlich ein   einstöckigen für Inline-Größenanpassung   Tabellen, aber es wäre zu groß sein,   schätzen. So Sie brechen sie in   drei Geschichten, Größe der Spalten ändern, die Größe   Zeilen und die Größe der Tabelle selbst.

Answer 2

Nach Kent Beck und Martin Fowler Geschichten und Eigenschaften sind Synonyme:

  

Eine User Story ist ein Stück   Funktionalität (einige Leute nutzen die   Wort Merkmal ), die von Wert ist   der Kunde.

Was für ein rufen Sie Merkmal in der Regel als bezeichnet wird Thema oder epische . Themen und Epen werden verwendet, um Gruppen User Stories, um größere Feature-Sets, der Sinn auf ihrem eigenen.

Von einer semantischen Sicht: Merkmal ist ein Teil des Systems Sie versuchen zu bauen, ist User Story eine Art und Weise, dass ein Teil zu beschreiben.

---

Korrektur:

Wie Pascal hat darauf hingewiesen - ich vielleicht die wahre Bedeutung von „Feature“ verpaßt in diesem Zitat ( „Feature“ bezieht sich offensichtlich auf Funktionalität) Abgesehen davon, ich denke immer noch, dass man diese Worte verwendet (Funktion und Benutzer Geschichte) als Synonyme in vielen Kontexten (vs. „ich auf dieser Geschichte gerade arbeite“ „zu dieser Funktion arbeite ich“), da, wie Pascal sagte, ist eine User Story eine Möglichkeit, eine Funktion zu erfassen. Was bedeutet, dass es eine 1: 1-Beziehung zwischen diesen beiden. Und, wie aus meiner Bemerkung über die Semantik zu sehen ist, das ist, wie ich es verstehe wirklich.

Answer 3

gar nicht ..

Eine User Story stellt kleine Teile des Geschäftswerts. Also es ist wirklich schwer zu sagen, wenn eine User Story eine Teilmenge eines Merkmals ist oder eine Funktion ist eine Teilmenge von einer User Story (auch bedenken, dass die User Storys in der Regel von den Beteiligten geschrieben werden, die nicht genau zu wissen, neigt dazu, was sie wollen ... :))

Wenn Sie also die Empfehlung der agilen folgen kurz, um die Geschichten zu halten Sie auf dem „besten“ Szenario fallen würde, dass der User Story ist eine Teilmenge des Merkmals zu sein.

Allerdings, wenn Ihre Stakeholder lange Geschichten zu schreiben, würde jede Geschichte ein paar Funktionen hat (wenn es eine gute Kommunikation zwischen dem Team und den Beteiligten wird dies nicht das Team, die Geschichten in der kleinen brechen passiert da)

Answer 4

Merkmale sind das, was ein System tut. User-Geschichten sind nur eine Möglichkeit unter anderen Funktionen zu erfassen.

Answer 5

Ich kam gerade über dieses Thema, als ich für verschiedene Ideen „mit mehreren Rollen für ähnliche Anforderungen“ gesucht.

Ich denke, dass ein Merkmal als Behälter für in Verbindung stehende Geschichten hilft, die Anforderungen bei der Priorisierung, weil Akteure in der Regel ihre Bedürfnisse als abhängige Geschichten erzählen. In einem aktuellen Projekt, sagte mir der Kunde wie folgt

Ein Mitglied kann Nachrichten an den Administrator senden Admin kann Nachrichten an alle Mitglieder schicken Die Mitglieder können sich gegenseitig Nachrichten senden

Wenn ich diese Anforderungen zu sehen, ich weiß, dass, sollten wir ein System implementieren Menschen zu ermöglichen, eine Nachricht zu senden, und wir sollten Prüfungen hinzufügen, damit wem was zu tun ist.

Und ich weiß auch, dass diese Anforderungen, wie einige andere implizite Anforderungen haben die Nachrichten als lesen, die kamen, deren Anordnung kann als Spam Einstellung und etc.

So ich versuche, diese Anforderungen als

umformulieren

Als Mitglied oder Admin, ich Nachrichten an andere Personen senden. Als Mitglied oder admin, kann ich Nachrichten lesen, die mir geschickt wurden.

Und als die Annahmekriterien, i angeben, im Detail, die die senden kann.

Dann rufe ich alle diese Dinge als „Private Messaging“ -Funktion, so dass bei später einige Zeit, wenn der Kunde entscheidet, dass es zusätzliche Kosten ist, kann er sagen „einfach das Private Nachrichten-Sache fallen“, und ich kann entfernen alle von ihnen aus dem Rückstand.