En tant que personne encore novice dans le domaine de l'agilité, je ne suis pas sûr de comprendre complètement la relation ou la différence entre l'histoire de l'utilisateur, la fonctionnalité et l'épopée.
Selon cette [question][1], une fonctionnalité est une collection d'histoires. L'une des réponses suggère qu'une fonctionnalité est en fait une épopée. Les fonctionnalités et les épopées sont-elles considérées comme une seule et même chose, c'est-à-dire une collection d'histoires d'utilisateurs liées entre elles ?
Notre chef de projet insiste sur le fait qu’il existe une structure hiérarchique :
Epopée -> Fonctionnalités -> Histoires d'utilisateurs
Et que, fondamentalement, toutes les histoires d'utilisateurs doivent s'inscrire dans cette structure. Par conséquent, toutes les histoires d'utilisateurs doivent relever d'une fonctionnalité parapluie et toutes les fonctionnalités doivent relever d'une épopée.
Pour moi, cela semble bizarre. Quelqu'un peut-il clarifier comment les user stories, les fonctionnalités et les épopées sont liées ? Ou existe-t-il un article qui expose clairement les différences ?
Il s'agit en fait d'un terme très générique. Il existe de nombreuses façons de les interpréter, qui varient selon la littérature et la façon dont les gens les perçoivent. Prenez tout ce que je dis avec un gros grain de sel.
En général, un Epic comprend une fonctionnalité très globale et pas très bien définie dans votre logiciel. Elle est très large. Elle sera généralement décomposée en petites histoires d'utilisateur ou en fonctionnalités lorsque vous essayez de lui donner un sens et de les intégrer dans une itération agile. Exemple :
Epic
Les Feature et User Story sont des fonctionnalités plus spécifiques, que vous pouvez facilement tester avec des tests d'acceptation. Il est souvent recommandé qu'elles soient suffisamment granulaires pour tenir dans une seule itération.
Les fonctionnalités tendent généralement à décrire ce que fait votre logiciel :
Fonctionnalité
Les histoires d'utilisateur tendent à exprimer ce que l'utilisateur veut faire :
User story En tant qu'employé de banque, je veux être capable de modifier les informations sur les clients afin de pouvoir les mettre à jour.
Je ne pense pas qu'il y ait vraiment de hiérarchie entre les deux, mais vous pouvez en avoir une si vous le souhaitez ou si cela correspond à votre façon de travailler. Une histoire d'utilisateur peut être une justification spécifique pour une fonctionnalité, ou une façon spécifique de la faire. Elle peut aussi être l'inverse. Une fonctionnalité peut être un moyen de réaliser une histoire d'utilisateur. Ou ils peuvent désigner la même chose. Vous pouvez utiliser les deux : les user stories pour définir ce qui apporte une valeur métier et les fonctionnalités pour décrire les contraintes du logiciel.
User story : en tant que client, je veux payer avec les cartes de crédit les plus populaires. Fonctionnalité : support de l'API XML GOV-TAX-02 du gouvernement.
Il y a aussi la question du scénario, qui est généralement une façon d'exécuter une fonctionnalité ou une histoire d'utilisateur. Ils correspondent généralement à un test d'acceptation spécifique. Par exemple
Scénario : Dépôt d'argent. Étant donné que j'ai 2000$ sur mon compte bancaire Lorsque je retire 100 $. Puis je reçois 100$ en espèces Et mon solde est de 1900$.
C'est ainsi que nous définissons ces termes où je travaille. Ces définitions sont loin d'être une définition mathématique ou un terme standardisé. C'est comme la différence entre un politicien de droite et un politicien de gauche. Cela dépend de l'endroit où vous vivez. Au Canada, ce qui est considéré comme étant de droite peut être considéré comme étant de gauche aux États-Unis. C’est très variable.
Sérieusement, je ne m’en ferais pas trop à ce sujet. L'important est que tous les membres de l'équipe se mettent d'accord sur une définition afin de pouvoir se comprendre. Certaines méthodes comme scrum ont tendance à les définir de manière plus formelle, mais choisissez ce qui vous convient et laissez le reste de côté. Après tout, agile n’est-il pas question d’individus et d’interactions plutôt que de processus et d’outils et de logiciels fonctionnels plutôt que de documentation exhaustive ?
Epic : Une très grande histoire d'utilisateur qui est éventuellement décomposée en histoires plus petites.
User story: Une définition de très haut niveau d'une exigence, contenant juste assez d'informations pour que les développeurs puissent produire une estimation raisonnable de l'effort pour l'implémenter.
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
Feature : Une caractéristique ou une capacité distinctive d'une application logicielle ou d'une bibliothèque (par exemple, la performance, la portabilité ou la fonctionnalité).
C’est juste la décomposition des problèmes. Ce sont juste des histoires, sauf qu'elles ont des tailles différentes.
Personnellement, je préfère ne pas étiqueter leurs tailles, mais si vous le faites, c'est aussi bien. Demandez à votre chef de projet quelle est la définition dans votre espace de travail.