Monsieur le coach, et ma doc alors ?

Un jour de formation User Story Academy, un stagiaire m’interpèle et me dit : «  Et ma doc alors ? ». Tout d’un coup, le silence, LA question était tombée ! Vous savez, cette fameuse question qui met à mal l’agilité, que l’on vous pose à chaque fois, celle qui fait débat, où personne n’est jamais d’accord et n’a pas vraiment de réponse : Comment gérer la documentation en agile ?

Et bien voici ce que je lui ai répondu…

Retour sur le manifeste

Tout d’abord, il faut rétablir une vérité : l’agilité ne dit pas qu’il ne faut pas de documentation, elle préconise la bonne documentation ! La nuance est importante et l’amalgame est souvent fait, sans doute à cause d’une mauvaise interprétation du manifeste :

«  Des logiciels opérationnels plus qu’une documentation exhaustive » 

Oui la meilleure documentation c’est le produit lui même, son code et ses tests. Mais dans certains contextes, lorsqu’il s‘agit d’une documentation utilisateur, de contrats d’interface, de flux ou tout autre fonctionnalité « transparente », tout le monde n’a pas accès à l’information. 

Dans le cas de mon stagiaire, la situation est pire. Nouveau Product Owner sur un produit qui a évolué au fil des versions, où divers prestataires se sont succédés, l’information a tellement été diluée avec le temps, qu’il lui est devenu impossible de savoir comment fonctionne son produit.

Dans ce cas, on ne demande pas du Zola, mais une documentation est nécessaire.

Différence entre Backlog et documentation

Le premier réflexe pour une documentation en agile est de penser au backlog. En effet, celui-ci contient toute la connaissance fonctionnelle du produit. Mais il faut comprendre le mécanisme inhérent. Une User Story développée dans un temps N peut être modifiée par une User Story en N+1. Du coup, rien ne garantit qu’une US soit le reflet du produit. Retracer la « chaine » d’US caractérisant une fonctionnalité peut être long et fastidieux. 

Et mon référentiel de tests dans tout ça?

Le deuxième réflexe est de penser aux tests. Le référentiel de tests reflète l’état du logiciel toute version confondue. Si vous avez du BDD (tests rédigés en langage naturel par l’exemple), bien joué ! Tout dépend ensuite de votre couverture de tests. Encore faut-il y avoir accès et avoir le bon logiciel (bon courage avec QC). 

Solution pour une documentation agile

Voici donc une solution : un wiki + une ligne de DoD.

Pourquoi la documentation pose-t-elle problème ? Pourquoi est-elle souvent inexistante ? Pourquoi n’est-elle jamais à jour? Parce que c’est long et inintéressant ! Donc non prioritaire…

En mettant la documentation à jour sur un wiki à chaque fin d’US, ça n’est plus la même chose. C’est beaucoup moins rébarbatif. Petit bout par petit bout, brique par brique la documentation se construit et vous capitalisez. Au final, cela coûte beaucoup moins cher. De plus, le wiki propose des fonctionnalités très intéressantes comme la traçabilité de toutes les modifications et les notifications automatiques. Le plus connu est sans doute Confluence.

Pour s’en assurer, il suffit d’ajouter une ligne à votre DoD (Definition of Done). Vous savez, cette fameuse liste de critères qui vous permet de dire si votre Story est terminée ou non. En ajoutant le wiki comme critère dans la DoD, cela devient une règle de l’équipe. Votre US n’est terminée que lorsque le Wiki est à jour. Pas de wiki, pas de Done ! 

Simple non ?