Publié en 2001, le Manifeste Agile tient en quatre valeurs et douze principes. Douze ans plus tard, il reste la boussole de toute équipe sérieuse. Voici le texte complet, avec quelques mots sur ce qu'il signifie vraiment.
En février 2001, dix-sept praticiens du développement logiciel se réunissent dans une station de ski à Snowbird, Utah. Ils ne cherchent pas à fonder un mouvement. Ils essaient juste de trouver un terrain commun entre leurs méthodes respectives — XP, Scrum, DSDM, Crystal, Feature-Driven Development. Ce qu'ils rédigent ce week-end-là tient sur une page. On l'appelle depuis le Manifeste pour le développement Agile de logiciels.
Douze ans plus tard, ce texte est cité partout et appliqué nulle part, mal compris, réduit à un buzzword. C'est l'occasion de le relire dans son intégralité.
Les quatre valeurs
Nous découvrons de meilleures façons de développer des logiciels, par la pratique et en aidant les autres à le faire. Par ce travail, nous en sommes venus à préférer :
Les individus et leurs interactions plutôt que les processus et les outils.
Des logiciels opérationnels plutôt qu'une documentation exhaustive.
La collaboration avec les clients plutôt que la négociation contractuelle.
L'adaptation au changement plutôt que le suivi d'un plan.
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
La dernière phrase est la plus négligée. Le manifeste ne dit pas que les processus, la documentation, les contrats et les plans sont inutiles. Il dit que quand il faut choisir, on choisit la gauche plutôt que la droite. C'est une question de priorité, pas d'abolition.
Les douze principes
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Pas « satisfaire le client en livrant ce qui était prévu ». La valeur ajoutée prime sur le respect du scope initial.
Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agile exploitent le changement pour donner un avantage compétitif au client.
Le changement tardif n'est pas un échec de planification — c'est une opportunité. Les marchés bougent. Les utilisateurs apprennent. Les équipes qui peuvent pivoter gagnent.
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
La fréquence de livraison n'est pas une contrainte organisationnelle, c'est un choix délibéré pour raccourcir les boucles de feedback.
Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Pas « organisez une réunion de kick-off puis envoyez des emails ». Quotidiennement. C'est radical, et c'est volontaire.
Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
La confiance n'est pas un bonus managérial, c'est une condition de fonctionnement. Les équipes micro-managées ne livrent pas de bon logiciel.
La méthode la plus simple et la plus efficace pour transmettre de l'information à l'équipe de développement et à l'intérieur de celle-ci est le dialogue en face à face.
Les documents de spécification ne remplacent pas la conversation. Le ticket Jira ne remplace pas la discussion debout devant un tableau.
Un logiciel opérationnel est la principale mesure d'avancement.
Pas les stories pointées. Pas les tickets fermés. Pas les livrables intermédiaires. Le logiciel qui tourne. C'est le seul étalon qui compte.
Les processus Agile encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
Le sprint marathon n'est pas agile. L'équipe qui finit épuisée après chaque itération n'est pas agile. La soutenabilité est une vertu technique, pas un confort.
Une attention continue à l'excellence technique et à une bonne conception renforce l'Agilité.
La dette technique n'est pas le prix de la vélocité. C'est son ennemi. Le code mal écrit ralentit tout ce qui suit.
La simplicité — c'est-à-dire l'art de minimiser la quantité de travail inutile — est essentielle.
YAGNI. KISS. Ne pas construire ce dont on n'a pas besoin maintenant. C'est plus difficile que ça n'y paraît.
Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
L'architecture ne descend pas d'un architecte en chef vers l'équipe d'implémentation. Elle émerge des gens qui construisent le logiciel, parce qu'ils sont les mieux placés pour le faire.
À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
La rétrospective n'est pas une formalité de fin de sprint. C'est le mécanisme par lequel une équipe apprend. Pas de rétro sérieuse, pas d'amélioration réelle.
Ce que ce texte n'est pas
Le Manifeste Agile n'est pas un guide de déploiement de Scrum. Il ne mentionne ni sprints, ni story points, ni daily standup, ni backlog. Ces pratiques ont leur valeur — certaines plus que d'autres — mais elles ne sont pas le manifeste.
Il n'est pas non plus une promesse que vos projets iront plus vite. Il dit que vous livrerez de la valeur plus tôt, que vous apprendrez plus vite, que vous pourrez vous adapter. La vitesse brute n'est pas l'objectif.
Ce qu'il est, c'est une prise de position claire sur ce qui compte dans le développement logiciel : les humains, le produit qui fonctionne, la collaboration, et la capacité à changer. Tout le reste est secondaire.
Le texte original du manifeste est disponible sur agilemanifesto.org.