Manifeste Agile #2 : des logiciels opérationnels plus qu’une documentation exhaustive

Le Manifeste Agile nous explique qu’une des valeurs importantes des méthodes agiles est :  des logiciels opérationnels plus qu’une documentation exhaustive. Comment pouvons nous transformer ça concrètement ?

Pour rappel, les 4 valeurs du manifeste agile sont :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Nous allons voir en 4 articles complets, les possibilités déjà évoquées pour répondre à chacune de ses valeurs sans pour autant s’arrêter à la méthodologie Scrum.

Nous avions déjà commencé par traiter la première valeur du Manifeste Agile lors d’un premier article :

Article : Manifeste Agile #1 : les individus et leurs interactions plus que les processus et les outils

Article : Le manifeste agile : 4 valeurs et 12 principes

Des logiciels opérationnels

Si le Manifeste a voulu simplifier au maximum ces valeurs afin qu’elles soient lues et comprises par tout le monde, elle peuvent cependant soulever différentes interprétations intéressantes.

Dans un projet réalisé en méthode agile, on va surtout privilégier de travailler sur le fait d’obtenir un logiciel opérationnel. Qui dit opérationnel, dit que celui-ci correspondra parfaitement au besoin initial des utilisateurs clés ainsi qu’aux parties prenantes.

J’ai volontairement inclue les parties prenantes car elles sont souvent celles qui vont accepter la mise en production du produit pour x raisons (souvent financières). Il est évident que dans la plupart des cas, une application ne sera pas mise en production si elle est une perte financière hors stratégie particulière de l’entreprise.

Un produit qui s’incrémente d’évolution

Pour qu’un logiciel soit opérationnel, les méthodes agiles fonctionnent avec des itérations courtes. Cela permet de récupérer régulièrement du feedback des utilisateurs clés qui permettront d’améliorer le produit (logiciel) dès les prochaines itérations.

Il est essentiel de bien comprendre que cela implique que les méthodes agiles soient très axées utilisateurs.

La représentation du Scrum avec la boucle itérative en est la parfaite illustration :

Si on avait prévu de faire une fonctionnalité qui est au final peu intéressante pour les utilisateurs clés, on s’autorisera de modifier le travail à réaliser dans les prochaines itérations pour que le produit soit de plus en plus proche de leurs attentes.

On privilégiera cette piste plutôt que de suivre impérativement des documentations comme on le ferait avec d’autres méthodes de gestion de projet plus anciennes.

Une documentation également incrémentale

Afin de s’autoriser ce droit de changer les fonctionnalités du produit voire ses principes dans certains cas, on va réaliser des documentations au fur et à mesure.

Certaines documentations se feront et s’étofferont après (ou pendant) chaque développement demandé (US, tâche technique…) ; celles-ci ne se feront jamais d’un bloc et jamais en amont des développements afin de s’assurer de leur utilité : on pourrait prendre comme exemple des documentations techniques ou des documentations utilisateurs.

Pour d’autres documentations liées généralement aux demandes fonctionnelles à réaliser, on les réalisera par petits blocs de demandes fonctionnelles appelés des user-stories.

Article : Comment bien créer ses user-stories ?

« Plus que » veut bien dire qu’on exclue pas la documentation (même exhaustive si on va à l’exagération de l’interprétation) mais qu’on privilégie le logiciel. Il ne faut surtout pas interpréter cette phrase comme le fait de ne pas réaliser de documentation. L’agilité impose beaucoup de rigueur et est exigente sur la qualité ; la qualité fonctionnelle passe par un bonne documentation fonctionnelle et la qualité technique par une bonne documentation technique.

Si cela est obligatoire dans certains contextes (normes ISO à respecter ou document d’exigence de sécurité par exemple), l’équipe devra même fournir le minimum de documentation requis en amont pour réaliser les développements.

Je vous laisse vous référer sur un article dédié aux documentations dans les méthodes agile :

Article : La documentation dans les méthodes Agiles

Dans certains contextes, un minimum peut être attendu en fin de framing pour valider un « Go » voire un « No go » de l’exécution du projet. Il faut juste s’éviter de partir dans de la documentation « non exhaustive » ; n’hésitez pas à appliquer la philosophie KISS (Keep It Simple, Stupid) à votre documentation.

Article : Le principe KISS pour les développeurs

Plus de documentation fonctionnelle et cahier des charges

Le type de documentation qui est exclu des projets agiles sont les cahiers des charges et/ou les documentations fonctionnelles qui font souvent des dizaines voire des centaines de pages.

Nous privilégions des documentations fonctionnelles qui se construisent par morceau et qui s’alimentent à l’approche du développement de chacun de ces morceaux (les fameuses user-story). Cette technique permet de ne pas mettre de l’énergie dans une documentation qui pourra changer dans le temps.

Comme dans la philosophie du Lean, on tente de limiter au maximum le waste (déchet) dans la production du produit. Cela permettra de maximiser la productivité de la création du produit et donc de concentrer son énergie à la valeur du produit.

Attention, chaque morceau peu être détaillé et complet ; c’est même recommandé.

La qualité avant la quantité

Dans cette valeur se cache le terme « opérationnel ». Il est indispensable dans les projets agiles d’avoir des projets de qualité. Les équipes vont donc faire le nécessaires pour limiter au maximum le risque de bugs futurs.

Pour cela, les demandes fonctionnelles devront être de qualité et la partie technique devra être irréprochable. On conseille ainsi de mettre des  concepts d’ingénierie logiciel comme des tests unitaires, des tests d’acceptances, des tests de charges, des tests qualitatifs de code…

En effet, ces techniques d’ingénierie prennent beaucoup de temps ce qui implique une rigueur constante de l’ensemble de l’équipe. Faire un projet avec des méthodes agiles ne permet pas de développer plus rapidement mais d’avoir un produit de meilleure qualité.

Conclusion

J’espère que cet article vous aura bien éclairé sur la deuxième valeur agile qui est « des logiciels opérationnels plus qu’une documentation exhaustive » car elle est parfois mal interprété par certaines équipes qui associe cette valeur par un zéro documentation.