La documentation et l'agilité
From Transitionagile
Cette thématique fait suite à un ensemble d'échanges / discussions avec Jean-François Jagodzinski (coach agile), Laurent Tardiff (PO) Antoine Clave (consultant en management de projets traditionnels) et Bruno Riccoboni (de la DSI du CHU de Grenoble).
Sur ce thème, il me semble qu'il y a beaucoup à creuser, une structuration s'impose. Globalement : A quoi sert la doc ? Quelle doc ? Quelle est sa VA et son ROI ? Que faut-il documenter, quand et comment ?
Contents |
Intro : à quoi sert la documentation ?
Globalement, quelles sont les raisons pour lesquelles les personnes gérant les projets selon l'approche traditionnelle sont si attachées à la documentation ? Qu'en pensent le reste de l'organisation ? Il faudrait interroger / receueillir des témoignages des métiers, la Direction Informatique (urbanistes, architectes, BE, exploitant, TMA...).
Partie 1 : Quelle documentation ?
Je propose pour aider les traditionalistes à comprendre ce que signifie le passage à l'agilité de partir de leurs propres références. Voyons quelle est la liste de doc traditionnelle / voir ce qu'elle devient si on passe à Scrum.
Dans un projet de de classique, on documente successivement : - l'opportunité / business case / project charter - la faisabilité / besoins + étude scénarios + choix scénario // étude explo - le cahier des charges niveau CGF + contraintes + forfait sur périmètre avec engaggt délai et coût, variable qualité // CDC niveau cadrage avec début de backlog priorisé évolutif + contraintes + tps passé ou forfait agile avec bd / engagement sur cadre scrum avec planning de sprints, engagement délai, cout, qualité / variable périmètre - le contrat : avec des avenants à chaque évolution de périmètre // stable en scrum sauf si changement de rythme (nb de mêlées de front) - les specs… de la simple reformulation word à la forme structurée avec maquette / de rien à un peu plus… documentée avant le dé / après le dé (rappel manifeste) - les tests : écrits après, en test unitaire ou d'intégration, joués à la main par les developpeurs // écrits au commencement de la meo, structurés, codés pour automatisation av. de développer la story - le code - les paramètres (la liste validée, pourquoi cette liste, les cas discutés et écartés) - le résultat des tests : tableau de suivi des anomalies / rapport de compilation - la doc d'install - la doc utilisateur
De la Pérennité de la documentation
Dans un projet, à chaque étape, on approfondi, on révise le périmètre, on gère les éventuelles régressions fonctionnelles… => comment conserver la documentation à jour ? (sinon toute la doc précédente est obsolète ? Ex DFB et CDC et même les specifs sont obsolètes si on détecte un problème en recette qui vient d'un manque fonctionnel non détecté en amont. Faut-il tout revoir depuis la DFB ? A quel coût (modifier le programme + la doc de test, de recette + les specs, le CDCD, la DFB, le guide utilisateur, le guide d'install...) ?
Du respect du projet des principes d'un SI urbanisé
Un projet développé en scrum n'est pas souvent seul au monde : positionnons le dans le SI d'une grande organisation ayant un legacy system conséquent et urbanisé ou en voie d'urbanisation : l'équipe projet SCRUM bénéficie-t-elle de la souplesse voulue ? Quid du respect de l'archi fonctionnelle ? Quelle participation à la gestion des référentiels documentaires du SI (doc des fonctions transverses…)?
De l'analyse de la valeur de la documentation
Quelle doc sert vraiment à qqchose (relue au moins une fois a posteriori en étant toujours à jour)? Dans quel cas la valeur de la doc est elle supérieure au coût de sa non existence en cas de besoin ou au coût de son maintient à jour à chaque évolution de la solution ? (cf discussion avec Laurent Tardiff au sujet d ela doc d'install d'une appli)
Pour les documents à forte valeur, quand les créer ?
Pour une doc dont le ROI est positif, quel est le meilleur moment pour la créer, comment la créer pour réduire son coût de création et surtout comment la maintenir à jour à moindre coût pour qu'elle conserve sa valeur de référence ? Nous évoquerons ici la notion de référentiel documentaire co-écrit en séance par ex avec un wiki qui remplace la documentation word évoluant par stades successifs, par versions successives avec relectures multiples... Ce référentiel documentaire évite également de créer des documents différents pour les besoins, la conception générale et la conception détaillée. Le référentiel documentaire est unique, les précedents documents s'obtiennent par des niveaux de lecture (chapitres, section, sous-section) de plus en plus fins, et ce jusqu'aux tests métier et au manuel utilisateur
To be continued
