Intermédiaire

Jetez vos User Stories

Lors de mes accompagnements, je suis régulièrement questionné sur le sujet de la gestion de la documentation dans les contextes agiles. Quand on me pose la question : « Comment doit-on gérer la documentation en agilité ? », en bon coach Agile, je réponds : « Ca dépend ! ». Pour aller plus loin, je vous propose de développer les réflexions qui ont émergé au travers de mes différentes expériences.

De quelle documentation parle-t-on ?

Généralement, la question de la documentation est amenée comme ceci : « Est-ce que l’on doit rédiger des spécifications sur un projet agile ? ».

Il m’arrive parfois de rencontrer des contextes où les équipes se lancent dans la rédaction de spécifications par habitude. Dans d’autres contextes moins courant, certaines équipes ont totalement abandonné leurs spécifications, pensant qu’en agile on ne fait plus de documentation. Dans ce second cas, les équipes ont interprété un peu hâtivement la valeur du manifeste Agile qui dit : « Des logiciels opérationnels plus qu’une documentation exhaustive ». Cette valeur ne nous dit pas qu’il ne faut plus de documentation, mais qu’il est primordial de définir quelle documentation doit être produite, à quel moment doit-on l’écrire et quel est le bon niveau de détail à y mettre. Mais qu’est-ce qu’un bon niveau de détail pour une documentation ?

Tout d’abord, il faut s’assurer que la documentation reflète la réalité du logiciel, mais il faut également savoir optimiser l’effort à fournir pour la rédiger. Généralement, une documentation extrêmement détaillée nécessite une charge de rédaction conséquente. Si celle-ci n’est pas régulièrement revue et mise à jour, elle peut rapidement devenir obsolète. Cette situation génère souvent du gaspillage pour le projet et beaucoup de frustrations pour les équipes.

A quoi sert la documentation ?

Certaines questions fondamentales sont rarement posées : « A quoi sert la documentation ? » ou bien « A qui s’adresse-t-elle ? ». Dans la plupart des contextes traditionnels que j’ai rencontrés, la documentation de référence est la spécification fonctionnelle détaillée. Cette spécification a principalement deux vocations :

  1. Exprimer un besoin pour donner du travail à ceux qui vont réaliser le produit
  2. Conserver la connaissance sur le produit (processus métier, fonctionnalités, règles de gestion…).

On se retrouve ainsi avec une seule documentation pour deux usages différents.

User Story

La réponse de l’agilité consiste à remplacer la spécification fonctionnelle détaillée par des éléments de spécifications plus digestes uniquement pour répondre au premier des deux usages (donner du travail à ceux qui vont réaliser le produit). On va rédiger ces petits éléments de spécification « juste à temps », quelques jours avant de les réaliser, et on ne cherche pas à tout spécifier dans le détail dès le démarrage du projet.

Le formalisme fréquemment utilisé pour ces éléments de spécification est la « User Story », dont l’intérêt est de renseigner sur le « pourquoi ? » et le « pour qui ? » de ce qui doit être réalisé. Attention, il est important de partager une macro-description des grandes fonctionnalités attendues afin de garder une vision globale sur le produit.

Par contre, la User Story ne répond pas au second usage de la spécification, à savoir la conservation de la connaissance produit. En effet, si on suit le Modèle 3C (Card, Conversation, Confirmation) formalisé dans eXtrem Programing, une User Story doit être décrite sur une carte dans le but d’inviter les parties prenantes à une discussion permettant de favoriser une compréhension partagée du besoin. Ainsi, la carte de la User Story est un artefact favorisant l’échange et le partage autour du besoin dans le seul but d’aligner tout le monde sur ce qu’il y a faire. Une fois que le besoin est réalisé, la carte peut (doit ?) être jetée. Celle-ci n’a plus aucune utilité.

Et la connaissance alors ?

Mais alors, si on jette la User Story, où est conservée la connaissance produit ? Il n’y a pas de réponse toute faite, tout dépend des contraintes de votre organisation. Je vous propose de prendre deux exemples très opposés pour essayer de trouver une réponse adaptée.

  • Premier exemple, vous êtes dans une organisation avec un taux de turnover très faible qui a embauché des développeurs en interne.
  • Autre exemple, vos développeurs sont externalisés et le taux de turnover est très élevé.

Pensez-vous devoir gérer la conservation de la connaissance produit de la même façon dans ces deux contextes ?

A priori, dans le premier cas, vous pouvez vous contenter d’une documentation minimaliste en mettant l’accent sur un code lisible, maintenable et bien commenté. Cela permettra éventuellement de générer la documentation à partir du code. Par contre, dans le second cas, vous aurez probablement besoin de compléter la documentation générée par une documentation produit plus détaillée et ce, indépendamment de la forme choisie (suite Office, wiki…).

Quoiqu’il en soit, il est nécessaire de s’accorder sur le rythme de mise à jour de cette documentation. Par ailleurs, j’ai pu constater qu’il est plus pertinent de considérer la documentation comme faisant partie intégrante du produit. Ainsi, vous pouvez lisser l’effort de rédaction en vous synchronisant sur le rythme itératif de votre produit. En fin d’itération, à chaque livraison du produit, vous pouvez livrer la documentation mise à jour avec les dernières fonctionnalités ajoutées.

Et la documentation utilisateur ?

Selon le contexte, la question de la documentation destinée à l’utilisateur se pose. Doit-on en rédiger une ? Si oui, à quel moment ?

Là encore, tout dépend du contexte. Les experts en expérience utilisateur vous diront qu’une interface est comme une blague, si vous devez l’expliquer, elle n’est pas si bonne que ça.

Donc, si vous avez une interface utilisateur, investissez plutôt sur la conception de celle-ci que sur sa documentation a posteriori. Cependant, si votre contexte nécessite la rédaction d’une telle documentation, je vous conseille également de vous synchroniser sur le rythme de livraison itératif de votre produit.

Conclusion

Mon propos dans cet article n’est bien évidemment pas d’alimenter l’idée reçue selon laquelle il n’y aurait pas de documentations sur les projets agiles. Par contre, il est primordial de vous poser les bonnes questions avant de vous lancer dans la rédaction de celles-ci : A qui s’adressent-t-elles ? Quel est le niveau de détail attendu ? A quel moment les rédiger ? Qui les rédige ?… Autant de questions dont les réponses devraient vous aider à gagner en efficacité.

Sinon, pour en revenir au titre de cet article, si vous entendez quelqu’un vous dire que les User Stories suffisent à couvrir tous vos besoins en documentation, vous saurez maintenant quoi leur répondre.

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT

Nombre de vue : 1339

COMMENTAIRES 3 commentaires

  1. Fabien Cortial dit :

    Tres bon article qui pousse à la reflexion. Le projet que je gere est fait principalement par des prestatiares, pour autant nous equilibrons code documenté et documentation externe.

  2. […] Source : SOAT Blog » Jetez vos User Stories […]

  3. 192.168.0.1 dit :

    Est-ce que l’on doit rédiger des spécifications sur un projet agile ?

AJOUTER UN COMMENTAIRE