Les méthodologies Agile et leur documentation
Devenues incontournables pour les projets de développement, les méthodologies Agile sont souvent perçues comme sujettes à de mauvaises pratiques documentaires. Eloignées des traditionnels cycles en V, ces méthodologies nécessitent pourtant elles aussi une base documentaire forte pour assurer l’adéquation des besoins au produit final.
Les méthodologies Agile sont de plus en plus utilisées pour la réalisation des projets de développement informatique. Désormais, près de trois organisations sur quatre s’appuient sur elles, contre un tiers seulement en 2009. Cet engouement s’explique sans doute par leur caractère pragmatique et orienté résultats, préconisant notamment un produit fonctionnel plutôt qu’une documentation pléthorique. Ceci ne signifie cependant pas que toute documentation soit superflue.
Une base de connaissance documentée et partagée
Bien que les échanges verbaux soient favorisés, il n’en demeure pas moins nécessaire de construire une base de connaissance documentée et fiable avec les différents interlocuteurs du projet, de manière à formaliser les décisions prises durant le projet. Contrairement aux méthodologies de type Waterfall, la documentation est ici la résultante du travail effectué et non la base de ce dernier. Ainsi, seules les informations nécessaires au bon déroulement du projet sont conservées. La documentation n’est pas un but en soi, mais un moyen pour parvenir au produit final. L’effort investi est réduit à son minimum, de manière à se concentrer sur la construction de la solution et non sur sa spécification. Puisqu’elle est réduite à sa plus simple expression, la documentation doit être d’autant plus pertinente, et tous les acteurs du projet en sont responsables.
Un dessin vaut mieux qu’un long discours
Bon nombre de développements impliquent la mise en place d’une interface graphique. Celle-ci est souvent garante de la bonne perception du produit et de son adoption par les utilisateurs. Il est donc primordial de bien spécifier les interactions homme/machine et leur design. Dans le cadre des méthodologies Agile, la formalisation des besoins doit être pragmatique et visuelle; c’est ainsi que l’utilisation des wireframes (ou maquettes fil de fer) s’est démocratisée. En effet, associées à un style guide, elles permettent de spécifier les écrans de l’application de manière rapide et compréhensible par l’ensemble des acteurs du projet, tout en se focalisant sur l’essentiel: les interactions avec l’utilisateur final.
Tous les acteurs du projet documentent, même les développeurs
Certains pourraient penser qu’en adoptant une méthodologie Agile, ils s’affranchissent de toute tâche de documentation; en fait c’est peut-être l’inverse: toutes les occasions sont bonnes pour documenter et c’est toute l’équipe qui contribue. Là où le chef de projet tient à jour sa documentation de projet (backlog, meeting minutes, burndown chart, etc.), les analystes métier mettent à jour les user stories. Les spécialistes en expérience utilisateur quant à eux définissent les wireframes et les designers construisent le look and feel de l’application sous la forme de maquettes extrêmement réalistes. Mais la principale documentation est le code source lui-même, qui se doit d’être bien écrit et commenté. Celui-ci est vérifié aussi bien manuellement, lors de séances de code review, que de manière automatique, par les systèmes d’intégration continue. Traqués, les développeurs n’ont pas le choix! Le code source est contrôlé, sa couverture de tests est mesurée et inclue dans un rapport fourni lors des livraisons et accessible en ligne. Les tests couvrent à la fois les aspects techniques, d’intégration et fonctionnels. Ils constituent une documentation complète de l’application, en même temps qu’un outil de validation. Impossible de livrer et de terminer une itération si les métriques ne sont pas conformes aux attentes exprimées. Travailler dans un projet Agile, c’est documenter de manière précise, au plus près du cœur du système, directement dans le code source.
Encore de la documentation
La documentation d’un projet Agile se décline sous plusieurs formes: user stories, wireframes, personas, code source et rapports de tests. Dans le cadre de réalisations avec engagement de résultat, se rajoutent encore les documents de vision, plans de projet, guides utilisateur, cahiers de test, etc. Toute une série de documents empruntés aux méthodologies de type Unified Process viennent compléter le panorama. Le but étant d’assurer un cadre contractuel global permettant de supporter le haut degré de liberté induit par une démarche Agile.
Etre Agile c’est avant tout mettre en avant la communication, la réactivité et l’adaptabilité. Pour ce qui est de la documentation, finalement, ne serait-ce pas juste une histoire de mesure?
Kommentare
« Plus