Documentation Agile : Équilibrer vitesse et rétention des connaissances

Les divers documents, artefacts et processus liés à leur génération sont quelques-uns des principaux symboles du modèle Waterfall. Empruntant au Lean, Agile considère une grande partie de la documentation comme un « déchet » qui doit être éliminé afin de rationaliser le cycle de vie du développement.

Pour de nombreux chefs de projet, il n'est pas très difficile de comprendre comment les phases Waterfall sont transformées en sprints - le même travail est accompli ; c'est juste organisé d'une manière différente. Cependant, la suppression de la plupart des documents est une pilule plus difficile à avaler car elle souligne une manière de travailler complètement différente. Cela nécessite de desserrer les rênes du contrôle, d'embrasser l'inconnu et de donner à l'équipe de livraison les moyens de prendre des décisions sur-le-champ.

L'approche traditionnelle de la documentation est remise en question

Dans la méthodologie Waterfall, beaucoup de temps est passé à documenter les exigences du projet et à détailler les solutions. Ce processus fonctionne lorsque les exigences sont parfaitement claires et que nous sommes certains que rien ne changera par rapport à ce qui a été capturé et établi. Pourtant, les expériences de la plupart des entreprises au cours des dernières décennies ont montré que cela n'est presque jamais vrai. Dans le monde d'aujourd'hui, le rythme du changement est si dynamique que les besoins du client changent considérablement au moment où nous terminons la phase de documentation.

L'objectif d'Agile est de faire avancer les choses et d'ajouter de la valeur aux parties prenantes. Il est construit de telle manière que le modèle décourage de travailler sur les périphériques et sur des activités qui n'apportent pas directement et immédiatement de valeur ajoutée au client.

Documentation en cascade vs Agile

Chaque entreprise a un niveau de documentation différent, qui peut différer même au niveau du projet. Mais voici à quoi ressemblent les procédures de documentation typiques dans les projets Waterfall et Agile :

Le cas de la documentation

Waterfall prône une approche beaucoup plus stricte de la documentation, ce qui peut sembler excessif. Mais avant de considérer cela comme du « gaspillage », voici plusieurs avantages à disposer de procédures de documentation solides.

Opportunité de réflexion stratégique

Ceux qui ne parviennent pas à planifier, prévoient d'échouer. La documentation oblige un chef de projet à s'asseoir et à réfléchir, puis à trouver les meilleures solutions. Les gens interprètent parfois à tort la valeur Agile d'un logiciel fonctionnel par rapport à une documentation complète pour signifier qu'aucune documentation n'est requise. Ils se précipitent ensuite sur le marché, un geste que Paul Adams, vice-président des produits chez Intercom, décrit comme jeter des trucs contre le mur et voir ce qui colle. Concevoir des solutions, créer des plans, délibérer des actions - ces activités créent de la valeur en permettant de gagner du temps en ne développant pas chaque idée de fonctionnalité qui vous vient à l'esprit.

UX et cohérence fonctionnelle

Au fur et à mesure que les entreprises passent de quelques fondateurs à des centaines ou des milliers d'employés, de nombreuses équipes différentes commencent à travailler sur le même produit ou sur des produits connexes. L'équipe A peut penser que ce sur quoi elle travaille n'est pas lié à ce sur quoi travaille l'équipe B, mais pour l'utilisateur final, c'est le même produit. Au lieu que des équipes interfonctionnelles fassent leur propre travail, une documentation claire sur l'expérience utilisateur et les niveaux fonctionnels évite un flux d'utilisateurs décousu.

La documentation peut être convertie en guides de l'utilisateur

Dans Waterfall, on passe beaucoup de temps à détailler les solutions et comment elles seront utilisées. Des images de conceptions haute fidélité sont créées pour les développeurs front-end. Tous ces actifs nécessitent moins de travail pour être convertis en guides d'utilisation internes ou externes que de les créer à partir de zéro.

Comment Agile réduit les besoins en documentation

Un facteur qui revient à plusieurs reprises comme excuse pour exiger la documentation est le roulement du personnel. Les managers craignent de perdre leurs connaissances institutionnelles lorsque des personnes partent et que de nouvelles rejoignent pour les remplacer. Comment sauront-ils ce qui a été mis en œuvre et comment cela fonctionne ? Combien de temps mettront-ils à se rattraper ? L'équipe actuelle aura-t-elle la bande passante nécessaire pour accueillir les nouveaux membres de l'équipe ?

L'espoir est qu'une bonne documentation permettra aux nouveaux employés qui travaillent pour la plupart de manière indépendante de se mettre rapidement au courant. Cependant, Agile réduit intrinsèquement le besoin de documentation grâce à des techniques de collaboration qui, en même temps, réduisent le temps d'intégration. Voici quelques façons dont Agile réduit le besoin de documentation.

Interaction régulière entre les équipes produit et les membres de l'équipe agile

Le Manifeste Agile promeut « les individus et les interactions plutôt que les processus et les outils ». Étant donné que les exigences ont tendance à changer au cours d'un projet et que de nouvelles idées surgissent, Agile assure la clarification des exigences directement à partir de la source au lieu de dépendre d'artefacts écrits qui nécessitent une mise à jour constante.

Le toilettage et la planification compartimentent les tâches

La préparation du backlog et la planification des sprints décomposent les fonctionnalités en parties spécifiques et implémentables qui sont facilement compréhensibles et peuvent être travaillées de manière indépendante. Cela crée une opportunité pour les nouvelles recrues d'être productives dès le début, tout en ne comprenant pas encore pleinement la vue d'ensemble de l'ensemble du projet.

Les user stories fournissent une documentation efficace

Le format simple des user stories permet aux chefs de projet de capturer les exigences minimales qui créent une compréhension partagée entre tous les membres de l'équipe. Même si une user story ne se transforme pas en sprint, le gaspillage lié à la création de cet artefact de documentation est très faible. Au fur et à mesure que les user stories se transforment en sprints, elles peuvent être étoffées et complétées par d'autres informations requises telles que les wireframes, les conceptions, les critères d'acceptation, etc. Ce processus permet une livraison de documentation très efficace, hautement jetable et produite aux étapes de développement les plus appropriées.

Besoin réduit de documentation de code

Des techniques telles que la programmation en binôme et la révision de code créent des opportunités constantes pour diffuser les connaissances techniques au sein de l'équipe, en particulier aux nouveaux membres de l'équipe. La rétroaction constante conduit à une compréhension partagée qui a également la flexibilité de s'adapter à de nouvelles circonstances au lieu de devenir rapidement obsolète dans un document quelque part.

Cérémonies agiles

Les standups quotidiens, les revues de sprint et les rétrospectives créent de nombreuses opportunités pour résoudre les problèmes et prendre des décisions en face à face au lieu de s'appuyer sur les e-mails et les documents. La durée limitée de toutes les cérémonies garantit que seules les informations les plus importantes sont prioritaires au lieu de passer du temps à tout documenter, même si elles ne seront probablement jamais utilisées.

Tout ce qui précède réduit directement ou indirectement la documentation et donne la priorité à la réalisation des objectifs du projet tout en garantissant que rien n'est vraiment perdu par manque de documentation.

Approches hybrides de la documentation

Certaines entreprises préfèrent toujours avoir de la documentation, même dans un contexte Agile. Agile n'est pas normatif, car chaque projet est différent et a un ensemble unique de circonstances qui doivent être prises en compte.

Vous trouverez ci-dessous quelques exemples de la façon dont Agile peut être combiné avec des méthodes de documentation plus chronophages.

Combiner UML et Agile

Envisagez d'utiliser un langage de modélisation standard tel que le langage de modélisation unifié (UML) qui est très structuré et a des entités définies pour visualiser un système. Cela aide à garder le contenu très simple et concentré sur ce qui est nécessaire et garantit une utilisation minimale de la langue écrite. Des outils tels que StarUML et Draw.io, parmi tant d'autres, sont des options pratiques.

Générateurs de documentation de code

Une autre approche consiste à s'assurer que le code est beaucoup plus lisible en introduisant des commentaires plus structurés et détaillés dans le cadre des détails de la classe, des détails de la méthode, de l'utilisation des paramètres, des dépendances, etc. Il existe de nombreux outils qui automatisent le processus de génération de documents utiles à partir du code source et ils sont appelés générateurs de documentation. Ils vont du générique au langage de programmation spécifique.

Conception détaillée et documents UX

La définition des exigences à l'aide de wireframes, de maquettes, de diagrammes de flux utilisateur, de diagrammes de séquence, etc. permet de simplifier les flux de projet et de clarifier explicitement pour l'équipe technique ce qui doit être développé. Les documents de conception sont un excellent moyen d'avoir un niveau variable de documentation plus rigide. Il existe différents outils de wireframing et UX parmi lesquels choisir pour ces tâches.

Outils de gestion de projet Automatiser la documentation

Une gestion de projet plus puissante et des outils connexes tels que JIRA, Confluence, Asana et Basecamp permettent de conserver toutes les informations relatives au projet en un seul endroit. Les tâches peuvent être liées, étiquetées, imbriquées et attribuées à différents membres de l'équipe, qui peuvent ensuite laisser des commentaires et signaler tout problème. Toutes ces actions, ainsi que la flexibilité d'adapter ces outils, peuvent créer une quantité substantielle de documentation avec peu ou pas d'effort.

Par ailleurs, historiquement, une partie des besoins en documentation découle des exigences de reporting. Les parties prenantes veulent accéder aux performances de l'équipe ou à d'autres mesures pertinentes. Les outils de gestion de projet facilitent l'automatisation de tableaux de bord et de vues personnalisés qui reflètent l'avancement du projet et renvoient à la documentation pertinente dans l'outil.

La gestion de la documentation est un exercice d'équilibre

Les créateurs du Manifeste Agile écrivent qu'ils apprécient "un logiciel fonctionnel plutôt qu'une documentation complète". Cependant, ils ajoutent également une clause de non-responsabilité selon laquelle "bien qu'il y ait de la valeur dans les éléments de droite, [ils] valorisent davantage les éléments de gauche". Agile ne suggère pas de supprimer toute la documentation, car certaines documentations apportent évidemment de la valeur ; il suggère simplement que la priorité devrait être sur le fonctionnement du logiciel et l'ajout de documentation uniquement si nécessaire en fonction des circonstances du projet et sans entraver fortement les progrès du développement.

Les chefs de projet doivent trouver un équilibre entre passer moins de temps sur la documentation et passer plus de temps sur la livraison de logiciels fonctionnels et déterminer où une certaine forme de documentation est nécessaire pour un succès à long terme.