L’agilité fait sûrement partie des concepts ayant le plus influencé les développements logiciels ces vingt dernières années. Pour autant, il a aussi été très largement détourné. Revenons donc à ses principes fondamentaux.
La gestion de projets
Avant l’agilité, les projets (logiciels, mais pas que) étaient majoritairement réalisés de la manière suivante :
1/ une documentation exhaustive : le client rédigeait un cahier des charges (souvent un joli pavé, allant de quelques dizaines de pages à plusieurs centaines) qui contenait l’ensemble des exigences que le logiciel devait respecter.
2/ suivi d’un plan : l’équipe technique se chargeait de l’implémenter. Une fois l’implémentation terminée, le plan de vérification démontrait le respect des exigences.
3/ négociation contractuelle : en fonction du nombre d’exigences respectées et du respect du délai imparti, le client rémunérait l’équipe technique.
1/ une documentation exhaustive : le client rédigeait un cahier des charges (souvent un joli pavé, allant de quelques dizaines de pages à plusieurs centaines) qui contenait l’ensemble des exigences que le logiciel devait respecter.
2/ suivi d’un plan : l’équipe technique se chargeait de l’implémenter. Une fois l’implémentation terminée, le plan de vérification démontrait le respect des exigences.
3/ négociation contractuelle : en fonction du nombre d’exigences respectées et du respect du délai imparti, le client rémunérait l’équipe technique.
Cette méthode de travail présentait de nombreux problèmes, comme par exemple :
- le client devait imaginer l’intégralité de son projet à l’avance, jusqu’aux moindres détails. Avec la complexité grandissante des projets, il est vite devenu impossible de prévoir toutes les situations, et donc de mettre des exigences en face de chaque situation.
- un véritable “effet tunnel” existait entre le début et la fin du projet : le client donnait son cahier des charges au début, et récupérait un produit à la fin. Si une des hypothèses initiale était fausse, le client ne s’en rendait compte qu’une fois le produit livré. S’il voulait faire évoluer le produit, un nouveau projet devait être négocié.
- Le produit a une date de fin, ce qui signifie que les développeurs n’ont aucune obligation quant à la qualité du code. Si le projet n’est pas facile à maintenir ou à faire évoluer par la suite, ce n’est pas un problème !
Je vous invite vivement à lire ces exemples d’échecs :
– des trains trop grands par rapport à la taille des quais
– la machine à tickets de métro parisien, ou “comment ne pas répondre correctement au besoin des usagers ?”
– des trains trop grands par rapport à la taille des quais
– la machine à tickets de métro parisien, ou “comment ne pas répondre correctement au besoin des usagers ?”
L’agilité
Pour pallier tous ces problèmes, le concept d’agilité a été créé.
On retrouve le terme dès les années 1970, mais l’émergence de la théorie date réellement de l’année 2001 où un groupe de 17 experts s’est retrouvé pour en définir les bases communes.
On retrouve le terme dès les années 1970, mais l’émergence de la théorie date réellement de l’année 2001 où un groupe de 17 experts s’est retrouvé pour en définir les bases communes.
Le manifeste agile, disponible ici, est le résultat de ce séminaire : il définit les 4 valeurs suivantes :
Nous valorisons
- 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 reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Comme explicité dans la dernière phrase, ces valeurs sont toutes basées sur la forme “élément1 plus que élément2″ : elles consistent donc bien à privilégier de nouvelles valeurs par rapport à celles historiques de la gestion de projet. Pour autant, il ne s’agit aucunement de les renier !
A noter que 12 principes ont aussi été formulés pour expliciter ces valeurs, je les détaillerai dans un prochain article.
Les individus et leurs interactions plus que les processus et les outils
L’idée derrière cette première valeur est de remettre les individus au centre de la problématique. De nombreux projets sont peu efficaces, ou voués à l’échec, à cause :
- de processus trop lourds : ajouter des garde-fous à chaque étape de conception, ou encore à créer des documents énormes et verbeux jamais relus.
- d’outils (pré?) historiques ne répondant plus aux besoins actuels, mais conservés malgré tout, souvent pour de mauvaises raisons.
- de généralisation d’outils ou de processus à l’ensemble des équipes sur la base qu’ils fonctionnent pour l’une d’entre elles.
Les méthodes agiles veulent remettre les individus au centre du processus décisionnel en les rendant autonomes dans le choix des outils et processus qu’elles utilisent. De même, l’agilité veut maximiser les interactions entre les personnes pour faire émerger une véritable intelligence collective : les outils de travail ne doivent être qu’une façon de faciliter cette communication entre les personnes.
Le terme “individu” couvre également le client : les interactions avec le client sont un point essentiel de l’agilité. La définition de son besoin passe par la discussion.
Des logiciels opérationnels plus qu’une documentation exhaustive
Comme je l’expliquais précédemment, un bon cahier des charges ne présume pas d’un produit ergonomique, pratique , répondant au besoin du client.
L’agilité prend le contre pied en décrétant qu’il faut accepter de ne pas avoir une documentation complète en amont. La meilleure manière de mesurer l’avancement d’un projet réside dans la capacité du logiciel à être utilisable à chaque instant.
Mais ce qui se cache surtout derrière cette valeur est le concept de qualité : un logiciel opérationnel est un logiciel qui apporte de la valeur, facile à utiliser. La documentation est rédigée de manière synchrone avec l’avancement du logiciel. On s’assure alors que la documentation est représentative de ce que fait le logiciel, et non ce qu’il devrait faire.
L’opérationnalité peut aussi être vu comme un concept de qualité technique. Un logiciel opérationnel est un logiciel :
- avec une architecture pertinente
- avec des tests automatisés pour s’assurer du bon fonctionnement des briques essentielles
- facile à faire évoluer, modulable (si un problème arrive à un endroit, cela ne remet pas en cause l’intégralité du produit).
La collaboration avec les clients plus que la négociation contractuelle
Le contact avec le client est essentiel, mais il doit se faire intelligemment. Les contrats “non-agiles” définissent des dates de début et de fin de projet, un périmètre fixe, et ne laissent pas de place à l’adaptation. L’agilité veut remettre le client dans l’équation durant toute la conception du logiciel.
Dans la méthodologie Scrum par exemple, le client est invité aux démonstrations pour tester le logiciel au fur et à mesure qu’il est conçu. Cela permet de s’assurer qu’il répond bien à son besoin, et de s’adapter par la suite si nécessaire. Ces séances permettent même parfois de déceler de nouveaux usages non prévus initialement.
A l’inverse, la négociation contractuelle impose souvent une roadmap stricte, avec des dates de livraison fixes, et souvent très optimistes. On se perd alors souvent en négociations pour gagner quelques jours de délai supplémentaires, ou pour justifier des retards. Cette débauche d’énergie est autant de temps perdu pour la réalisation de nouvelles fonctionnalités.
L’adaptation au changement plus que le suivi d’un plan
Une des valeurs probablement les plus mal comprises : l’agilité prône une adaptabilité face aux changements de route qu’un projet peut vivre. Cela ne signifie pas “ne pas avoir de plan”, mais plutôt être capable de détecter si on va vers un mur (le besoin du client a changé, les concurrents ont pris une longueur d’avance, un choix technologique pose problème, etc…) et faire en sorte de l’éviter.
L’adaptation au changement peut aussi correspondre à la manière dont on définit le périmètre d’une feature. L’iron agile triangle illustre bien ce concept :
Dans les méthodes classiques, le périmètre est fixe, les ressources et le temps sont variables. En agilité, on inverse le triangle pour rendre la fonctionnalité adaptable aux ressources et au temps disponible pour la développer.
Mais l’adaptation au changement va au-delà de la roadmap ou des fonctionnalités : elle correspond aussi à l’adaptation de l’équipe elle-même. Ses besoins évoluent au fur et à mesure (en fonction de sa taille, de ses projets, voire des individus qui la composent). L’équipe doit donc se remettre en question régulièrement (lors des rétrospectives en Scrum par exemple) pour détecter ses points forts et ses faiblesses, et s’adapter en conséquence.
Conclusion
Vous l’aurez compris, l’agilité représente un changement complet de paradigme sur la manière de travailler en privilégiant l’autonomie de l’équipe et la collaboration, notamment avec le client. Pour autant, le manifeste ne précise pas comment atteindre ces objectifs. Des frameworks (Scrum, Kanban, ShapeUp, …) ont été créés pour donner des pistes pour y parvenir.
Ce qu’il faut retenir
- l’agilité est définie dans le manifeste agile qui comprend 4 valeurs et 12 principes
- Les 4 valeurs 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