Principe INVEST pour la création d’histoires d’utilisateurs
En plus d’un format standardisé et d’éléments complets, une bonne user story doit également suivre les principes INVEST : 1. Je dépends ; 2. Négociable ; 3. Précieux ; 4. Estimable ; 5. Petit ; 6. T estable.
1. Indépendant – Il est important de rendre une user story aussi indépendante que possible des autres user stories. Le maintien de l’indépendance entre les user stories facilite non seulement la hiérarchisation et l’alignement, facilite la planification des versions et des itérations, facilite la compréhension indépendante, le suivi, la mise en œuvre, les tests et la livraison fréquente, mais clarifie également la portée de l’estimation de la taille de la user story et donc le biais d’estimation. plus petit.
2. Négociable – Le contenu d’une user story est négociable ; une user story n’est pas un contrat. Une user story est juste une courte description de la user story sans trop de détails ; des détails spécifiques sont produits lors de la phase de communication. Une user story avec trop de détails limite en fait l’utilisateur, les idées de l’équipe et la communication.
3. Précieux – Chaque histoire doit être précieuse pour le client (qu’il s’agisse d’un utilisateur, d’un acheteur ou d’un rôle interne à l’entreprise). Les user stories sont précieuses pour l’utilisateur final, elles doivent donc être écrites du point de vue de l’utilisateur, décrivant une FONCTION plutôt qu’une TÂCHE.
Cette fonctionnalité facilite le passage d’un style de travail traditionnel basé sur des directives à un style de travail autonome axé sur la valeur pour les membres de l’équipe de développement et de test, de sorte que tous les membres de l’équipe connaissent la valeur du travail qu’ils effectuent chaque jour.
4. Estimable (peut être évalué) – Une partie très importante de la réunion de planification est l’estimation des points d’histoire. Il s’agit en fait d’une estimation grossière de la User Story à développer afin que l’équipe puisse connaître la complexité (charge de travail) de cette user story.
L’accent est mis sur si la user story peut être complétée dans l’itération en cours selon les conditions de réception de cette user story et les DoD (critères de complétion) définis par l’équipe, et si elle ne peut pas être complétée, la raison est donnée et le PO décide de diviser ou de reconcevoir la user story.
Les problèmes qui rendent difficile l’estimation de l’histoire par les développeurs proviennent du manque de connaissance du domaine (auquel cas plus de communication est nécessaire), ou de l’histoire trop volumineuse (auquel cas elle doit être découpée en plus petits morceaux).
5. Petit – Une bonne histoire doit être aussi courte que possible en termes de charge de travail, de préférence pas plus de 10 personnes idéales/jour, au moins pour s’assurer qu’elle est terminée en une seule itération. Plus la user story est grande, plus le risque est grand dans la planification, l’estimation de la charge de travail, etc.
6. Testable (testable) – Une user story doit être testable afin de confirmer qu’elle peut être complétée. Si une user story n’est pas testable, vous ne pouvez pas savoir quand elle sera terminée. Un exemple de user story non testable : le logiciel doit être facile à utiliser.
Trois lignes directrices
Une user story est fondamentalement une bonne user story lorsque les principes INVEST sont suivis. Ensuite, nous nous concentrons sur trois lignes directrices pour aider à mieux respecter les principes lors de la production de user stories.
Les trois directives sont : un utilisateur, une valeur complète et aucune dépendance.
1. Un seul type d’utilisateurs – Incluez un seul type d’utilisateurs, car plusieurs utilisateurs ont souvent des nuances. Il s’agit généralement d’un utilisateur typique, souvent avec un besoin commun quelconque.
2. Valeur complète – Offrez une valeur client dans son intégralité. Une user story complète signifie que lorsque cette histoire est terminée, l’utilisateur peut atteindre un objectif clair et significatif.
3. Non-dépendance – Les trois types courants de dépendances sont : le chevauchement, la séquence et le confinement.
En général, les points fonctionnels qui se chevauchent entre les étages doivent être évités ; les relations séquentielles sont une réalité et peuvent être résolues par certains moyens dans la plupart des cas ; et les relations d’inclusion sont utiles pour les systèmes complexes, avec des implications pour la planification des versions et des plans d’itération qui nécessitent une attention particulière.
Dépendances qui se chevauchent
Les dépendances qui se chevauchent sont la forme de dépendances qui causent le plus de problèmes, en particulier lorsque plusieurs user stories contiennent plusieurs parties différentes qui se chevauchent. Il est difficile de trouver un ensemble de user stories pouvant représenter l’ensemble des fonctionnalités pour ce produit minimum viable, qui devrait contenir et ne contenir que les fonctionnalités nécessaires une fois.
Solution
Supprimez les parties qui se chevauchent en tant que user stories distinctes.
Fractionnement rationnel des user stories et maintien des chevauchements dans une seule des user stories les plus cohérentes.
Utilisez le modèle de développement Scrum.
Dépendances séquentielles
La dépendance séquentielle signifie que pour qu’une user story soit terminée, une ou plusieurs autres user stories doivent être terminées avant elle. Les dépendances séquentielles sont généralement inoffensives et il existe des moyens d’atténuer ces dépendances.
Dans une perspective de développement agile, l’ensemble du système évolue progressivement d’un produit initial minimum viable à un produit robuste, chaque étape ultérieure s’appuyant sur les précédentes.
Mais d’un autre point de vue, les dépendances séquentielles inutiles rendent plus difficile le classement et la hiérarchisation, ce qui affecte à son tour le développement des plans de publication et d’itération et rend plus difficile l’estimation de la taille des user stories.
Solution
Faites en sorte que les user stories d’une itération soient aussi exemptes que possible de dépendances intrinsèques.
Ne conserver que les dépendances unidirectionnelles entre les itérations, avec uniquement des dépendances unidirectionnelles dans le temps entre les histoires des itérations ultérieures et les histoires des itérations précédentes (dépendances directes).
Supprimer les dépendances principales en tant qu’histoires distinctes et ne pas mélanger les exigences dépendantes et non dépendantes dans une seule histoire.
Inclusion de dépendances
Les dépendances contenues font référence à l’utilisation de la gestion hiérarchique dans l’organisation des user stories, telles que la gestion commune des histoires de fonctionnalités à deux niveaux, où une fonctionnalité contient plusieurs user stories, constituant ainsi une dépendance contenue de la fonctionnalité sur ses histoires subordonnées.
Solution
Le niveau user-story est utilisé pour la planification des itérations, en évitant la planification des itérations grossière avec le niveau fonctionnalité, qui peut être utilisé pour la planification des versions.
Le niveau de fonctionnalité peut également être divisé jusqu’à ce qu’il soit au niveau d’une fonctionnalité commercialisable minimale, et les user stories qu’il contient peuvent être regroupées séparément dans les fonctionnalités nouvellement divisées.
Suivant le concept de produit minimum viable, une fonctionnalité est implémentée dans plusieurs itérations de plusieurs user stories, chacune pouvant aboutir à un livrable potentiel ou fournir des commentaires internes ou externes.
Les références
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский