Méthodes « Agile » : comparaison et avantages
« Vous avez fait du bon travail, mais l’utilisateur ne veut pas utiliser l’application », me confie le client.
Nous venions de passer plusieurs mois à développer une application basée sur des spécifications détaillées. Dans le contexte de ce projet, nous étions isolés de l’utilisateur final. La décision d’adopter une méthode de gestion de projets traditionnelle avait été prise au début du projet.
Cette phrase du client m’avait fait un choc. J’étais plutôt habitué à des retours de clients positifs. Nous avions aussi mis beaucoup d’énergies et d’efforts dans ce projet. Je voulais absolument comprendre et analyser ce qui n’a pas fonctionné dans le contexte de ce projet.
Et c’est là que je me suis intéressé aux méthodes dite « Agile ». Lorsque j’ai analysé mes projets qui ont fonctionné et cette dernière expérience, pour moi, les méthodes dite « Agile » était un regroupement des bonnes pratiques.
Dans cet article, je vais partager avec vous l’origine des méthodes agiles, la différence avec les méthodes traditionnelles, les méthodes agiles les plus connues et quand les employés et comment travailler avec une équipe de développement en mode agile.
Historique des méthodes « Agile »
En 2001, 17 experts, dont Ken Schwaber et Jeff Sutherland, se rencontrent et ils créent le « Manifeste agile » sensé rétablir l’ordre dans le chaos du monde du développement logiciel où 81 % des projets informatiques échouent [1].
Le « manifeste agile » c’est 4 valeurs et 12 principes. Toute méthode de gestion de projets respectant ces 4 valeurs et ses principes est une méthode agile.
Voici les quatre valeurs :
- 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
La partie gauche de la phrase n’annule pas la partie droite. Simplement, la partie gauche de la phrase (en gras) est plus valorisés que la partie droite.
Les méthodes de gestion de projets agiles les plus connues sont : Scrum, Kanban et eXtreme Programming (XP). Dernièrement, nous entendons aussi beaucoup parlé de SAFe qui est sensé être un système de portofolio management.
La différence entre les méthodes « Agile » et les méthodes traditionnelles
Les méthodes de gestion de projets traditionnelles, appelés gestion de projets en cascade ou encore cycle en V, sont des méthodes où l’on va planifier les tâches d’une manière prédictive et séquentielle. On va planifier la totalité du projet dans les moindres détails.
Le chef de projets a la sensation d’accomplir le projet déjà au moment de la planification de cette dernière. Des étapes sont prévues pour relever l’expression détaillée des besoins et leur validation auprès des utilisateurs finaux, le développement, les tests et la mise en production. Il y a peu de place au changement.
Dans la réalité, il y a souvent un déphasage entre cette planification et l’exécution de ce plan. À ce moment-là, les discussions entre l’équipe de développement, le chef de projet et les utilisateurs finaux deviennent tendues. Tous les changements, quels qu’ils soient, deviennent une source de négociations et un sujet de discussion délicat.
Dans un projet « Agile », l’organisation est plus souple et adaptable. Nous n’allons pas prévoir tout le projet dans les moindre détails très en amont du projet. Nous allons définir de gros blocs et nous allons prioriser ces dernières.
Ces blocs sont priorisés de façon à pouvoir livrer un bloc fonctionnel à l’utilisateur final à la fin de chaque itération. Une itération dure entre 2 et 3 semaines ou 1 mois dans certains cas. Ceci va permettre de diminuer l’abstraction inhérente liée à un projet informatique.
L’utilisateur final peut valider les blocs suivants basé sur un produit fonctionnel. Il n’a pas la lourde tâche d’apposer sa signature sur un document où sont inscrits de vagues spécifications et des croquis.
La communication et la collaboration entre l’équipe projet et l’utilisateur final sont ainsi également renforcé. Puisque à l’instar de se rencontrer uniquement au début du projet, ils se rencontrent toutes les 2 à 3 semaines et échangent sur des bases plus concrètes.
Tout le monde sait que la communication et la collaboration entre les différentes parties prenantes du projet sont importantes. Ces rituels permettent d’instaurer une communication régulière et constructive.
Les changements ne sont plus ressentis comme des « dangers », mais sont embrassés d’une manière bienveillante et comme une suite logique du projet. Le focus n’est pas sur le respect stricte du cahier des charges, mais sur la valeur effective apportée par le produit auprès des utilisateurs finaux. Cette flexibilité et cette souplesse est appréciée par toutes les parties prenantes du projet. Les méthodes dite « Agile » donnent une plus grande réactivité que les méthode traditionnelles.
Selon l’accord contractuelle effectué, le projet peut se terminer avant la date de fin estimée parce que l’objectif du projet a été atteint et que les blocs suivants ne sont pas nécessaires.
Il se peut aussi que le projet partait dans une mauvaise direction. Les blocs fonctionnels, le produit testable et palpable très en amont du projet par rapport aux méthodes traditionnelles, ont permis à l’utilisateur final et aux parties prenantes du projet de s’en rendre compte rapidement. Ceci remet l’utilisateur final, le client, au cœur de l’action.
Ensuite, ce focus et cette concentration sur la valeur effective et non le « bon suivi du plan » ont permis d’économiser du budget et d’investir dans des fonctionnalités à plus forte valeur ajoutée que celles imaginées au début du projet. La planification est réellement pilotée par l’utilisateur final.
L’utilisateur final a également une très grande visibilité sur l’avancement du projet. Effectivement, grâce, aux livraisons fréquentes, mais aussi grâce au management très visuels des méthodes de gestions projets dites « Agile ».
Pour renforcer, la communication et la transparence, des tableaux physiques ou digitales sont employés pour représenter les tâches, les blocs et leur avancement. C’est aussi un moyen pour l’utilisateur final de se représenter et d’observer l’impact de ses demandes.
Est-ce que c’est tout ? Non, il faut aussi une ingénierie logicielle adaptée à ce type de projets. C’est un élément souvent négligé, mais qui est pour moi l’élément le plus important lorsque l’on va se lancer avec les méthodes « Agile ».
Effectivement, on est dans un projet « Agile ». Le produit va éventuellement être tiré dans un sens, puis dans un autre. Il faut se donner les moyens de laisser la place au changement.
On ne peut pas construire sereinement un produit avec ce type de gestion de projets sans avoir une ingénierie logicielle adaptée. Il faut des tests unitaires automatisés. Un mode de programmation et un esprit chez les développeurs où l’on va écrire le test unitaire, avant d’écrire le code (test-driven-developement; TDD). Il faut aussi une infrastructure permettant de livrer le code en production d’une manière automatisée. Etc.
Sans ces outils et ces compétences, la maturité de l’équipe de développement, le projet va aller droit dans le mur.
Et ce n’est pas fini… Même avec tous cela votre projet peut encore échouer… 🙂 Pas drôle n’est-ce pas ? 🙂 Je vous explique tout cela dans cet article.
Et vous, quelle conclusion faites-vous de cet article ?
Quelle est votre expérience avec les méthodes traditionnelles ou les méthodes « Agile » ? Vous sentez-vous prêt pour vous lancer avec les méthodes agiles ? –> Dites le moi dans les commentaires.
[1] The Standish Group 1995, Chaos, https://www.cs.nmt.edu/~cs328/reading/Standish.pdf