Décomposer une histoire complexe au démarrage du projet

J'essaie de me familiariser avec la gestion de projet agile (avec Pivotal Tracker) mais je continue à me retrouver en train de me heurter à des murs lorsque je tente de définir les premières histoires d'un projet. Prenons par exemple cette histoire très simple:

"Un utilisateur doit pouvoir étiqueter un produit"

En supposant que j'ai déjà défini "produit" ailleurs, cette histoire impliquerait peut-être d'écrire un système de marquage polymorphe sous le capot, à la fin de cet identifiant système, pour pouvoir enfin ajouter la possibilité de marquer un produit.

Mon problème est avec la quantité de travail cachée dans cette histoire. Je peux définir des tâches pour faire l'histoire, mais les histoires dans leur ensemble sont censées durer 1 à 2 jours? Je ne me sens pas bien à propos de l'histoire révélant simplement la pointe de l'iceberg, mais c'est la seule partie qui se rapporte à l'utilisateur.

Comment surmontez-vous ce genre de chose? Quelles sont les meilleures pratiques?

MISE À JOUR 25/08 Merci à tous pour vos conseils, j'ai pris tous les conseils à bord sur la façon de définir les histoires. Je passe maintenant à Jira Grasshopper qui a un meilleur support pour les tâches dans les histoires (affectation, estimations, etc.) et le suivi des tâches de développement une fois le sprint commencé.

Si vous avez besoin que vos histoires durent 1 à 2 jours chacune, vous devriez peut-être diviser chaque histoire en tâches utilisateur spécifiques qui représentent 1 à 2 jours de travail de développeur.

Considérez la "user story" suivante:

Un utilisateur doit pouvoir recevoir une facture d'un produit acheté.

Pensez à ce qui est impliqué uniquement dans la conception de la base de données, en donnant à l'utilisateur cette capacité. Vous avez besoin d'une table client, d'une table d'en-tête de facture et d'une table d'éléments de ligne de facture, et nous n'avons même pas encore parlé d'accepter des paiements.

En réalité, les user stories ne sont pas si simples. Les user stories complètes incluent une procédure pas à pas des étapes utilisateur impliquées:

• L'utilisateur met le produit dans le panier
• L'utilisateur spécifie la quantité
• L'utilisateur spécifie le type d'expédition

etc. En bref, vous devez décomposer vos histoires d'utilisateurs dans les moindres détails.

Les histoires ne sont pas censées être "1-2 jours de travail". Sous Scrum, les histoires sont normalement estimées en utilisant Story Points, un système de dimensionnement relatif. Si vous utilisez la planification, les histoires de poker reçoivent une valeur en points - le temps nécessaire à la mise en œuvre de l'histoire dépend de la vitesse établie par votre équipe.

Si vous sentez que l'histoire cache de la complexité (vous pourriez l'appeler une histoire épique ), vous devez la diviser en petites histoires. Assurez-vous que les nouvelles histoires respectent les critères INVEST .

Mais vous êtes peut-être en train de trop réfléchir à cela; le principe XP de YAGNI s'applique ici. Pour être explicite, vous ne devez pas implémenter un "système de marquage polymorphe sous le capot", sauf si vous en avez vraiment besoin. Même alors, il devrait être conçu en améliorant le système existant, que vous avez développé avec une bonne suite de tests.

Si vous êtes certain d'avoir besoin de ce système de balisage complexe, vous devez décrire la complexité dans des histoires distinctes. Mike Cohn décrit l'approche de la conception comme « intentionnelle, mais émergente »

Il semble que vous confondez histoires et tâches.

Histoire de l'utilisateur

Une user story est une "fonctionnalité" complète, quelque chose qui, lorsqu'elle est ajoutée au produit, apporte plus de valeur au produit.

Une user story ne doit pas être plus grande qu'elle ne peut être implémentée lors d'un sprint . Au cours de la première partie de la planification du sprint, vous décidez sur quelles user stories vous souhaitez travailler pendant le sprint. L'objectif du sprint est de compléter ces user stories, ajoutant ainsi plus de valeur au produit.

Tâche

Au cours de la deuxième partie de la phase de planification du sprint, les développeurs divisent l'histoire en tâches . Les tâches sont des tâches de développement. Il peut s'agir de choses comme "Ajouter une colonne à la base de données", "Étendre le service x", etc. Une tâche ne doit pas être plus grande qu'elle ne peut être effectuée en une journée.

Au cours de la mêlée quotidienne, vous évaluez la progression de ces tâches. Si une tâche est en cours depuis plus d'une mêlée quotidienne, elle prend trop de temps et vous, en tant qu'équipe, avez la responsabilité de résoudre cette situation.

N'oubliez pas que les récits d'utilisateurs représentent une valeur commerciale pour les parties prenantes. Les parties prenantes devraient être intéressées par l'achèvement des user stories, et non par des tâches.

La division des tâches est un outil permettant à l'équipe de développement de gérer le sprint, de surveiller la progression des user stories pendant un sprint et de visualiser les problèmes potentiels.

Les parties prenantes ne devraient pas se préoccuper de ces tâches de développement. Malheureusement, d'après mon expérience, ils le font souvent, en particulier pour les organisations nouvelles dans le développement agile. Mais faire face à cette situation est une autre affaire.

Épique

Si une user story est plus grande que vous ne le pensez, vous pouvez la terminer en un seul sprint, cela s'appelle une épopée. Il doit être divisé en plusieurs histoires d'utilisateurs plus petites avant que vous puissiez commencer à y travailler en équipe.

N'oubliez pas qu'une user story ajoute de la valeur à l'utilisateur final, donc diviser une épopée en une "front-end" et une "back-end" n'est pas la bonne façon. L'ajout du back-end pour une nouvelle fonctionnalité ne fournit pas en soi de valeur aux utilisateurs finaux.

Il n'est pas toujours facile de diviser une épopée en histoires d'utilisateurs gérables dans le délai d'un sprint lorsque vous n'avez pas l'expérience de le faire.

Utilisation de Pivotal Tracker

Je pense que Pivotal Tracker est un excellent outil pour suivre les histoires d'utilisateurs. Mais ce n'est pas un outil Scrum en tant que tel, et la façon dont Scrum enseigne à diviser les histoires en tâches n'est pas facilement gérée par le tracker pivot. Vous pouvez activer la possibilité d'ajouter des tâches aux user stories. Mais si vous exécutez un projet en utilisant Scrum, je suggérerais d'utiliser un tableau blanc et des notes autocollantes pour suivre la progression des tâches pendant un sprint.

Avoir un objectif de conception de mise en œuvre d'un système de marquage polymorphe est bien, mais vous devez toujours vous concentrer sur la mise en œuvre des fonctionnalités souhaitées par le client. Cela peut signifier que, histoire utilisateur à granularité fine, histoire utilisateur à granularité fine, votre système évolue vers un système de marquage polymorphe au fil du temps. À tout moment de ce voyage, cependant, vous devriez avoir un système composé de nombreuses petites fonctionnalités testables, décrites par une collection de User Stories que vous avez implémentées.

Dans ce cas, cela ressemble à des «produits de balisage» dans votre système qui pourraient être une épopée, c'est-à-dire quelque chose qui est beaucoup plus grand qu'une seule histoire utilisateur et peut être décomposé en plusieurs histoires plus petites avec un petit effort. Prenant une bonne quantité de licence artistique, je peux penser aux User Stories suivantes qui pourraient être à peu près applicables à vos besoins:

• En tant qu'administrateur système, je veux semer le système avec des balises valides afin que les utilisateurs puissent choisir parmi certaines valeurs lors de la première utilisation de la fonction de balisage.
• En tant qu'utilisateur du système, je veux pouvoir rechercher un produit par son nom afin de pouvoir l'étiqueter plus tard.
• En tant qu'utilisateur du système, je veux pouvoir lire la description d'un produit afin de pouvoir décider quelles balises il doit avoir.
• En tant qu'utilisateur du système, je veux pouvoir voir une image du produit afin de pouvoir décider quelles balises il doit avoir.
• En tant qu'utilisateur du système, je veux pouvoir attacher une seule étiquette à un seul produit.
• En tant qu'utilisateur du système, je veux pouvoir supprimer une seule étiquette d'un seul produit.
• En tant qu'utilisateur du système, je veux pouvoir attacher une seule étiquette à plusieurs produits.
• En tant qu'utilisateur du système, je veux pouvoir attacher plusieurs étiquettes à un seul produit.
• En tant qu'administrateur système, je veux voir une liste distincte de balises utilisées dans le système afin que je puisse décider si certaines d'entre elles sont des doublons.
• En tant qu'administrateur système, je souhaite consolider les balises dupliquées.

... et je pourrais continuer.

Je doute que l'un d'eux soit si réaliste que vous les utiliserez, mais j'espère qu'ils illustrent le genre de détails que vous pouvez consulter avec vos histoires d'utilisateurs.

Si une User Story ne peut vraiment pas être subdivisée en plus petites histoires et que vous la jugez toujours trop grande pour tenter de l'implémenter en une seule fois, vous pouvez la diviser en tranches verticales. Il s'agit d'une technique qui consiste à ne fournir qu'une partie de la fonctionnalité sous chaque User Story, mais chaque partie étant une tranche testable à travers toutes les couches pertinentes de la technologie, par exemple pour un site Web, cela pourrait signifier changer la base de données, l'application et les couches d'interface utilisateur. Évitez d'avoir une User Story pour le travail de la base de données, une autre pour l'application et une autre pour l'interface utilisateur, car elles ne seront pas testables individuellement.

Prenant une licence encore plus artistique, je pourrais diviser "En tant qu'utilisateur du système, je veux pouvoir attacher une seule étiquette à un seul produit." dans les tranches verticales suivantes:

• En tant qu'utilisateur du système qui regarde un seul produit, je veux pouvoir consulter une liste de balises afin de pouvoir décider laquelle appliquer.
• En tant qu'utilisateur du système qui regarde un seul produit, ayant décidé d'une étiquette à appliquer à ce produit, je veux pouvoir l'appliquer.
• En tant qu'utilisateur du système qui regarde un seul produit, après avoir appliqué une étiquette à ce produit, je veux un message de confirmation à l'écran me disant qu'il a bien enregistré.

Chacun de ces éléments peut être testé - s'il n'est pas particulièrement précieux en soi.

Il existe des livres écrits dans le seul but de trouver la bonne façon de décrire et de décomposer vos besoins. Ce n'est donc pas une tâche facile.

Souvent, je trouve des équipes de développement qui recherchent des solutions complexes au lieu des plus simples. Cela peut être dû à l'histoire elle-même ou au fait que l'équipe souhaite opter pour une solution trop complexe qui non seulement résout cette histoire mais jette également les bases des histoires x, y et z. C'est une bonne intention, mais cela laisse planer un champ où le même travail peut être effectué avec moins de travail. Il est toujours difficile de juger de la quantité de design à consacrer à une histoire pour ne pas ruiner les histoires futures en gâchant la conception. Cette décision appartient à l'équipe.

En tant que propriétaire de produit, vous ne pouvez influencer cela qu'en décomposant les histoires en petits morceaux. Vous devriez vous demander: l'histoire est-elle la plus petite solution à laquelle nous pouvons penser en ce moment? Pouvons-nous le décomposer en ensembles de fonctionnalités réduits qui deviendront un jour le "grand système d'étiquetage flexible que j'ai toujours voulu". Vous pouvez commencer avec un système de balises pour une seule balise, puis l'étendre pour inclure une liste de balises présélectionnées, puis laisser l'utilisateur définir des balises, etc.

Pour l'équipe de développement, cela se résume à: Pouvons-nous trouver une approche plus simple pour réaliser l'histoire, tout en ayant une architecture solide qui accomplit le travail aujourd'hui sans compromettre les fonctionnalités futures.

Si vous êtes ouvert à accepter des solutions intermédiaires et que l'équipe de développement essaie également de proposer la solution la plus simple mais la plus efficace, vous trouverez probablement le bon endroit où la taille des histoires que vous voulez faire est correcte (la plus petite sera la meilleure) . Cela ne veut pas dire que vous n'avez que de petites histoires. Certains sont plus gros que d'autres, c'est juste un fait que vous devez accepter, ou s'ils sont trop gros, puis décomposez les histoires en petits morceaux.