Publié par

Il y a 5 ans -

Temps de lecture 3 minutes

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 ?

Publié par

Publié par Renaud Chevalier

Renaud est directeur de l'offre agile chez Xebia. Il est également formateur au sein de Xebia Training .

Commentaire

4 réponses pour " Monsieur le coach, et ma doc alors ? "

  1. Publié par , Il y a 5 ans

    Simple quand la personne qui écrit la doc fait partie de l’équipe…

    Pour ma part, en 9 ans d’expérience, je n’ai jamais eu ce cas.

    Certes les développeurs/testeurs de l’équipe pourraient se forcer à mettre à jour un wiki et ensuite une autre équipe se chargerait de transformer le wiki en « vraie » doc utilisateur mais ca me parait couteux (coût qui doit pouvoir se justifier dans certains gros projets je pense, mais das ce cas pourquoi ne pas directement mettre les personnes qui écrivent la doc dans l’équipe et le mettre dans le DoD…)

  2. Publié par , Il y a 5 ans

    @chris : C’est quoi une « vraie » doc ? Celle qui permet d’utiliser le produit ? Un wiki répond très bienà cette problématique.

  3. Publié par , Il y a 5 ans

    Comprendre : je n’ai jamais eu le cas où c’est le développeur qui écrit la documentation fonctionnelle qui est dans les mains de l’utilisateur final (je n’ai travaillé que pour des entreprises SaaS, le manuel utilisateur est dans mon expérience toujours réalisé par le support et pas par le développement).

  4. Publié par , Il y a 5 ans

    Bonjour,

    Suivant les contextes, il peut être envisageable que le manuel utilisateur soit rédigé par le PO.
    Le PO faisant parti de l’équipe, la DoD s’applique aussi à lui :)

    Renaud

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.