{"id":10362,"date":"2022-02-07T10:08:40","date_gmt":"2022-02-07T10:08:40","guid":{"rendered":"https:\/\/www.cybermedian.com\/fr\/?p=10362"},"modified":"2026-04-20T09:12:27","modified_gmt":"2026-04-20T09:12:27","slug":"comment-ecrire-une-histoire-dutilisateur-efficace-avec-les-principes-invest","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/fr\/how-to-write-effective-user-story-with-invest-principles\/","title":{"rendered":"Comment \u00e9crire une histoire d’utilisateur efficace avec les principes INVEST ?"},"content":{"rendered":"

Principe INVEST pour la cr\u00e9ation d’histoires d’utilisateurs<\/span><\/h3>\n

En plus d’un format standardis\u00e9 et d’\u00e9l\u00e9ments complets, une bonne\u00a0user story<\/a>\u00a0doit \u00e9galement suivre les principes\u00a0INVEST<\/strong>\u00a0: 1.\u00a0Je<\/strong>\u00a0d\u00e9pends ;\u00a02.\u00a0N\u00e9gociable<\/strong>\u00a0;\u00a03.\u00a0Pr\u00e9cieux<\/strong>\u00a0;\u00a04.\u00a0Estimable<\/strong>\u00a0;\u00a05.\u00a0Petit<\/strong>\u00a0;\u00a06.\u00a0T<\/strong>\u00a0estable.<\/p>\n

<\/p>\n

1.\u00a0Ind\u00e9pendant<\/strong>\u00a0\u2013 Il est important de rendre une user story aussi ind\u00e9pendante que possible des autres user stories.\u00a0Le maintien de l’ind\u00e9pendance entre les user stories facilite non seulement la hi\u00e9rarchisation et l’alignement, facilite la planification des versions et des it\u00e9rations, facilite la compr\u00e9hension ind\u00e9pendante, le suivi, la mise en \u0153uvre, les tests et la livraison fr\u00e9quente, mais clarifie \u00e9galement la port\u00e9e de l’estimation de la taille de la user story et donc le biais d’estimation. plus petit.<\/p>\n

2.\u00a0N\u00e9gociable<\/strong>\u00a0\u2013 Le contenu d’une user story est n\u00e9gociable ;\u00a0une user story n’est pas un contrat.\u00a0Une user story est juste une courte description de la user story sans trop de d\u00e9tails ;\u00a0des d\u00e9tails sp\u00e9cifiques sont produits lors de la phase de communication.\u00a0Une user story avec trop de d\u00e9tails limite en fait l’utilisateur, les id\u00e9es de l’\u00e9quipe et la communication.<\/p>\n

3.\u00a0Pr\u00e9cieux<\/strong>\u00a0– Chaque histoire doit \u00eatre pr\u00e9cieuse pour le client (qu’il s’agisse d’un utilisateur, d’un acheteur ou d’un r\u00f4le interne \u00e0 l’entreprise).\u00a0Les user stories sont pr\u00e9cieuses pour l’utilisateur final, elles doivent donc \u00eatre \u00e9crites du point de vue de l’utilisateur, d\u00e9crivant une FONCTION plut\u00f4t qu’une T\u00c2CHE.<\/p>\n

Cette fonctionnalit\u00e9 facilite le passage d’un style de travail traditionnel bas\u00e9 sur des directives \u00e0 un style de travail autonome ax\u00e9 sur la valeur pour les membres de l’\u00e9quipe de d\u00e9veloppement et de test, de sorte que tous les membres de l’\u00e9quipe connaissent la valeur du travail qu’ils effectuent chaque jour.<\/p>\n

4.\u00a0Estimable<\/strong>\u00a0(peut \u00eatre \u00e9valu\u00e9) – Une partie tr\u00e8s importante de la r\u00e9union de planification est l’estimation des points d’histoire.\u00a0Il s’agit en fait d’une estimation grossi\u00e8re de la User Story \u00e0 d\u00e9velopper afin que l’\u00e9quipe puisse conna\u00eetre la complexit\u00e9 (charge de travail) de cette user story.<\/p>\n

L’accent est mis sur si la user story peut \u00eatre compl\u00e9t\u00e9e dans l’it\u00e9ration en cours selon les conditions de r\u00e9ception de cette user story et les DoD (crit\u00e8res de compl\u00e9tion) d\u00e9finis par l’\u00e9quipe, et si elle ne peut pas \u00eatre compl\u00e9t\u00e9e, la raison est donn\u00e9e et le PO d\u00e9cide de diviser ou de reconcevoir la user story.<\/p>\n

Les probl\u00e8mes qui rendent difficile l’estimation de l’histoire par les d\u00e9veloppeurs proviennent du manque de connaissance du domaine (auquel cas plus de communication est n\u00e9cessaire), ou de l’histoire trop volumineuse (auquel cas elle doit \u00eatre d\u00e9coup\u00e9e en plus petits morceaux).<\/p>\n

5.\u00a0Petit<\/strong>\u00a0– Une bonne histoire doit \u00eatre aussi courte que possible en termes de charge de travail, de pr\u00e9f\u00e9rence pas plus de 10 personnes id\u00e9ales\/jour, au moins pour s’assurer qu’elle est termin\u00e9e en une seule it\u00e9ration.\u00a0Plus la user story est grande, plus le risque est grand dans la planification, l’estimation de la charge de travail, etc.<\/p>\n

6.\u00a0Testable<\/strong>\u00a0(testable) \u2013 Une user story doit \u00eatre testable afin de confirmer qu’elle peut \u00eatre compl\u00e9t\u00e9e.\u00a0Si une user story n’est pas testable, vous ne pouvez pas savoir quand elle sera termin\u00e9e.\u00a0Un exemple de user story non testable : le logiciel doit \u00eatre facile \u00e0 utiliser.<\/p>\n

Trois lignes directrices<\/span><\/h3>\n

Une user story est fondamentalement une bonne user story lorsque les principes INVEST sont suivis.\u00a0Ensuite, nous nous concentrons sur trois lignes directrices pour aider \u00e0 mieux respecter les principes lors de la production de user stories.<\/p>\n

Les trois directives sont\u00a0: un utilisateur, une valeur compl\u00e8te et aucune d\u00e9pendance.<\/p>\n

1.\u00a0Un seul type d’utilisateurs<\/strong>\u00a0– Incluez un seul type d’utilisateurs, car plusieurs utilisateurs ont souvent des nuances.\u00a0Il s’agit g\u00e9n\u00e9ralement d’un utilisateur typique, souvent avec un besoin commun quelconque.<\/p>\n

2.\u00a0Valeur compl\u00e8te<\/strong>\u00a0– Offrez une valeur client dans son int\u00e9gralit\u00e9.\u00a0Une user story compl\u00e8te signifie que lorsque cette histoire est termin\u00e9e, l’utilisateur peut atteindre un objectif clair et significatif.<\/p>\n

3.\u00a0Non-d\u00e9pendance<\/strong>\u00a0– Les trois types courants de d\u00e9pendances sont\u00a0: le chevauchement, la s\u00e9quence et le confinement.<\/p>\n

En g\u00e9n\u00e9ral, les points fonctionnels qui se chevauchent entre les \u00e9tages doivent \u00eatre \u00e9vit\u00e9s\u00a0;\u00a0les relations s\u00e9quentielles sont une r\u00e9alit\u00e9 et peuvent \u00eatre r\u00e9solues par certains moyens dans la plupart des cas\u00a0;\u00a0et les relations d’inclusion sont utiles pour les syst\u00e8mes complexes, avec des implications pour la planification des versions et des plans d’it\u00e9ration qui n\u00e9cessitent une attention particuli\u00e8re.<\/p>\n

D\u00e9pendances qui se chevauchent<\/strong><\/p>\n

Les d\u00e9pendances qui se chevauchent sont la forme de d\u00e9pendances qui causent le plus de probl\u00e8mes, en particulier lorsque plusieurs user stories contiennent plusieurs parties diff\u00e9rentes qui se chevauchent.\u00a0Il est difficile de trouver un ensemble de user stories pouvant repr\u00e9senter l’ensemble des fonctionnalit\u00e9s pour ce produit minimum viable, qui devrait contenir et ne contenir que les fonctionnalit\u00e9s n\u00e9cessaires une fois.<\/p>\n

Solution<\/strong><\/p>\n

Supprimez les parties qui se chevauchent en tant que user stories distinctes.
\nFractionnement rationnel des user stories et maintien des chevauchements dans une seule des user stories les plus coh\u00e9rentes.
\nUtilisez le mod\u00e8le de d\u00e9veloppement Scrum.<\/p>\n

D\u00e9pendances s\u00e9quentielles<\/strong><\/p>\n

La d\u00e9pendance s\u00e9quentielle signifie que pour qu’une user story soit termin\u00e9e, une ou plusieurs autres user stories doivent \u00eatre termin\u00e9es avant elle.\u00a0Les d\u00e9pendances s\u00e9quentielles sont g\u00e9n\u00e9ralement inoffensives et il existe des moyens d’att\u00e9nuer ces d\u00e9pendances.<\/p>\n

Dans une perspective de d\u00e9veloppement agile, l’ensemble du syst\u00e8me \u00e9volue progressivement d’un produit initial minimum viable \u00e0 un produit robuste, chaque \u00e9tape ult\u00e9rieure s’appuyant sur les pr\u00e9c\u00e9dentes.<\/p>\n

Mais d’un autre point de vue, les d\u00e9pendances s\u00e9quentielles inutiles rendent plus difficile le classement et la hi\u00e9rarchisation, ce qui affecte \u00e0 son tour le d\u00e9veloppement des plans de publication et d’it\u00e9ration et rend plus difficile l’estimation de la taille des user stories.<\/p>\n

Solution<\/strong><\/p>\n

Faites en sorte que les user stories d’une it\u00e9ration soient aussi exemptes que possible de d\u00e9pendances intrins\u00e8ques.
\nNe conserver que les d\u00e9pendances unidirectionnelles entre les it\u00e9rations, avec uniquement des d\u00e9pendances unidirectionnelles dans le temps entre les histoires des it\u00e9rations ult\u00e9rieures et les histoires des it\u00e9rations pr\u00e9c\u00e9dentes (d\u00e9pendances directes).
\nSupprimer les d\u00e9pendances principales en tant qu’histoires distinctes et ne pas m\u00e9langer les exigences d\u00e9pendantes et non d\u00e9pendantes dans une seule histoire.<\/p>\n

Inclusion de d\u00e9pendances<\/strong><\/p>\n

Les d\u00e9pendances contenues font r\u00e9f\u00e9rence \u00e0 l’utilisation de la gestion hi\u00e9rarchique dans l’organisation des user stories, telles que la gestion commune des histoires de fonctionnalit\u00e9s \u00e0 deux niveaux, o\u00f9 une fonctionnalit\u00e9 contient plusieurs user stories, constituant ainsi une d\u00e9pendance contenue de la fonctionnalit\u00e9 sur ses histoires subordonn\u00e9es.<\/p>\n

Solution<\/strong><\/p>\n

Le niveau user-story est utilis\u00e9 pour la planification des it\u00e9rations, en \u00e9vitant la planification des it\u00e9rations grossi\u00e8re avec le niveau fonctionnalit\u00e9, qui peut \u00eatre utilis\u00e9 pour la planification des versions.<\/p>\n

Le niveau de fonctionnalit\u00e9 peut \u00e9galement \u00eatre divis\u00e9 jusqu’\u00e0 ce qu’il soit au niveau d’une fonctionnalit\u00e9 commercialisable minimale, et les user stories qu’il contient peuvent \u00eatre regroup\u00e9es s\u00e9par\u00e9ment dans les fonctionnalit\u00e9s nouvellement divis\u00e9es.<\/p>\n

Suivant le concept de produit minimum viable, une fonctionnalit\u00e9 est impl\u00e9ment\u00e9e dans plusieurs it\u00e9rations de plusieurs user stories, chacune pouvant aboutir \u00e0 un livrable potentiel ou fournir des commentaires internes ou externes.<\/p>\n

 <\/p>\n

Les r\u00e9f\u00e9rences<\/p>\n