Ich denke, eine Funktion könnte etwas wie "Kreditkartenautorisierung" sein, während eine User Story "Autorisierung der Kreditkarte für Paypal" sein kann.Was ist der Unterschied zwischen einer User Story und einem Feature in der agilen Terminologie?
Also, ist eine User Story eine Teilmenge einer Funktion?
Ja, so etwas wie eine Teilmenge. Dieser Artikel ist gut zu lesen:
Features vs Stories
Auszug:
mir heute klar, dass ich explizit den Unterschied in meinem Kopf zwischen Funktionen, die nicht gemacht hatte und Geschichten und es ist ein wichtiges Unterschied. Im Wesentlichen ein Feature ist eine Gruppe von Geschichten, die sind verwandt und liefern ein Paket von Funktionalität, die Endbenutzer würden im Allgemeinen erwarten, alle auf einmal zu erhalten. Zum Beispiel ist Inline-Tabelle Größenanpassung ein Feature (Hinweis: das ist die Fähigkeit zu ziehen, um die Größe von Tabellen, Zeilen und Spalten - versuchen Sie es in Word). In der ersten Pass haben Sie wahrscheinlich eine Single Story für Inline-Größenanpassung von Tabellen, aber es wäre zu groß, um schätzen. Also zerlegen Sie es in drei Geschichten, Größe Spalten, Größe Zeilen und Größe der Tabelle selbst.
Werfen Sie einen Blick auf Diego's Beitrag auf dieser Seite, eine erfrischende Perspektive. –
Danke ... Das ist ein guter Link, den Sie auch gepostet haben. Jedes Mal, wenn ich die Erfahrung von jemandem lese, der darüber nachdenkt, was er macht, bringt mich das auf eine andere Art und Weise zum Nachdenken. Das ist einer der Gründe, warum ich diese Seite für erstaunlich halte .. Sie lernen immer weiter –
Genaue Empfindungen hier :) –
Mitnichten ..
Eine User Story stellt kleine Teile des Geschäftswerts. Es ist also wirklich schwierig zu sagen, ob eine User Story eine Teilmenge einer Funktion ist oder ein Feature eine Teilmenge einer User Story ist (bedenken Sie auch, dass die User Stories in der Regel von Stakeholdern geschrieben werden, die nicht genau wissen was sie wollen ... :))
Also, wenn Sie der Empfehlung von agile folgen, um die Geschichten kurz zu halten, würden Sie auf das "beste" Szenario fallen, das die User Story eine Teilmenge der Funktion ist.
Wenn Ihr Stakeholder jedoch lange Geschichten schreibt, hätte jede Geschichte ein paar Features (wenn es eine gute Kommunikation zwischen dem Team und den Stakeholdern gibt, wird dies nicht passieren, da das Team die Geschichten in kleine aufteilen wird)
nach Kent Beck and Martin FowlerGeschichten und Funktionen sind Synonyme:
eine User Story ist ein Stück Funktionalität (einige Leute benutzen das Wort Feature) das ist der der Kunde wert.
Was Sie rufen eine Funktion ist in der Regel als Thema oder Epos bezeichnet. Themen und Epen werden verwendet, um User Stories zu größeren Feature-Sets zu gruppieren, die alleine sinnvoll sind.
Von einer eher semantischen Sicht: Feature ist ein Teil des Systems, das Sie versuchen zu bauen, User Story ist eine Möglichkeit, diesen Teil zu beschreiben.
Korrektur:
Wie Pascal hat darauf hingewiesen - ich vielleicht die wahre Bedeutung von „Feature“ in diesem Zitat („Feature“ an Funktionalität bezieht sich natürlich) verpaßt Abgesehen davon, ich denke immer noch, dass man kann diese Wörter (Feature und User Story) in vielen Kontexten synonym verwenden ("Ich arbeite an dieser Story" vs. "Ich arbeite an dieser Funktion"), da, wie Pascal sagte, eine User Story ist eine Möglichkeit, ein Feature zu erfassen. Was bedeutet, dass es eine 1: 1 Beziehung zwischen diesen beiden gibt. Und wie ich aus meiner Bemerkung zur Semantik ersehen kann, verstehe ich das so.
"Was man ein Feature nennt, wird normalerweise als Thema oder Epos bezeichnet", gefällt mir diese Analogie. :) –
Ich habe meinen Kommentar aus Versehen gelöscht, so dass ich es aus Gründen der Klarheit zurückstellen: Sind Sie sicher, dass einige Leute das Wort Feature nicht für Funktionalität verwenden? –
BTW, ich mag das Addendum auch, wenn ich einen anderen Standpunkt habe (persönlich sehe ich die Beziehung als * user story => feature * ohne strikte Äquivalenz). –
Eigenschaften sind, was ein System tut. User Stories sind nur eine Möglichkeit, Features zu erfassen.
Mein Punkt, Pascal;) –
Ich bin gerade auf dieses Thema gestoßen, als ich nach verschiedenen Ideen zur "Verwendung mehrerer Rollen für ähnliche Anforderungen" suchte.
Ich denke, dass eine Funktion als Container für verwandte Geschichten hilft, die Anforderungen zu priorisieren, weil Stakeholder ihre Bedürfnisse normalerweise als abhängige Storys angeben. In einem aktuellen Projekt, sagte mir der Kunde als
Ein Mitglied folgt können Nachrichten an den Admin Admin senden Nachrichten an alle Mitglieder senden können Mitglieder Nachrichten miteinander
senden kann, wenn ich diese Anforderungen zu sehen, i Wissen Sie, dass wir ein System implementieren sollten, das es Menschen ermöglicht, eine Nachricht zu senden, und wir sollten Prüfungen hinzufügen, um zuzulassen, wem was zu tun ist.
Und ich weiß auch, dass diese Anforderungen einige andere implizite Anforderungen haben wie die Nachrichten zu lesen, die kamen, zu veranlassen, kann als Spam Einstellung und etc.
Also ich versuche, diese Anforderungen als
umformulierenAls Mitglied oder Administrator kann ich Nachrichten an andere Personen senden. Als Mitglied oder Administrator kann ich Nachrichten lesen, die an mich gesendet wurden.
Und als Annahmekriterien, ich im Detail angeben, wer an wen senden kann.
Dann rufe ich all diese Dinge als "Private Messaging" -Funktion, so dass zu einem späteren Zeitpunkt, wenn der Klient entscheidet, dass es ein Aufpreis ist, er sagen kann "nur die private Messaging-Sache fallen lassen" und ich kann Entfernen Sie alle aus dem Rückstand.
Ein agiler Benutzerspeicher muss personenzentriert sein. Zum Beispiel: "Als Kontoinhaber kann ich meine Kreditkarte für Paypal autorisieren." Danach sollten Sie detaillierte Erfolgskriterien erhalten. – Jay
Es gibt UML-Modelle, um die Beziehungen von Stories, Backlogs usw. in http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile- zu erklären. Unternehmen-pdf.pdf – Fuhrmanator