J'ai été invité à participer, au nom de l'association Agile Toulouse à la table ronde Gestion documentaire au service l'amélioration continue organisée par l'association MFQ le jeudi 26 septembre dernier à Ingésup. Les interventions étaient plutôt menées par des professionnels de la gestion documentaire. C'est une discipline en soi que je ne connaissais pas et que j'ai découverte. Il est clair qu'elle est digne d'intérêt, ne serait-ce que de part son caractère universel : partout, les entreprises ont les mêmes problèmes de gestion documentaire et partout, il existe des solutions si on se donne la peine de les adresser professionnellement.
Néanmoins, l'organisation a tenu à y introduire la vision de l'agilité par rapport à la documentation, sujet déjà itéré maintes fois mais qui revient toujours comme un boomerang, en témoigne ce post de l'époque. Au début un tantinet septique sur la cohérence du programme, j'ai finalement trouvé que c'était une bonne idée. En effet, au fil de mes missions, ma vision change et s’aiguise sur chaque sujet, notamment celui de la documentation. L'exercice m'a forcé à la clarifier devant un auditoire peu éveillé à l'agilité, et pour la plupart non-informaticien. En résumé :
Documentation ou information ?
La première question à se poser est de se donner un but dans tout ça (une vision en quelque sorte) : de quoi parle-t-on et que veut-on au juste ? Et là je rejoins les autres intervenants, spécialistes de la gestion documentaire : l'important c'est l'information et la valorisation. Oui, c'est bien l'information qui est importante, comment elle est communiquée, partagée, diffusée, remontée, redescendue, facile d'accès etc, le document lui étant un support, un paquetage de l'information.
Valorisation
La valeur d'une information ou d'une documentation est plus difficile à définir. Mais on se doute qu'il s'agit de faire le tri entre des info/docs utiles et des infos/docs moins utiles. J'avais déjà proposé un modèle de valeur pour juger de cela. On peut également reprendre un des principes d'Extreme Programming : Voyager léger, qui nous invite à alléger au maximum nos valises pour aller plus vite. Forcément, cela concerne au premier chef la documentation (mais pas que)
Quelles informations, quels documents, pour quels buts ?
En agile, nous privilégions le visuel, les post-its, les radiateurs d'information car ils facilitent la collaboration au quotidien, remettent à l'honneur la conversation face-à-face et nous dispense d'avoir des documents lourds et inadaptés pour servir cet objectif. Néanmoins, cela nous invite à distinguer plusieurs types de documentation :
- la documentation éphémère au service de la collaboration
- la documentation persistante au service du produit et de l'organisation
- la document projet, éphémère par nature, pour piloter le projet
- la documentation produit, persistante par nature, pour documenter la conception et l'utilisation du produit
Documentation projet
On considère ici la documentation projet comme étant celle des plans, rapports et suivi de pilotage. On y trouve alors toute la batterie d'artefacts utilisés classiquement en agile : plan de version, burndown, vélocité etc. Notons que si on ne peut pas se contenter de post-it et de papiers aux murs, on privilégiera souvent les outils aux gros document Words / Excel, car ils facilitent la collaboration. Cela pose quelque part la question de l'agilité de l'outil
Documentation produit
C'est celle qui sera gardée pour maintenir et faire vivre le produit :
- backlog produit et ses histoires utilisateurs. Mais attention, cette documentation est en perpétuelle métamorphose et à ce titre, pourrait presque rentrer dans la catégorie précédente. Disons qu'il est inclassable, car à la fois au service de la définition des besoins (définition des histoires d'utilisateurs) et du pilotage projet (sorte de plan de livraison de petits morceaux de produit)
- manuels d'utilisation, d'installation, de maintenance etc
- architecture, principes de conceptions clef etc
- le code lui-même : il doit être compréhensible et lisible
- les tests : les tests d'acceptation. Leur description permet de bien comprendre le comportent attendu du produit. Leur code permet de bien comprendre le comportement attendu du logiciel, qui doit être le même bien entendu !
Documentation émergente
Un des caractéristiques des projets agiles, c'est l'émergence des documents, c'est-à-dire qu'il sont produit petits à petits tout au long du projet, en boucles rapides. C'est normal puisque nous recherchons la cible du juste à temps avec le document qu'il faut au bout moment, par opposition à la cible du tout prévoir dès le début avec des gros documents. Les contextes critiques (spatial, médical, temps-réel embarqué etc) exigent la production de documents comme fourniture de preuves. En agile, nous fournirons ces documents. Mais nous ne les fournirons pas de la même façon. Nous les fournirons de façon émergente, au fil du développement des incréments de produits. Cela permet, entre autre, d'être sûr d'écrire du contenu mature, d'éviter de s'être trompé en amont et d'avoir à réécrire. En termes d'assurance produit, il va être question de collecter des preuves cumulatives qui nous permettront d'atteindre les objectifs qualité en fin de parcours.
Documentation exécutable
Enfin, un volet important de la documentation dans le monde agile, c'est sa capacité à se transcender en devenant un automate qui permet de prouver que le produit répond bien au besoin. On parle souvent de spécification exécutable. Les tests d'acceptation sont formalisés dans un système de type wiki (exemple : Fitnesse), qui permet à la fois d'exécuter des tests et de conserver une forme documentaire accessible aux non-informaticiens. On entend ainsi résoudre le chaînon manquant entre une spécification de besoins écrit par l'humain et un logiciel qui s’exécute à travers une machine. Entre les deux, il y a le trou qui peut faire que le produit ne réponde pas au besoin.
Documentation agile pour autre chose que l'informatique
Puisque la majorité du public n'était pas dans le monde du logiciel, il m'a fallu réfléchir aux bonnes pratiques de gestion agile de la documentation au sens large. Retenons :
- Valoriser les documents : sont-ils utiles, à quel degré ? Sinon, il faut les simplifier ou les éliminer
- Les produire au bon moment : ne pas sur-anticiper, attendre d'avoir le feedback nécessaire pour les enrichir, se contenter de versions intermédiaires suffisantes
- Se recentrer sur la notion d'information : parfois sans doute, est-il souhaitable et possible de se passer de document au profit d'un outil adéquat d'échange de l'information
- Privilégier la collaboration et réutiliser les techniques agiles de management visuel pour potentiellement alléger la charge de production documentaire
- Faire participer l'équipe au standard de gestion documentaire, car ce sont eux qui subissent les problèmes au quotidien. C'est l'aspect managérial cultivé par le courant agile. Les gens d'en bas deviennent acteur de l'amélioration continu : ils proposent des standards, leurs amélioration et s'engagent à le faire