Documentation d'analyse et Agilité

Beaucoup ont l'impression que l'Agilité rime avec "pas de doc". Une sorte de chaos où on se dédouane des doc sous prétexte qu'on "fait de l'agile".

Une des valeurs du manifeste Agile est effectivement de préférer "des logiciels opérationnel plus qu'une documentation exhaustive".

C'est là que la richesse du vocabulaire français nous éclaire : on parle bien de documentation non exhaustive donc quand même d'une documentation.

Mais que se cache-t-il derrière l'expression "non exhaustive" ?

En fait tout ceci est relativement simple et suit un principe standard du développement agile, celui de ne faire que ce qui est nécessaire.

Il y a deux cas de figures à prendre en compte : 

1. la documentation utile au développement du projet
2. la documentation utilisée pour conserver la connaissance sur le produit

La documentation fonctionnelle utile au projet

Une petite histoire au coin du feu.

Au cours d'un projet Agile sur lequel j'ai travaillé il y a peu, j'ai eu une conversation avec un Product Owner un vendredi soir juste avant de partir. 

Selon lui, il s’apprêtait à passer le weekend à écrire des spécifications fonctionnelles pour l'équipe. Ceci m'a surpris étant donné qu'il avait déjà présenté et revu les User Stories (mode gherkin) avec l’équipe une première fois au cours d'un Backlog review avant de les modifier en y intégrant leurs remarques.

L'équipe connaissait donc parfaitement le contexte et s'était approprié suffisamment bien les User Stories pour être capable de les amender.

Néanmoins, le Product Owner pensait nécessaire la rédaction d'une documentation de spécification pour les Poker planning à venir.

La question est simple, dans un tel cas est-il nécessaire de reprendre dans un document l'ensemble des informations déjà partagé avec l'équipe ?

Ma réponse est Non, évidemment !

Rappelons que l'Agilité mets le focus sur la délivrance de versions fonctionnelles du logiciel plutôt sur la documentation.

Donc dans ce cas, une documentation reprenant tout ce qui a déjà été présenté est un double travail donc une perte de temps.

A ce moment là, l'équipe a le minimum d'informations nécessaires pour les développements attendus dans le sprint à venir. Dans le cas où des compléments seraient nécessaires les Daily les feraient surgir et l'équipe aurait alors le temps de se retourner vers le Product Owner pour les réponses. Le feedback va dans les deux sens.

Quelle est alors l'utilité d'une documentation en phase de développement ?

Ici, la documentation devrait être vue sous deux angles :

1. Rappeler le contexteIl faut toujours avoir quelque part (wiki ou autres) un moyen aisé de présenter ou se rappeler le contexte du projet. Dans ce cas, une documentation est utile.
2. Etre un complément d'informations Enfin, au cours des développements, tout un ensemble d'informations comme les ACL, certains définitions de cas métiers très particuliers etc ... sont utiles voir même nécessaire pour l'équipe. A ce moment là, les détailler et les conserver dans une documentation centralisée et partagée est plus que nécessaire.

La mémoire du projet

Au cours de ma discussion avec ce Product Owner, l'argument de la mémoire du projet est apparue.

En effet, la documentation est indispensable à la mémoire du projet et donc à sa maintenance. 

Dans six mois, un an, elle sera fondamentale :

• pour l'intégration de nouveaux membres à l'équipe;
• pour le développement de nouvelles fonctionnalités;
• pour la compréhension de l'état actuel du système.

Mais la documentation utilisée et produite durant la phase de développement, n'est pas assez complète pour pouvoir remplir ces rôles dans une année.

Alors quid de cette documentation ?

Pour moi la chose est relativement simple bien que peu dans les usages.

La documentation de mémoire du projet devrait être considérée comme un projet à part entière.

Par conséquent, elle devrait avoir ses propres créneaux et ses propres ressources sans être une tâche du projet de développement.

Une fois de plus, le but de l'Agilité est de fournir un produit fonctionnel. Cette documentation de mémoire est-elle indispensable pour le délivrance des fonctionnalités ?

Conclusion

La documentation en phase de développement ne doit pas être confondue avec celle nécessaire pour la mémoire du projet.

Elles n'ont pas le même but et ne nécessite pas le même investissement.

Faites donc aussi attention à ce quelle ne se glisse pas dans la définition du "Terminé" ou alors vous serez amené à réaliser une ensemble de petite tâches non directement liées à la production des fonctionnalités.