En tant que novice en matière d'agilité, je ne suis pas sûr de bien comprendre la relation ou la différence entre une histoire d'utilisateur, une fonctionnalité et une épopée.
Selon cette question , une fonctionnalité est une collection d'histoires. L'une des réponses suggère qu'une fonctionnalité est en réalité une épopée. Les caractéristiques et les épopées sont-elles considérées comme la même chose, c’est-à-dire une collection d’histoires utilisateur connexes?
Notre chef de projet insiste sur le fait qu’il existe une structure hiérarchique:
Epic -> Features -> User stories
Et que, fondamentalement, toutes les histoires d'utilisateurs doivent entrer dans cette structure. Par conséquent, toutes les histoires d'utilisateurs doivent être regroupées dans une fonction parapluie et toutes les fonctionnalités doivent être classées dans une épopée.
Pour moi, cela semble bizarre. Quelqu'un peut-il clarifier la relation entre les histoires d'utilisateurs, les fonctionnalités et les épopées? Ou existe-t-il un article décrivant clairement les différences?
la source
Réponses:
Ce sont des termes très génériques. Il y a beaucoup de façons de les interpréter, variant dans la littérature et la façon dont les gens les voient. Prenez tout ce que je dis avec un énorme grain de sel.
Habituellement, un Epic comprend une fonctionnalité très globale et pas très bien définie dans votre logiciel. C'est très large. Elle est généralement décomposée en une user story plus petite ou une fonctionnalité lorsque vous essayez de la comprendre et de l’intégrer dans une itération agile. Exemple :
Epic
- Permet au client de gérer son propre compte via le Web
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’ils soient suffisamment granulaires pour tenir dans une seule itération.
Les fonctionnalités ont généralement tendance à décrire les tâches de votre logiciel:
Fonctionnalité
- Modification des informations client via le portail Web
Les histoires d'utilisateurs ont tendance à exprimer ce que l'utilisateur veut faire:
User story
En tant qu'employé de banque,
je souhaite pouvoir modifier les informations client
afin de pouvoir les tenir à jour.
Je ne pense pas qu'il existe vraiment une hiérarchie entre les deux, mais vous pouvez en avoir une si vous le souhaitez ou si cela convient à votre façon de travailler. Une user story peut être une justification spécifique pour une fonctionnalité ou un moyen spécifique de le faire. Ou ce peut être l'inverse. Une fonctionnalité peut être un moyen de réaliser une histoire d'utilisateur. Ou ils peuvent dénoter la même chose. Vous pouvez utiliser les deux: User stories pour définir ce qui apporte de la valeur métier et une fonctionnalité pour décrire les contraintes du logiciel.
Histoire d'utilisateur : en tant que client, je souhaite payer avec les cartes de crédit les plus courantes. Cette
fonction prend en charge l'API XML GOV-TAX-02 du gouvernement.
Il y a aussi la question du scénario, qui est généralement la manière dont une histoire d'entité / utilisateur sera exécutée. Ils correspondent généralement bien à un test d'acceptation spécifique. Par exemple
Scénario : Retirer de l'argent étant
donné que j'ai 2000 $ dans mon compte bancaire
Lorsque je retire 100 $
, je reçois 100 $ en argent comptant
et le solde est de 1900 $
C'est ainsi que nous définissons ces termes dans lesquels je travaille . Ces définitions sont loin d'une définition mathématique ou d'un terme normalisé. C'est comme la différence entre un politicien de droite et un politicien de gauche. Cela dépend où tu habites. Au Canada, ce qui est considéré comme de droite peut être considéré comme de gauche aux États-Unis. C'est très variable.
Sérieusement, je ne m'en inquiéterais pas trop. L'important est que tous les membres de l'équipe s'accordent sur une définition afin que vous puissiez vous comprendre. Certaines méthodes comme Scrum ont tendance à les définir plus formellement, mais choisissez ce qui vous convient et laissez le reste. Après tout, l’agilité entre individus et interactions entre processus et outils et logiciel de travail sur documentation complète n’est-elle pas agile ?
la source
Epic : Une très grande histoire d'utilisateurs qui est finalement décomposée en histoires plus petites.
Scénario utilisateur: définition très détaillée d’une exigence, contenant juste assez d’informations pour permettre aux développeurs de produire une estimation raisonnable des efforts déployés pour la mettre en œuvre.
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
Caractéristique : caractéristique ou capacité distinctive d’une application logicielle ou d’une bibliothèque (performances, portabilité ou fonctionnalité, par exemple).
http://en.wikipedia.org/wiki/Software_feature
la source
Je vous mets en garde contre l'application d'une hiérarchie trop rigide à ces termes. Nous avons essayé de le faire dans mon travail précédent. Deux fois. Les deux tentatives étaient différentes et les deux fois nous avons constaté que nous nous étions inutilement limités. La seule constante était la définition d'une user story . Du point de vue de la planification, une histoire est la pierre angulaire d’un projet. Les grands termes (épopée, fonctionnalité, etc.) ne sont en réalité que des balises . Les balises constituent un moyen simple de permettre à une histoire d’exister en même temps dans plusieurs épopées et plusieurs fonctionnalités. Cela ne vaut pas l'effort mental d'être plus strict que cela.
Les balises fonctionnent pour Stack Exchange et peuvent également fonctionner pour vous.
la source
Voici comment nous travaillons avec Epics, Stories and Features
Au début du cycle de projet, nous trouvons Epics . Ce sont des fonctionnalités de très haut niveau, presque centrées sur le marketing. Le genre de chose que vous pouvez utiliser dans un résumé, tel que,
Cela conduit à des épopées telles que
Celles-ci sont rédigées sous la forme de récits utilisateur (par exemple, en tant que client, je souhaite parcourir le catalogue de produits afin de pouvoir prendre une décision d'achat en connaissance de cause), mais je ne joue que le rôle d'initiateur pendant dix ans pour ce qui sera réellement développé et publié.
Ces épopées sont ensuite décomposées en histoires d'utilisateurs . Il s’agit de parcours complets d’utilisateur de bout en bout, de portée très limitée et définis de manière à pouvoir être estimés et planifiés de manière indépendante, puis développés , testés et diffusés au cours d’un seul cycle de publication.
La User Story est l'unité de livraison. C'est la user story qui est complète ou non complète, qui est mise en ligne ou non.
Une Epic peut générer un grand nombre de user stories, toutes ne seront pas développées ou publiées en même temps.
À titre d’exemple, l’épopée de consultation du catalogue de produits peut se décomposer en
Là encore, chacun de ces éléments serait écrit dans le format. Par exemple, en tant que client, je souhaite naviguer dans la hiérarchie des catégories afin de pouvoir parcourir les produits et accéder au produit le mieux adapté à mes besoins.
En général, pour la plupart de nos projets, nous avons des dizaines d’Epics et des centaines d’histoires.
Au fur et à mesure que nous parcourons le cycle de vie d'une histoire, nous marquons ces histoires avec Feature s. Par exemple, tous les articles de navigation, de recherche, de stock et de tarification seront étiquetés avec, par exemple, "catalogue de produits". Les histoires de commande relatives au paiement par carte de crédit peuvent être étiquetées avec une étiquette «carte de crédit» et celles relatives au paiement par PayPal seront étiquetées avec une étiquette «paypal».
Ces étiquettes servent à regrouper des histoires qui vont ensemble, non pas parce qu’elles exercent la même activité de différentes manières (par exemple, toutes les histoires d’ordre place), mais parce qu’elles doivent être publiées ensemble.
Par exemple, l’histoire «passer une commande en utilisant une carte de crédit» appartient à la même épopée que l’histoire «en passant une commande avec PayPal», mais ils ne doivent pas nécessairement être publiés ensemble.
Alors que l'histoire "passer une commande avec paiement par carte de crédit", l'histoire "traiter un remboursement sur une carte de crédit" et l'histoire "permettre aux clients de gérer leurs cartes de crédit enregistrées sur leur compte" semblent appartenir les unes aux autres . Ils auraient tous été étiquetés avec l'étiquette de fonctionnalité «carte de crédit». c'est-à-dire qu'ils appartiendraient tous à la fonction "Carte de crédit". Il n'est pas très utile de libérer la possibilité de passer une commande en payant par carte de crédit, s'il n'est pas possible de traiter un remboursement de retour sur PayPal, ou s'il n'est pas possible de gérer vos cartes de crédit enregistrées sur votre compte.
Remarque : En règle générale, c'est le cas. C'est finalement une décision commerciale. Si le délai de mise sur le marché est important, il peut exister une raison légitime de partir avec l'une d'elles et non avec l'autre.
Ainsi, Epics sert à décomposer en histoires (liées, mais distinctes) qui peuvent être développées indépendamment, tandis que Les fonctionnalités servent à regrouper des histoires qui devraient être publiées ensemble.
Vous pourriez dire que les Epics se décomposent en histoires d'utilisateurs et que les histoires d'utilisateurs sont composées en fonctionnalités. Les histoires qui appartiennent à une fonctionnalité sont généralement à travers Epics. Ainsi, Epics et Features sont orthogonaux, pas dans une hiérarchie stricte.
Dans notre façon de travailler, une fois que les épopées ont été décomposées en histoires, elles perdent leur raison d'être. Nous n'évaluons ni ne planifions les épopées. Nous ne suivons pas les progrès sur Epics. Nous ne libérons pas Epics. Nous estimons, planifions et suivons les récits d'utilisateurs. Et nous publions des fonctionnalités.
la source
Je suis d'accord, comme beaucoup de réponses, sur le fait qu'il n'y a pas vraiment de bonne réponse car ce ne sont que des termes qui peuvent être modifiés en fonction du camp Agile sur lequel vous êtes basé et vous pouvez certainement créer votre propre camp à condition que tous les membres de votre équipe, y compris les parties prenantes externes comprendre ce qu'ils veulent dire. C'est juste une façon d'organiser vos besoins.
La réponse que j’aime est celle du camp de Mike Cohn et c’est assez simple.
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
Il évite en réalité le terme "Feature". Je suppose que c'est principalement parce que c'était un terme commun dans le monde traditionnel des chutes d'eau. De nombreux camps agiles ont tendance à utiliser des termes différents pour souligner les différences.
Donc, dans la définition de votre PM, Feature se situe quelque part au milieu de la hiérarchie Epic-Story.
Voici mon infographie de cette définition tirée de mon article sur InfoQ http://www.infoq.info/articles/visualize-big-picture-agile ;-)
la source
Les fonctionnalités et les épopées ne sont pas la même chose.
Au cours des phases de planification, les discussions aboutissent à des user stories qui sont généralement identifiées comme des épopées, car l'effort nécessaire pour mettre en œuvre des solutions adaptées est trop important pour être accompli en quelques jours. Les caractéristiques du produit sont identifiées au cours de cette phase. Mais ce n'est qu'un sous-produit de la discussion. Les fonctionnalités sont ensuite utilisées pour planifier une carte routière du produit, qui fait l'objet d'une discussion séparée.
Les épopées sont prises en compte et discutées plus avant, donnant lieu à des histoires d'utilisateurs pour chaque épopée. Les fonctionnalités et les épopées sont utilisées pour animer les discussions lors des sessions de raffinement du carnet de commandes et de planification des sprints. À ce moment-là, les récits d'utilisateurs issus de ces discussions sont affinés , hiérarchisés et, dans la planification des sprints, acceptés dans les sprints à des fins de mise en œuvre.
la source
C'est juste un problème de décomposition. Ce ne sont que des histoires, sauf avec des tailles différentes.
Personnellement, je préfère ne pas étiqueter leurs tailles, mais si vous le faites, c'est très bien aussi. Demandez à PM quelle est la définition dans votre espace de travail.
la source
Notre organisation compte plus de 2 000 développeurs. La réponse à cette question est donc importante pour une communication claire et fluide entre les centaines d’équipes Agiles travaillant ensemble sur notre produit commun. Pour une très petite organisation, vous pouvez avoir une structure très simple qui n'a même pas besoin d'être hiérarchique (comme d'autres l'ont répondu). Cependant, pour les grandes organisations, il est clair qu'il faut une hiérarchie organisée, à l'échelle et cohérente - et c'est là que réside le problème de s'efforcer de hiérarchiser quelque chose qui n'est pas strictement hiérarchique.
Incidemment, nous appelons chacun de ces niveaux disparates des "éléments de travail". Certaines organisations (y compris certaines des personnes interrogées ci-dessus) se réfèrent à des niveaux disparates sous la forme de récits ou de récits d'utilisateurs (et nous l'avons également fait par le passé), mais nous avons trouvé cela trop ambigu. Nous les appelons donc de manière générique d'éléments de travail.
Le mieux que nous ayons "officiellement" fait jusqu'à présent est de suivre la structure SAFe des thèmes d'investissement et des épopées économiques de Dean Leffingwell se situant au sommet (et à partir du sommet) de la hiérarchie, puis aux fonctionnalités en dessous, et enfin aux Histoires aux caractéristiques. Selon Agile, les tâches sont toujours classées sous Histoires. Nous veillons donc à ne pas réutiliser ce terme plus haut. Nous avons choisi de suivre SAFe pour au moins avoir une certaine cohérence dans toutes nos équipes.
Mais cela reste insuffisant pour nos besoins. Nous définissons une fonctionnalité comme un élément clairement livrable pour un consommateur de notre logiciel (c'est-à-dire que nous répertorions ces fonctionnalités dans nos annonces de versions à venir). Et nous définissons une histoire comme une plus petite étendue de travail et de travail pouvant être livrés en un seul sprint par une seule équipe de développement agile. Nous commençons également maintenant à suivre la définition SAFe de thème d'investissement et épopée économique au niveau du portefeuille (et non en dessous de ce niveau). Et nous commençons à NE PAS utiliser nos anciennes définitions de "Thème" et "Épique".
Nous évoluons maintenant lentement dans cette direction, mais les rouages du progrès s’écroulent lentement. Nous sommes toujours aux prises avec la division du travail en petits morceaux afin que nous puissions définir le travail et le faire en douceur par plusieurs équipes. Pour ce faire, nous voyons la nécessité d’un «sous-élément» plus petit qu’un élément mais plus grand qu’un récit. Les sous-fonctionnalités peuvent être utilisées pour des portions de travail effectuées sur une Feature par chaque équipe, ou des portions de travail effectuées par une seule équipe à différents moments (dans différents Sprints, voire différentes versions).
Nous avons également besoin de plusieurs niveaux hiérarchiques entre Feature et Business Epic, mais nous n’avons pas encore résolu celui-ci, si ce n’est pour les appeler simplement "Thèmes" - nous savons que ce n’est pas le terme correct, car il est facile à confondre avec SAFe Investment. Pour certains gros projets (versions), nous avons jusqu'à 5 à 8 niveaux hiérarchiques différents, chacun divisant le travail en morceaux de plus en plus petits. Vous pouvez considérer ces thèmes comme des "groupes de fonctions", mais ce n'est pas nécessairement le terme correct non plus.
Je pense qu'il est important d'essayer d'utiliser des termes qui offrent plus de clarté que d'ambiguïté. Ainsi, toute personne faisant référence à un récit signifie la plus petite unité de travail pouvant être réalisée dans un seul sprint (à l'exception des tâches du récit), et Sub-Feature désigne la plus petite unité de travail sur une fonctionnalité pouvant être effectuée par un seul. équipe. De même, un groupe de fonctionnalités correspond à un niveau hiérarchique supérieur à celui de la fonctionnalité. Au-dessus, cela devient un peu flou. Nous les appelons donc généralement des thèmes, et nous autorisons les thèmes en tant que parents et enfants d'autres thèmes. Nous essayons de limiter les niveaux de fonctionnalité, de sous-fonctionnalité et d'histoire à un seul niveau chacun (les fonctionnalités ne doivent pas être des enfants d'autres fonctionnalités), mais nous ne sommes pas encore parvenus à le limiter à 100%.
Je sais que nous pourrions utiliser des "balises" pour organiser certaines de ces tâches, mais les balises ne nous donnent pas la structure de répartition du travail organisationnelle dont nous avons besoin pour classer le travail entre toutes nos équipes. Par définition, les balises sont ambiguës (relations plusieurs-à-plusieurs), mais une hiérarchie est strictement un-à-plusieurs.
L'essentiel, c'est qu'il s'agit toujours d'un travail en cours pour nous, et nous avons encore du mal à le faire. Mais en adhérant aux définitions SAFe de thème, épopée, long métrage et histoire, nous allons dans la bonne direction!
la source
La hiérarchie du backlog de produits dépend en grande partie de la taille du produit et de sa modularité (nombre de domaines de produits définis).
Pour les petits projets: Epic> Story est plus que suffisant; et vous appelez soit la "fonctionnalité".
Les grands projets peuvent ressembler à: Roman> Thème> Epic> Feature> Story
Le meilleur exemple pourrait être le suivant:
Novel = MS Office
Thème = MS Word / MS Excel ...
Epic = Tableaux / Répertoire de polices ...
Fonctionnalités = Tableau de base / Modèle de couleurs de tableau / Opérations avec des cellules ...
Histoires (pour ' "Fonctions élémentaires dans les tableaux de base" = Ajouter un tableau / Dessiner un tableau / Insérer une colonne brute / insérer ...
Ce que je pense qu'il est utile de garder à l'esprit lors de la définition de votre propre classement en retard est:
1. Histoire: a) toujours réalisable en un seul sprint; b) pas toujours vérifiable pour les utilisateurs finaux
2. Epic / Feature: a) ne correspond pas à une durée de sprint et doit être décomposé; b) devrait toujours être vérifiable pour les utilisateurs finaux; c) toujours expédiable, peut être monétisé - calculez le retour sur investissement correspondant.
3. Lorsque vous envisagez d’ajouter ou de ne pas ajouter Epic> Feature ou de vous en tenir à Epic> Story: je recommanderais d’insérer Feature entre Epic et Story uniquement lorsque: Epic does '. t fit fit même une version, vous devez donc définir un élément pouvant être expédié qui conviendra à une durée de libération .
J'espère que c'est utile.
la source
Dans notre organisation, nous avons les éléments suivants:
Thème = Utilisé pour regrouper une collection d'histoires
Epic = Décrit une grande user story (en réalité une exigence) qui doit être décomposée en user stories.
Fonctionnalités = Fait ce qui est écrit sur l'étain, décrit une fonctionnalité du produit requise
User story = Il s'agit du niveau de détail le plus bas à partir duquel les tâches sont dérivées.
la source