Quelle est la différence entre une User Story et une fonctionnalité dans la terminologie Agile?
Je suppose qu'une fonctionnalité pourrait être quelque chose comme "l'autorisation de carte de crédit", tandis qu'une histoire d'utilisateur peut être "autoriser la carte de crédit pour Paypal".
Ainsi, une histoire d'utilisateur est-elle un sous-ensemble d'une fonctionnalité?
Oui, quelque chose comme un sous-ensemble. Cet article est une bonne lecture:
Fonctionnalités vs histoires
Extrait:
J'ai réalisé aujourd'hui que je n'avais pas explicité la différence dans mon esprit entre les fonctionnalités et les histoires et c'est une différence importante. Essentiellement, une fonctionnalité est un groupe d'histoires qui sont liées et fournissent un ensemble de fonctionnalités que les utilisateurs finaux s'attendent généralement à obtenir en une seule fois. Par exemple, le redimensionnement de table en ligne est une fonctionnalité (remarque: il s'agit de la possibilité de faire glisser pour redimensionner des tableaux, des lignes et des colonnes - essayez-le dans Word). Dans la première passe, vous auriez probablement une seule histoire pour le redimensionnement en ligne des tableaux, mais ce serait trop gros pour être estimé. Donc, vous le décomposez en trois étages, redimensionnez les colonnes, redimensionnez les lignes et redimensionnez le tableau lui-même.
Selon Kent Beck et Martin Fowler histoires et caractéristiques sont synonymes:
Une user story est un morceau de fonctionnalité (certaines personnes utilisent la fonctionnalité Word ) qui est utile au client.
Ce que vous appelez une fonctionnalité est généralement appelé thème ou épique . Les thèmes et les épopées sont utilisés pour regrouper les user stories dans de plus grands ensembles de fonctionnalités, qui ont du sens par eux-mêmes.
D'un point de vue plus sémantique: la fonctionnalité est une partie du système que vous essayez de construire, la 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 "fonctionnalité" dans cette citation ("fonctionnalité" se réfère évidemment à la fonctionnalité). En dehors de cela, je pense toujours que l'on peut utiliser ces mots beaucoup de contextes ("Je travaille sur cette histoire" vs "Je travaille sur cette fonctionnalité"), car, comme l'a dit Pascal, une user story est un moyen de capturer une fonctionnalité. Ce qui signifie qu'il existe une relation 1: 1 entre ces deux-là. Et, comme on peut le voir dans ma remarque sur la sémantique, c'est ainsi que je la comprends vraiment.
Pas du tout..
Une user story représente de petites parties de la valeur commerciale. Il est donc très difficile de dire quand une user story est un sous-ensemble d'une fonctionnalité ou une fonctionnalité est un sous-ensemble d'une user story (gardez également à l'esprit que les user stories sont généralement écrites par les parties prenantes, qui ont tendance à ne pas savoir exactement ce que Ils veulent ... :) )
Donc, si vous suivez la recommandation de l'agile pour garder les histoires courtes, vous tomberiez sur le "meilleur" scénario qui est l'histoire de l'utilisateur étant un sous-ensemble de la fonctionnalité.
Cependant, si votre partie prenante écrit de longues histoires, chaque histoire aurait quelques caractéristiques (s'il y a une bonne communication entre l'équipe et les parties prenantes, cela ne se produira pas car l'équipe divisera les histoires en petites)
Les fonctionnalités sont ce que fait un système. Les user stories ne sont qu'un moyen parmi d'autres de capturer des fonctionnalités.
Je suis juste tombé sur ce sujet lorsque je cherchais des idées différentes sur "l'utilisation de plusieurs rôles pour des besoins similaires".
Je pense que, une fonctionnalité en tant que conteneur pour des histoires connexes aide à hiérarchiser les exigences car les parties prenantes disent généralement leurs besoins comme des 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 les uns aux 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 vérifications pour permettre à qui de faire quoi.
Et je sais aussi que ces exigences peuvent avoir d'autres exigences implicites telles que la lecture des messages qui sont venus, leur organisation, peuvent être définies 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 administrateur, je peux lire les messages qui m'ont été envoyés.
Et comme critère d'acceptation, je précise en détail qui peut envoyer à qui.
Ensuite, j'appelle toutes ces choses en tant que fonctionnalité 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 messagerie privée" et je peux les supprimer toutes. de l'arriéré.