Dans la section Informatique
Une Image...
Articles Liés
Top Articles
- Tutorial : Installer et configurer Homeplayer (freeplayer) (136117)
- Tutorial : Installer Windows Virtual PC et Windows XP Mode pour Windows 7 (Seven) (58613)
- Tutorial : Installer un dual boot avec Windows XP ou Vista et Windows 7 (Seven) (39132)
- Tutorial : Introduction à Jquery UI (34030)
- Tutorial : Migration de Windows Vista vers Windows 7 (Seven) (28258)
| Idée reçue n° 1: il n'y a plus de documentation |
 |
 |
| Informatique - Méthodes | ||||||
| Écrit par Vincent MARTIN | ||||||
|
Nous commençons un nouveau cycle sur les idées reçues de l’Agilité. Aujourd’hui, idée reçue numéro un : « Avec l’Agilité, il n’y a plus de documentation. »
Cette idée est surtout due à une mauvaise interprétation de la valeur n° 2 de l’Agilité : « Un logiciel fonctionnel plutôt que de la documentation exhaustive. »
Le Manifeste Agile n'a jamais dit que la documentation projet était inutile et qu’elle n’était plus nécessaire. Ce qu'il dit en revanche – entre les lignes – c’est que dans la plupart des projets, une (bonne) partie de la documentation est malheureusement superflue et/ou inexploitable.
Privilégier la documentation utile
Une doc de spécifications détaillées en début de projet, par exemple, c’est du temps, de l’énergie et de l’argent perdus. D’abord parce qu’elle est rédigée à un moment du projet où beaucoup de choses sont – et c’est naturel – floues, incertaines ou carrément inconnues. Beaucoup des points des spécifications ne reposent pas sur des faits, mais sur des hypothèses. Des choses seront à préciser, parfois à corriger.
Dans la pratique, ces corrections seront apportées au code en cours de projet, mais sont rarement répercutées – et je mets au défi quiconque de me prétendre le contraire – dans la documentation. On fera cela plus tard... Sauf que justement, en fin de projet, on est hyper à la bourre, et que, donc, ces corrections ne sont jamais faites. On se trouve alors dans la situation paradoxale d’une documentation complète, détaillée, coûteuse, ... mais inexacte et incohérente avec le code produit. On souhaite bon courage à l’équipe de maintenance !
Pourquoi alors passer du temps et de l’énergie à rédiger en amont une documentation dont on sait qu’il faudra la corriger pour la rendre cohérente avec le projet ? Pourquoi ne pas se contenter de ce qui est certain, d’une forme minimale et consacrer une rédaction plus élaborée aux spécifications en cours d’itération, cohérentes avec ce qui est réalisé, en se contentant de décrire le fonctionnement de l’exigence implémentée et d’indiquer éventuellement les choix importants, avec leur justification. En gros : se limiter à ce qui est nécessaire pour la compréhension du projet et faciliter le travail de l’équipe de maintenance. Qui le plus souvent préférera travailler avec une documentation minimum, mais du code de qualité, plutôt que de s’attaquer à une documentation exhaustive et complexe, aussi coûteuse à déchiffrer qu’elle l’a été à rédiger.
Utiliser la notion de « terminé »
Une méthode très efficace pour avoir le bon niveau de documentation dans un projet Agile est de l’intégrer à la notion de « terminé » : pour que ma story, ou ma tâche soit terminée, pour que je puisse placer mon post-it dans la colonne « terminé » de mon scrum board, il faut qu’elle soit documentée, avec les éléments de documentation et de qualité convenus.
On peut également l’inclure dans les colonnes du scrum board : à la place des trois colonnes de base (« à faire », « en cours », « terminé »), on peut imaginer d’avoir les colonnes « à coder », « code à relire », « à tester », « à documenter », « terminé ». Une tâche ne peut atteindre la colonne « terminé » que si elle est passée par la colonne « à documenter », et sortir de celle-ci que si la documentation demandée a été fournie.
Privilégier la communication en face à face
La documentation, dans une démarche classique, est utilisée pour transmettre de l’information d’une équipe à l’autre : par exemple des analystes aux architectes. Sans communication directe entre les deux équipes, il est facile d'imaginer que pour éviter les allers retours, consommateurs de temps, cette documentation doit être la plus complète possible.
C'est évidemment une illusion, sauf à supposer que tout peut être décidé, acté, prévu, spécifié en début de projet, et pour toute la durée du projet. Mieux vaut une documentation moins complète mais une communication directe entre les acteurs. Ce qui n’est pas indiqué en amont dans la documentation est alors produit en cours d’itération, par les échanges entre les différents acteurs. En d’autres termes, il vaut mieux avoir des User Stories brèves mais clairement identifiées, des « promesses de conversation » permettant d’initier l’échange avec l’expert métier, en face à face, qu’une documentation complète.
Le moyen le plus efficace pour transmettre de l’information, ce n’est pas la documentation, c’est l’échange et la communication en direct. On retrouve le principe numéro 6 du Manifeste Agile : « La méthode la plus simple et la plus efficace pour transmettre de l'information à l'équipe de développement et à l'intérieur de celle-ci est le dialogue en face à face » (source : http://www.agilemanifesto.org/iso/fr/principles.html).
Conclusion
L’Agilité n’interdit pas la documentation, elle préconise juste de s’en tenir au « bon » niveau de documentation, et surtout de constituer la documentation comme le reste du projet, itérativement. Le « bon » niveau de documentation étant celui qui est défini dans la notion de « terminé », garantissant ainsi que chaque exigence du projet doit, pour être réellement terminée, être entre autres correctement documentée.
Prochaine idée reçue : « l’Agilité, c’est pour les petits projets. »
Retrouvez tous nos articles sur www.computure.net.
Pour tout savoir de Scrum et de l'Agilité :
Et dans la catégorie « Méthodes », retrouvez également les articles suivants :
Computurellement vôtre.
L'image d'en-tête est extraite du site de la librairie Mollat (Bordeaux) : http://blogs.mollat.com/litterature/tag/bibliotheque/. Les propriétaires et ayant droit peuvent nous contacter s'ils jugent son utilisation inappropriée.
Tags:
Powered by !JoomlaComment 4.0alpha3
!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved." |
