Documentation Agile : Juste ce qu’il faut

Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».

A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …

Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.

Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :

  • A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
  • En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
  • Et toujours en fonction de destinataires potentiels

Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.

L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.

Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).

Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …

4 Comments

  1. On notera toutefois qu’il existe des cas où la production de certaines documentations est obligatoire et qu’elle devient aussi importante (si ce n’est plus…) que le logiciel lui-même.
    Je pense en particulier aux domaines où il existe de très fortes contraintes réglementaires (médical, transports, …) Dans ces cas très particuliers, je crois pour ma part qu’il faut considérer que certaines docs font intégralement partie du produit à livrer et donc les aborder non pas comme un simple artefact de support mais comme un but en tant que tel dont la production est intégrée au cycle de développement. La doc en question devient une exigence : peu importe si elle va avoir une utilité pour la partie logicielle.

  2. Comme tu le dis fort justement, cet espect documentaire devient une exigence à respecter, qu’il convient d’inscrire puis de tracer dans la "Liste des exigences". Le Processus Unifié assure une bonne prise en charge de ces acpects, et ce tôt dans le projet (non pas à la dernière minutes comme c’est trop souvent le cas!) grâce à sa discipline Déploiement et des rôles dédiés (tel le rédacteur technique). Généralement, on cherchera à livrer "le produit et sa documentation associée" (dégré et destinataires variables en fonction du contexte).

  3. Dans la pratique des grands comptes il est assez difficile dans la pratique d’avoir le discours « Juste ce qu’il faut ». J’ai mené plusieurs projets pour un grand de la pharmacie, ceux qui sont au QA (qui faisait partie du service dit de Gouvernance ce qui veut tout dire) imposait l’esprit les documents avant tout, ils avaient un outil de planification dont les livrables explicites étaient les livrables documentaires, le logiciel n’apparaissant nulle part.

    Dans leur méthodologie, le mot itératif figurait à plusieurs reprises en justification de la gestion des risques, dans la pratique il fallait suivre le Cycle en V. Je leur avais remarquer malicieusement que leur logiciel ne prévoyait même pas le cycle itératif alors que c’était dans leur propre méthodologie …

    Il y a donc le discours pseudo-rationnel d’un côté et la pratique de l’autre qui est toute autre qui est notamment issue de la lutte de pouvoir et des alliances. Dans le cas ci-dessus le directeur de la MOE imposait le cycle en V (même si les développeurs n’en voulaient pas) et avait pour allié la QA. La méthodo a été pondue par un cabinet de conseil spécialiste des abstractions.

    En conclusion, l’Agilité peut difficilement se faire parce qu’il n’y a pas l’adhésion du Top Management dans la très grande majorité des cas, parce qu’on n’apprends pas les méthodes itératives dans les écoles mais le cycle en V, et parce que le cycle en V est simpliste.

  4. @lepineKong: C’est pour toutes ces raisons qu’une transformation agile passe par un véritable changement culturel …

Les commentaires sont fermés.