Quelle est la différence entre une histoire D'Utilisateur et une fonctionnalité dans la terminologie Agile? [fermé]

Selon Kent Beck et Martin Fowler histoires et fonctionnalités sont synonymes:

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

Ce que vous appelez un fonction est généralement appelé thème ou épique. Les thèmes et les épopées sont utilisés pour regrouper les histoires d'utilisateurs en ensembles de fonctionnalités plus importants, qui ont du sens en eux-mêmes.

À partir d'un plus point de vue sémantique: feature est une partie du système que vous essayez de construire, user story est un moyen de décrire cette partie.

Correction:

Comme Pascal l'a souligné - j'ai peut-être manqué le vrai sens de "feature" dans cette citation ("feature" fait évidemment référence à la fonctionnalité) en dehors de cela, je pense toujours que l'on peut utiliser ces mots (feature et user story) comme synonymes dans beaucoup de contextes ("je travaille sur cette histoire" VS "je travaille sur cette fonctionnalité"), puisque, comme Pascal a dit, Une histoire d'utilisateur est un moyen de capturer une fonctionnalité. Ce qui signifie qu'il y a une relation 1:1 entre ces deux. Et, comme on peut le voir de ma remarque sur la sémantique, c'est ainsi que je le comprends vraiment.

Pas du tout..

Une histoire d'utilisateur représente de petites parties de la valeur métier. Donc, il est vraiment difficile de dire quand un article de l'utilisateur est un sous-ensemble d'une fonction ou d'une fonction est un sous-ensemble d'un article de l'utilisateur (également garder à l'esprit que l'utilisateur histoires sont généralement écrites par les parties prenantes, qui ont tendance à ne pas savoir exactement ce qu'ils veulent ... :) )

Donc, si vous suivez la recommandation de l'agile pour garder les histoires courtes vous tomber sur le "meilleur" scénario que l'utilisateur est l'histoire d'un sous-ensemble de la fonctionnalité.

Cependant, si votre intervenant écrit de longues histoires, Chaque histoire aurait quelques fonctionnalités (s'il y a une bonne communication entre l'équipe et les parties prenantes, cela n'arrivera pas puisque l'équipe divisera les histoires en petites)

Caractéristiques sont ce qu'un système fait. Les histoires d'utilisateurs ne sont qu'un moyen parmi d'autres de capturer des fonctionnalités.

Je suis juste tombé sur ce sujet quand je cherchais des idées différentes sur "Utiliser plusieurs rôles pour des exigences similaires".

Je pense qu'une fonctionnalité en tant que conteneur pour les histoires connexes aide à prioriser les exigences parce que les parties prenantes racontent généralement leurs besoins en tant qu'histoires dépendantes. Dans un projet récent, le client m'a dit ce qui suit

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

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 nous devrions ajouter des contrôles qui permettent de faire ce.

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

J'essaie donc de reformuler ces exigences comme

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

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

Ensuite, j'appelle toutes ces choses comme fonction de "messagerie privée", de sorte que, à un moment donné, si le client décide que c'est un coût supplémentaire, il peut dire" il suffit de laisser tomber la chose de messagerie privée " et je peux les supprimer tous du backlog.