INVEST, la meilleure recette pour écrire ses US ? 🍕
Certains modes de fonctionnement en Agile ne sont pas forcément applicables partout (Loi de Conway inversée, Règle des "deux pizzas" d’Amazon…) - mais un principe de rédaction des User Stories provenant de l’Extreme Programming gagnerait à être davantage connu : le modèle INVEST.
Premièrement imaginé en 2003, puis mis à jour en 2011 par son auteur Bill Wake (coach en développement logiciel) dans l’acronyme INVEST chaque lettre symbolise une notion.
Pour que cela paraisse moins abstrait et comme nous parlions de pizza plus haut, voici donc la recette INVEST :
I – Indépendant : les US sont idéalement autonomes, sans devoir attendre que d’autres soient déployées. L’interdépendance et le chevauchement de cibles/fonctionnalités mènent à la confusion. On peut voir ici un parallèle avec la préparation de chacun des ingrédients d’une pizza (pâte, fromage, sauce, garnitures…) de manière compartimentée.
N – Négociable : en agilité, les notions de collaboration, d’évolution et d'adaptation au changement sont intrinsèques, c’est donc naturel qu'après des POC, Spikes, Refinements, Tres Amigos ou autres, une US évolue au rythme des échanges de l’équipe quant à la façon de faire, aux solutions envisagées… à la manière dont on ajusterait les dosages, les ingrédients de manière itérative.
V – Valeur : l’US doit apporter de la valeur pour le métier et pour l'utilisateur final. Faire primer l’utilité et le fonctionnel au-delà du technique pur. Pour se représenter l’essence d’une pizza, une seule part devrait suffire. La valeur pour le métier est donc de proposer un moyen de satisfaire la faim, conviviale ; pour l’utilisateur final ses choix et préférences en matière de goût seront satisfaits. Une story de type « En tant que pizzaiolo je veux que mon four fasse telle taille et soit à telle température... » ne peut pas, en ce sens, être une User story (l’utilisateur final, celui qui mangera la pizza) mais sera plutôt une Technical story, ayant attrait à la réalisation en coulisses.
Evitez donc les US « en tant que développeur je veux configurer Jenkins pour de l’intégration continue » ou autres.
E – Estimable : l’expérience de l’équipe aide à quantifier le temps, l’effort nécessaire pour la réalisation de l'US, ce qui permet de planifier selon les effectifs et itérations. Ici, il n’y a pas vraiment de science exacte, il peut y avoir des imprévus, dépendances… On essaie d’obtenir des « petites » tâches réalisables indépendamment. Confectionner la pâte, la pétrir, la laisser reposer : tout est plus ou moins quantifiable en termes de moyens et de temps.
S – Small (2003) puis Scalable (2011) : de petites US bien découpées (demandant quelques jours/homme au maximum de réalisation) répondront plus précisément et plus rapidement à un besoin, plutôt qu’une US complexe au scope trop large qui demanderait un mois à terminer.
Pour le côté scalable, une notion peut permettre différentes variations. Exemple : « Acheter une pizza » pourra évoluer et s’adapter aux besoins de l’entreprise, qu’il s’agisse d’un client devant un foodtruck, d’un autre qui l’achète surgelée au supermarché, ou de celui qui passe commande par une application sur son mobile.
T – Testable : Il faut effectivement pouvoir goûter la part de pizza pour s’assurer de sa bonne réalisation (l’attendu) avant de la proposer au client. En pratique écrire les tests au plus tôt permet de savoir quand le but de l’US est atteint. La lecture d’une bonne US doit permettre de déduire les tests nécessaires, notamment avec des critères d’acceptation.
En somme INVEST est à garder en tête lorsque l’on discute autour d’une US, de son découpage. Une US bien comprise permet d'être une US bien développée et bien testée.
Pensez également en privilégiant le bout en bout plutôt qu’une bribe de fonctionnalité lorsque c’est applicable, en se mettant à la place de l’utilisateur. Souvent les équipes se concentrent sur leur pièce du puzzle, au détriment de l’ensemble.