Le problème que l'agilité essaie de résoudre
Vous démarrez un projet. Vous passez trois mois à tout planifier : le budget, les délais, les fonctionnalités, qui fait quoi. Un beau document. Tout le monde signe.
Six mois plus tard, rien ne correspond. Le marché a bougé. Le client a changé d'avis. Une technologie est apparue. Et vous êtes en train de construire, à grands frais, quelque chose dont plus personne ne veut vraiment.
L'agilité part d'un constat simple : sur un projet complexe, on ne peut pas tout prévoir. Alors autant arrêter d'essayer, et devenir très bon à s'adapter.
D'où ça vient : dix-sept personnes dans la neige
En février 2001, dix-sept praticiens du développement logiciel se réunissent dans une station de ski de l'Utah, à Snowbird. Ils ne sont d'accord sur presque rien — chacun défend sa propre méthode, et ce sont souvent des concurrents.
Ils en repartent pourtant avec un texte de quelques lignes : le Manifeste Agile. Quatre valeurs, énoncées sous forme d'arbitrages :
- Les individus et leurs interactions, plus que les processus et les outils.
- Un produit qui fonctionne, plus que de la documentation exhaustive.
- La collaboration avec le client, plus que la négociation contractuelle.
- L'adaptation au changement, plus que le suivi d'un plan.
Le « plus que » est essentiel. Ce n'est pas « pas de plan », « pas de documentation ». C'est une question de priorité quand il faut choisir.
À quoi ça sert, concrètement
Au lieu de livrer un gros projet au bout d'un an, une équipe agile livre un petit morceau utilisable toutes les deux semaines. Elle le montre. Elle écoute. Elle corrige le tir.
Trois bénéfices, très terre à terre :
- On se trompe moins longtemps. Une mauvaise idée est repérée en deux semaines, pas en dix-huit mois.
- On livre de la valeur tout de suite, au lieu de tout garder pour une grande sortie qui glisse de trimestre en trimestre.
- Les gens qui font le travail décident du travail, ce qui, accessoirement, les rend beaucoup moins malheureux.
Et non, ce n'est plus réservé aux développeurs : marketing, RH, événementiel, industrie — partout où l'imprévu est la règle plutôt que l'exception.
Les grandes familles
L'agilité est un état d'esprit. Les frameworks sont des façons concrètes de l'appliquer.
Scrum — Le plus répandu. L'équipe travaille par cycles courts et réguliers appelés Sprints (une à quatre semaines), au terme desquels elle livre quelque chose d'utilisable. Trois rôles, quelques rituels, et beaucoup de discipline.
Kanban — Pas de sprints, pas de rôles imposés. On visualise tout le travail sur un tableau, et on s'impose une règle simple : ne pas commencer trop de choses à la fois. Le flux continu, plutôt que le rythme cadencé.
Lean — Venu de l'industrie automobile japonaise. Une obsession : traquer le gaspillage. Tout ce qui n'apporte rien au client final — attentes, stocks, tâches inutiles — doit disparaître.
Extreme Programming (XP) — Le plus technique. Il pousse à l'extrême les bonnes pratiques de développement : tests écrits avant le code, programmation à deux sur le même écran, livraisons très fréquentes.
Par où commencer ?
Par Scrum. C'est le plus utilisé, le plus documenté, et celui qui donne les repères les plus solides pour comprendre tout le reste.
Et si possible, en le pratiquant plutôt qu'en le lisant.