Documentation technique et projet agile informatique: une hérésie?

Qu’en est-il de la documentation technique dans un projet agile?

J’ai été interpellée dans un de mes projets par un collègue qui s’est exclamé que nous ne pouvions pas dire que nous étions agiles étant donné la documentation technique qui nous était demandée par le client dans un projet de réalisation d’une application informatique.

Il faut bien admettre que la documentation n’est habituellement pas le travail préféré d’un développeur et qu’il peut être tentant de trouver une bonne raison de s’en débarrasser.

De mon côté, je n’avais pas vu les choses de cette façon.

Comme c’est souvent le cas lorsqu’une nouvelle approche est lancée, chacun y va de son interprétation et la signification d’un même mot change selon les expériences. Si on n’y prend garde, cela amène un risque important de voir des problèmes de communications.

Vous pouvez faire le test dans votre entourage de manière tout à fait simple. Demandez à quelques personnes à quoi ils pensent lorsqu’ils entendent un mot. Ce peut être montagne, vaisselle, vacances, qualité le mot en soi importe peu. Vous verrez que ce qui résonne en chacun sera différent.

Pour éviter ces pièges lorsqu’on parle de méthode de travail, je favorise une source principale comme étant « la référence » et au besoin je complète pour ajuster aux besoins particuliers de la situation. Ce qui est important : prendre le temps de revoir avec l’ensemble des interacteurs la définition des mots dans le contexte où vous êtes.

Suite à cette affirmation de mon collègue, je suis donc retournée à mes deux sources principales pour clarifier ce qu’on entend par l’approche agile :

1. Le manifeste agile [1]

2. Le scrum guide [2]

Le manifeste agile indique que l’agilité vise à valoriser « Des logiciels opérationnels plus qu’une documentation exhaustive ».

Dans le scrum guide on ne parle pas explicitement de documentation. Par contre, on indique : « Les développeurs sont les membres de la Scrum Team qui s'engagent à traiter tout ou partie utile d’un Increment à chaque Sprint»

Mon interprétation de ces deux sources est la suivante :

• Si pour que le product owner[3] puisse publier le résultat du travail de l’équipe, il a besoin de documentation, alors on doit produire cette documentation. Dans ce cas, la production de la documentation technique est une exigence du département qualité de l’entreprise.

• Cette documentation ne doit pas être exhaustive mais elle doit répondre au besoin de publication du logiciel réalisé.

Ce qui signifie, que contrairement au processus de développement traditionnel qui exige que les spécifications soient rédigées de manière exhaustive avant de commencer à écrire du code, la documentation est produite en parallèle avec la réalisation du logiciel.

Cela évite de documenter quelque chose qui au final ne sera pas livré. et surtout de s’assurer que la documentation reflète exactement ce qui a été produit. Un autre avantage, une partie de la documentation pourra être produite directement depuis le code, évitant ainsi la duplication des informations et le risque d’incohérence. Ce qui est aujourd’hui possible avec les outils de développement à disposition.

En conclusion, l’approche agile permet d’être agile aussi dans la rédaction de la documentation, ce qui ne signifie pas qu’il n’y aura pas de documentation.

Et vous, qu'en pensez-vous ? Avez-vous des expériences similaires ou différentes ? Faites-moi en part, je serai ravie d'en discuter avec vous!

Illustration : œuvre de Mélanie Bénard Tremblay, 2020, © Marakoudja

[1] https://agilemanifesto.org/iso/en/manifesto.html [2] Le Guide Scrum 2020, https://www.scrum.org/ [3] « Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. », Le Guide Scrum 2020, https://www.scrum.org/