Bien définir en Agile : I.N.V.E.S.T.ir dans vos stories.

agile-dilbert-story

Dans les méthodes agiles, un récit utilisateur ou user story (story dans le reste du post), est une phrase simple dans le langage de tous les jours permettant de décrire avec suffisamment de précision le contenu d’une fonctionnalité à développer. La phrase contient généralement trois éléments descriptif de la fonctionnalité : Qui ? Quoi ? Pourquoi ?

Il suffit d’écrire une phrase avec la structure “En tant que <qui>, je veux <quoi> afin de <pourquoi>“.  Toutefois, il arrive souvent que la story soit mal exprimée, ce qui mène à une mauvaise compréhension généralement suivie par une implémentation insatisfaisante. Comment donc faire lors de cet exercice pour écrire le bon récit et livrer ce que demande le client ?

Pour ce faire, il faut se rappeler des caractéristiques fondamentales d’une story, qui se résument en l’acronyme : I.N.V.E.S.T :

 I pour Indépendant :

Les stories doivent être indépendants l’une de l’autre. Ce qui permettra a l’équipe de les réaliser et les livrer sans qu’ils affectent l’ensemble des livrables.

 N pour Négociable.. et Négocié :

Un récit doit être le fruit d’une collaboration entre l’équipe et le client, afin de fournir le maximum de valeur pour ce dernier. Un bon récit ne représente pas un contrat détaillé de fonctionnalités, mais se focalise sur l’essence de la fonctionnalité. La négociation est un élément fondamental pour comprendre l’essence du besoin du client.

 V pour “valuable” (Précieux) :

Une story doit avoir de la valeur pour le client. C’est la principale caractéristique d’une story. Généralement, cette caractéristique est perdue lors d’un mauvais découpage de stories. Un bon découpage est un découpage qui livre de la valeur pour le client à chaque story. Imaginez que vous découpez un gâteau à couches par exemple, Personne ne voudra d’un gâteau découpé horizontalement, tout le monde veut plutôt un morceau qui contient l’ensemble des couches. C’est de même pour la story. Ces couches peuvent être assimiles aux couches réseau, persistance, business et interface utilisateur etc. Livrer un ensemble fonctionnel, partie par partie au client a toujours de la valeur.

 E pour Estimable :

Une story doit être estimable. Sans forcément avoir un estimé exact, nous pouvons en donner assez pour aider le client à prioriser et planifier l’implémentation des stories. C’est le rôle de l’équipe d’estimer, ceci dépendra éventuellement de l’expérience.

Il arrive souvent que l’équipe n’a pas suffisamment d’informations pour estimer. Dans ce cas, cette dernière doit diviser la story en un “Spike” ayant une durée fixe (time-boxed) et permettant d’avoir assez d’information pour pouvoir estimer le reste de la story.

S pour Small (Petit) :

Une bonne story demande généralement peu de personnes-semaines (ou même peu de personnes-jours) pour être réalisée. Souvent, il viendrait à l’esprit que d’avoir moins de temps et de description mènerait à une mauvaise interprétation, mais l’objectif essentiel derrière ceci est de laisser les détails être élaborées par les conversations directes avec le client.

T pour testable

Ecrire une story implique une promesse cachée : “Je connais suffisamment ce que je veux que je pourrais écrire un test pour”. L’équipe devrait demander au client de l’information sur comment il compte tester sa story. Le plutôt que les tests sont définis, plus vite l’objectif réel est atteint. Généralement, si un client ne sait pas comment il va tester sa story, ceci montre que cette dernière n’est pas assez claire, ou qu’elle n’a pas beaucoup de valeur, ou que ce dernier a plutôt besoin d’aide pour la tester. Dernièrement, les tests non fonctionnels peuvent être considérées comme des requis qui doivent être testées. En déterminant comment réaliser ces tests, l’équipe se rend compte les besoins réels du client.

Ainsi donc, si vous faites partie d’une équipe Agile, et que vous participiez de près ou de loin a l’écriture ou la réalisation de stories, I.N.V.E.S.T. est votre ami. Une fois la story bien définie, écrire des taches pour réaliser cette dernière est un jeu d’enfants avec S.M.A.R.T, ce que je couvrirais dans un post prochain !

Anis Berejeb

Anis est avant tout un passioné de l'agilité et du développement. Avec plus de 15 ans dans le domaine du développement web, son expertise combine des connaissances accrues dans l'ensemble des notions partant du développement logiciel jusqu'à l'organisation des équipes dans les environnements agiles à grande échelle.

You may also like...