Vos méthodes Agile c’est bien sympa, mais faut aussi faire de la doc hein!
Quelle belle sentence ai-je pu entendre maintes fois.
Alors pour rappel, soyons clair, notre objectif premier est de générer de la valeur pour nos clients. Pas sûr que le botin fasse partie des attentes principales!
Ensuite oui la documentation est nécessaire. Pour le support, pour la maintenance… mais pas pour se couvrir, ou pour prendre la poussière dans un coin.
Livrer un produit opérationnel est une priorité mais le faire vivre dans le temps en devient malgré tout rapidement une autre.
A partir de la deux idées :
Le backlog se suffit à lui-même
Pratique, tout est dedans!
Mais difficile de s’y retrouver malgré tout, après des mois de dur labeur!
Et puis en fonction des cas, plusieurs stories peuvent refléter des évolutions successives d’un même périmètre (comme une interface qui va s’enrichir au fur et à mesure des sprints)
Devoir reconstituer un puzzle quand on veut voir immédiatement l’image globale n’est jamais plaisant.
Une solution est d’utiliser des hiérarchies type “Features” ou “Epics”. Chapeautant un ensemble de stories, ils peuvent contenir la documentation globale nécessaire à une bonne visibilité et au suivi opérationnel.
La documentation raisonnée
C’est là que réside un équilibre fragile : qu’est-ce que réaliser une documentation raisonnée?
Confronter par exemple cette idée avec les concepts ITIL vous feront vite tomber dans la valse des documents… et de leur maintenance!
Encore une fois, il va falloir adapter tout cela, et ce n’est pas facile dans une équipe pluri disciplinaire… avec des enjeux différents (développement, infrastructure, hébergement…).
Pour le suivi opérationnel, procédure de paramétrage, d’installation, d’assistance, architecture générale et contrat de service semblent cependant être un minimum.
Et un Wiki?
Idée intéressante, qui permet de centraliser la documentation, proposer une recherche aisée et une navigation facilitée.
Mais encore une fois que mettre dedans? Malheureusement cette question vient souvent après les questions “Pour qui?” et “Pourquoi?”.
Aider l’utilisateur?
Faciliter le travail du support?
Fournir les éléments pour un maintien en conditions opérationnelles?
….
A tout vouloir mélanger, les utilisateurs ne s’y retrouverons pas… . Donc choisissez votre axe et tenez le.
Conclusion
Discussions sans fin, incompréhensions, conflits et autres amuseries sont au programme si l’on ne s’arrête pas sur le mot raisonné une bonne fois pour toute.
Chaque contexte de travail étant différent, impossible de donner une liste arrêtée de documents.
Seul constat : le backlog est vivant et suit l’évolution du produit. Une documentation, elle, reste statique et risque, faute de mise à jour, de prendre la poussière et de devenir obsolète et dangereuse .
