Histoire de l'utilisateur

Une user story est une brève description d'un besoin, formulée du point de vue de la personne qui en bénéficiera. Elle se présente généralement sous la forme d'un rôle, d'une fonctionnalité souhaitée et de la raison de ce besoin. Issue des pratiques de programmation extrême, elle est devenue le format dominant pour exprimer le travail dans le développement itératif.

Son objectif est souvent mal compris. Le récit n'est pas un cahier des charges ; il sert à encourager le dialogue. Dans sa formulation originale, les récits servaient de support à une discussion entre les personnes souhaitant cette fonctionnalité et celles qui la développeront. Le texte a pour but de garantir cette discussion, et non de la remplacer. Les équipes qui considèrent la fiche comme une exigence complète ont adopté le format et abandonné le mécanisme.

La justification est l'élément le plus important et pourtant le plus souvent rédigé avec négligence. Expliquer pourquoi une fonctionnalité est souhaitée permet à une équipe de proposer une solution différente, souvent plus efficace, au même besoin, et de déprioriser honnêtement une tâche lorsque la justification initiale s'avère faible. Les user stories dont la justification se contente de réaffirmer la fonctionnalité, comme vouloir un bouton pour pouvoir appuyer dessus, ne communiquent rien et empêchent toute discussion constructive.

Le dimensionnement est crucial car une user story doit pouvoir être réalisée en une itération et offrir une expérience utilisateur concrète. Les user stories trop volumineuses sont impossibles à terminer ou à évaluer, tandis que celles décomposées en couches techniques, comme la création séparée d'une table de base de données ou d'un composant d'interface, ne produisent aucun résultat observable individuellement. Le découpage vertical, où chaque user story traverse chaque couche pour aboutir à une fonctionnalité simple mais complète, permet de préserver la capacité de démonstration et d'apprentissage.

Le format est une convention plutôt qu'une exigence, et son application rigide engendre des absurdités. Les tâches techniques sans utilisateur direct, comme la mise à jour d'une dépendance ou l'amélioration de l'observabilité, ne correspondent pas au modèle ; les y contraindre revient à créer un utilisateur artificiel qui souhaite une mise à jour de la bibliothèque. Il est plus honnête et plus utile de consigner ces tâches clairement, en expliquant leur justification, que de les déformer pour se conformer à un format.

Les critères d'acceptation permettent de tester un récit et en font partie intégrante, et non un élément distinct. Ils définissent les conditions dans lesquelles le récit sera considéré comme complet, y compris les cas limites et les chemins d'erreur que la forme narrative omet. Sans eux, la notion de complétude devient subjective, et les désaccords apparaissent généralement lors de la relecture, moment où leur résolution est la plus coûteuse.

Les user stories s'accumulent et deviennent ingérables si elles ne sont jamais élaguées. Les éléments rédigés il y a plusieurs mois décrivent un produit et un marché qui ont évolué depuis, et une liste de plusieurs centaines de user stories n'est qu'un document que personne ne lit, et non un plan. Supprimer régulièrement les user stories qui ne seront pas réalisées est certes contraignant, mais bien plus utile que de les conserver indéfiniment.

Puisque la valeur dépend de la conversation plutôt que du produit, l'efficacité est déterminée par la participation des bonnes personnes. En pratique, ce format est utilisé au sein de le développement de produits avec le besoin sous-jacent mis en évidence par recherche d'utilisateurs plutôt que de supposer, et les organisations qui développent cette capacité en interne établissent généralement la pratique de rédaction et de perfectionnement au sein d'un département des produits pour que les histoires naissent de problèmes validés.