Quelle est la différence entre une histoire d'utilisateur et une fonction dans la terminologie Agile? [fermé]

Question

Je suppose que une caractéristique pourrait être quelque chose comme « autorisation de carte de crédit », tandis qu'une histoire d'utilisateur peut être « autoriser la carte de crédit paypal ».

Alors, est une histoire d'utilisateur un sous-ensemble d'une fonction?

Answer 1

Oui, quelque chose comme un sous-ensemble. Cet article est une bonne lecture:
Caractéristiques vs histoires

Extrait:

  

J'ai réalisé aujourd'hui que je ne l'avais pas fait   explicite la différence dans mon esprit   entre les caractéristiques et les histoires et il est   une différence importante. Essentiellement,   une caractéristique est un groupe d'histoires   sont liés et de fournir un ensemble de   fonctionnalité que les utilisateurs finaux seraient   attendent généralement d'obtenir à la fois.   Par exemple, le redimensionnement de table en ligne est   une caractéristique (note: c'est la capacité   faire glisser pour redimensionner des tables, des lignes et   colonnes - essayez dans Word). dans le   premier passage, vous auriez probablement un   histoire unique pour le redimensionnement en ligne de   tables, mais il serait trop grand pour   estimation. Alors vous le décomposer en   trois étages, redimensionner les colonnes, redimensionner   lignes et redimensionner la table elle-même.

Answer 2

Selon Kent Beck et Martin Fowler histoires et Caractéristiques sont synonymes:

  

Une histoire d'utilisateur est un morceau de   fonctionnalité (certaines personnes utilisent la   mot fonction ) qui est de valeur   le client.

Ce que vous appelez fonction est généralement appelé thème ou épique . Les thèmes et les épopées sont utilisés pour des histoires d'utilisateurs du groupe à de plus grands ensembles de fonctionnalités, qui ont du sens de leur propre chef.

D'un point de vue plus sémantique: caractéristique est une partie du système que vous essayez de construire, histoire d'utilisateur est une façon de décrire cette partie.

---

Correction:

Comme Pascal a souligné - je manqué peut-être le vrai sens de « fonction » dans cette citation ( « fonctionnalité » fait évidemment référence à la fonctionnalité) En dehors de cela, je pense toujours que l'on peut utiliser ces mots (fonction et histoire de l'utilisateur) comme synonymes dans beaucoup de contextes ( « Je travaille sur cette histoire » vs « Je travaille sur cette fonction »), puisque, comme dit Pascal, une histoire d'utilisateur est un moyen de capturer une fonction. Ce qui signifie qu'il ya une relation 1: 1 entre les deux. Et, comme on peut le voir de ma remarque sur la sémantique, voilà comment je comprends vraiment.

Answer 3

Pas du tout ..

Une histoire d'utilisateur représente les petites pièces de valeur commerciale. Il est donc très difficile de dire quand une histoire d'utilisateur est un sous-ensemble d'une fonction ou une caractéristique est un sous-ensemble d'une histoire d'utilisateur (aussi garder à l'esprit que les histoires d'utilisateurs sont généralement écrits par les parties prenantes, qui ont tendance à ne pas savoir exactement ce que ils veulent ... :))

Alors, si vous suivez la recommandation agile pour garder les histoires courtes vous tomber sur le scénario « meilleur » qui est l'histoire d'utilisateur étant un sous-ensemble de la fonction.

Toutefois, si votre partie prenante d'écrire des histoires longues, chaque histoire aurait deux caractéristiques (s'il y a une bonne communication entre l'équipe et les parties prenantes cela ne se produira puisque l'équipe va briser les histoires en petits)

Answer 4

Les fonctionnalités sont ce qu'un système est en train de faire. histoires de l'utilisateur ne sont qu'un moyen parmi d'autres pour capturer les caractéristiques.

Answer 5

Je viens de tomber sur ce sujet quand je cherchais des idées différentes sur « l'utilisation de plusieurs rôles pour des exigences similaires ».

Je pense que, d'une fonction en tant que conteneur pour les histoires connexes contribue à donner la priorité aux exigences parce que les intervenants disent habituellement leurs besoins comme des histoires à charge. Dans un récent projet, le client m'a dit comme suit

Un membre peut envoyer des messages à l'administrateur Admin peut envoyer des messages à tous les membres Les membres peuvent envoyer des messages à l'autre

Quand je vois ces exigences, je sais que, nous devrions mettre en place un système pour permettre aux gens d'envoyer un message et il convient d'ajouter des contrôles pour permettre à qui faire quoi.

Et je sais aussi que ces exigences peuvent avoir d'autres exigences implicites telles que la lecture des messages qui sont venus, les arranger, peuvent être réglage comme spam et etc.

Alors je tente de reformuler ces exigences

En tant que membre ou admin, je peux envoyer des messages à d'autres personnes. En tant que membre ou admin, je peux lire les messages qui ont été envoyés à moi.

Et comme les critères d'acceptation, je déclare en détail qui peut envoyer à qui.

Alors j'appelle toutes ces choses comme fonction « messagerie privée », de sorte que, à un moment plus tard, si le client décide qu'il est un coût supplémentaire, il peut dire « laisser tomber juste la chose la messagerie privée » et je peux retirer tous du carnet de commandes.