Quelle est la différence entre les user stories et les fonctionnalités?
En jouant avec icescrum , j'ai réalisé que je ne comprenais pas la différence entre les user stories et les fonctionnalités utilisateur.
Quelqu'un peut-il expliquer la différence?
Une fonctionnalité est un élément distinct de fonctionnalité qui peut fournir des capacités à l'entreprise.
Une histoire est un petit aspect d'une fonctionnalité que vous pouvez utiliser pour obtenir des commentaires de vos parties prenantes et savoir si vous faites quelque chose de mal.
Par exemple, une fonctionnalité pourrait être "permettre aux utilisateurs de commenter des articles". Les histoires associées à cette fonctionnalité pourraient alors être:
- enregistrer les commentaires
- filtrer les commentaires pour les mots grossiers
- limiter les commentaires à 400 caractères et renvoyer aux utilisateurs
- ajouter des captchas pour empêcher les robots de spammer le site
- permettre aux utilisateurs de se connecter via Google id
etc.
À chaque étape, nous pouvons ensuite obtenir des commentaires sur la pertinence de la direction que nous prenons.
Certaines équipes ne prennent pas la peine de diviser des fonctionnalités en histoires. C'est bon.
Caractéristiques == Histoires d'utilisateurs.
Le verbiage est dicté par l'Agile donné méthodologie utilisé.
Les différentes méthodologies utilisent une terminologie différente pour faire référence aux fonctionnalités. C'est à l'équipe de décider quelle méthodologie ou terminologie utiliser. Extreme Programming (XP) utilise les termes User Stories ou Stories pour représenter des fonctionnalités; Scrum utilise Product Backlog pour décrire une liste de fonctionnalités; Le développement piloté par les fonctionnalités utilise la fonctionnalité; et DSDM utilise l'exigence. De même, il existe différentes versions allégées du processus unifié, ou Agile UP, qui utilisent des exigences et/ou des cas d'utilisation pour définir des fonctionnalités livrables de manière incrémentielle. En fin de compte, l'objectif est le même: fournir régulièrement de la valeur commerciale par petits incréments, et le plus tôt possible.
A ser Story est une déclaration informelle dans la langue du client qui capture l'intention de quelque chose que le client souhaite réaliser. Vous pouvez considérer un ser Story comme une déclaration de besoin informelle.
A fonctionnalité logicielle est une caractéristique distincte du logiciel qui contribue à la conception et aux fonctionnalités générales du logiciel.
Quelques considérations clés:
- Un Story peut décrire un Feature, mais une fonctionnalité ne décrit jamais un Story.
- Un Story peut ne pas décrire directement un Feature.
- Un Story peut impliquer l'inclusion d'un certain nombre de Features.
- Un Feature - seul ou en tant que membre d'une collection de Features - peut capturer l'intention d'un Story.
Avec tout cela à l'esprit, j'ai tendance à considérer les histoires comme des descriptions. Exigences essentiellement informelles qui me disent ce que veut le client. Les fonctionnalités, d'autre part, j'ai tendance à penser davantage à une spécification qui me dit comment un système devrait fonctionner pour répondre aux exigences des clients.
Les deux termes sont étroitement liés, mais il existe quelques différences.
Tout d'abord, ils proviennent de différents domaines. Le terme "fonctionnalité" est un terme assez général pour désigner une partie des fonctionnalités d'un logiciel, alors que "user story" a été inventé et n'est vraiment utilisé que dans le contexte du développement logiciel agile.
En pratique, elles coïncident très souvent, en ce qu'une seule user story consiste à implémenter une certaine fonctionnalité.
Cependant, dans certaines situations, ils peuvent être différents:
- Souvent, une fonctionnalité représente trop de travail pour une seule histoire d'utilisateur. Les user stories ne doivent pas être trop grandes (généralement pas plus de quelques jours, max 1-2 semaines de travail). De toute évidence, de nombreuses fonctionnalités sont beaucoup plus importantes. Dans ce cas, une fonctionnalité sera implémentée dans de nombreuses user stories. Certaines personnes utilisent des "épopées" pour regrouper des user stories, dans ce cas, vous pourriez dire que la fonctionnalité est une épopée.
- Les exigences non fonctionnelles (performances, sécurité, compatibilité, etc.) peuvent également être traitées comme des user-stories (bien que cela ne soit pas universellement accepté). Dans ce cas, le résultat de la user story ne serait normalement pas appelé une fonctionnalité (sauf si vous appelez "notre application plante rarement" une fonctionnalité).