Manifeste Agile de développement logiciel : Histoire , Principes et Valeurs

Manifeste pour le développement Agile de logiciels :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

• 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.

Les 12 principes sous-jacents au manifeste

Nous suivons ces principes :

• Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
• Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
• Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
• Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
• 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 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.
• Un logiciel opérationnel est la principale mesure d’avancement.
• Les processus Agiles 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.
• Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.
• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
• Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées.
• À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Histoire du Manifeste Agile (par “Jim Highsmith ©2001”)

Du 11 au 13 février 2001, au complexe The Lodge à Snowbird dans les montagnes Wasatch de l’Utah, dix-sept personnes se sont réunies pour discuter, skier, se détendre et essayer de trouver un terrain d’entente – et bien sûr, pour manger. Ce qui en a résulté, c’est le Manifeste pour le développement agile de logiciels. Des représentants de l’Extreme Programming, du SCRUM, du DSDM, du Adaptive Software Development, du Crystal, du Feature-Driven Development, du Pragmatic Programming et d’autres, sensibles à la nécessité d’une alternative aux processus de développement de logiciels lourds et axés sur la documentation, se sont réunis. 

Il serait difficile de trouver un rassemblement plus important d’anarchistes organisationnels, donc ce qui a émergé de cette réunion était symbolique – un Manifeste pour le développement Agile de logiciels – signé par tous les participants. La seule préoccupation concernant le terme agile venait de Martin Fowler (un Britannique pour ceux qui ne le connaissent pas) qui admettait que la plupart des Américains ne savaient pas prononcer le mot « agile ». 

Les préoccupations initiales d’Alistair Cockburn reflétaient les pensées premières de nombreux participants. « Personnellement, je ne m’attendais pas à ce que ce groupe particulier d’adeptes de l’agilité se mette d’accord sur quelque chose de substantiel. » Mais ses sentiments après la réunion étaient également partagés, « En ce qui me concerne, je suis ravi de la formulation finale [du Manifeste]. J’ai été surpris que les autres semblent également enchantés par la formulation finale. Donc, nous nous sommes mis d’accord sur quelque chose de substantiel. » 

Se nommant « The Agile Alliance », ce groupe de penseurs indépendants sur le développement logiciel, et parfois concurrents les uns des autres, est tombé d’accord sur le Manifeste pour le Développement Agile de Logiciels (affiché sur la page de titre du site web http://agilemanifesto.org/ ) . 

Bien que le Manifeste offre des idées spécifiques, il existe un thème plus profond qui anime de nombreux membres de l’alliance, mais pas tous, c’est certain. À la clôture de la réunion de deux jours, Bob Martin a plaisanté en disant qu’il allait faire une déclaration « sentimentale ». Mais bien que teintée d’humour, peu étaient en désaccord avec les sentiments de Bob – que nous nous sentions tous privilégiés de travailler avec un groupe de personnes partageant un ensemble de valeurs compatibles, un ensemble de valeurs fondées sur la confiance et le respect mutuel et promouvant des modèles organisationnels basés sur les personnes, la collaboration et la création de types de communautés organisationnelles dans lesquelles nous aimerions travailler.  

Au cœur, je crois que les méthodologues Agile sont vraiment concernés par les choses « sentimentales » – par la livraison de bons produits aux clients en opérant dans un environnement qui fait plus que parler des « personnes comme notre atout le plus important » mais qui agit réellement comme si les personnes étaient le plus important, et perd le mot « atout ». Ainsi, en dernière analyse, l’intérêt météorique pour les Méthodologies Agile – et parfois les critiques énormes à leur égard – concerne les choses sentimentales, des valeurs et de la culture. 

Par exemple, je pense qu’ultimement, la Programmation Extrême (Extreme Programming) a vu son utilisation et son intérêt se développer non pas à cause de la programmation en binôme ou du remaniement du code (refactoring), mais parce que, dans son ensemble, les pratiques définissent une communauté de développeurs libérée du fardeau des entreprises à la Dilbert. Kent Beck raconte l’histoire d’un emploi qu’il a eu au début de sa carrière où il a estimé un effort de programmation de six semaines pour deux personnes. Après que son gestionnaire ait réaffecté l’autre programmeur au début du projet, il a terminé le projet en douze semaines—et s’est senti terriblement mal à propos de lui-même ! Le patron—bien sûr—l’a harcelé sur sa lenteur tout au long des six semaines suivantes. Kent, quelque peu désespéré car il était un tel « échec » en tant que programmeur, a finalement réalisé que son estimation originale de 6 semaines était extrêmement précise—pour 2 personnes—et que son « échec » était en réalité l’échec du gestionnaire, en effet, l’échec de l’état d’esprit du processus « fixe » standard qui afflige si souvent notre industrie. 

Ce type de situation se produit tous les jours – le marketing, la gestion, les clients externes, les clients internes, et, oui, même les développeurs – ne veulent pas prendre de décisions difficiles concernant les compromis, donc ils imposent des exigences irrationnelles à travers l’application de structures de pouvoir corporatives. Ceci n’est pas seulement un problème de développement logiciel, cela concerne l’ensemble des organisations de type Dilbertesque. 

Pour réussir dans la nouvelle économie, pour avancer de manière agressive dans l’ère du commerce électronique et du web, les entreprises doivent se débarrasser de leurs manifestations Dilbertesques de travail inutile et de politiques obsolètes. Cette liberté par rapport aux absurdités de la vie en entreprise attire les partisans des Méthodologies Agile et effraie énormément (on ne peut pas utiliser le mot ‘merde’ dans un papier professionnel) les traditionalistes. Très franchement, les approches Agile font peur aux bureaucrates d’entreprise – du moins à ceux qui sont heureux de pousser le processus pour le processus lui-même plutôt que d’essayer de faire au mieux pour le « client » et de livrer quelque chose en temps voulu, de tangible et « comme promis » – car ils perdent leurs cachettes. 

Le mouvement Agile n’est pas anti-méthodologie, en fait, beaucoup d’entre nous veulent restaurer la crédibilité du mot méthodologie. Nous voulons rétablir un équilibre. Nous adoptons la modélisation, mais pas pour archiver un diagramme dans un dépôt d’entreprise poussiéreux. Nous adoptons la documentation, mais pas des centaines de pages de volumes jamais entretenus et rarement utilisés. Nous planifions, mais reconnaissons les limites de la planification dans un environnement turbulent. Ceux qui voudraient étiqueter les partisans de XP ou SCRUM ou de toute autre Méthodologie /Framework Agile comme des « hackers » ignorent à la fois les méthodologies et la définition originale du terme hacker. 

La réunion à Snowbird a été préparée lors d’une rencontre antérieure de partisans de la Programmation Extrême (Extreme Programming), et quelques « outsiders », organisée par Kent Beck au Rogue River Lodge en Oregon au printemps de l’année 2000. Lors de la rencontre au Rogue River, les participants ont exprimé leur soutien pour une variété de méthodologies  » Light « , mais rien de formel n’a eu lieu. Au cours de l’année 2000, un certain nombre d’articles ont été écrits qui faisaient référence à la catégorie des processus  » Light  » ou « Lightweight ». Un certain nombre de ces articles mentionnaient des « méthodologies légères”, telles que Extreme Programming, Adaptive Software Development, Crystal et SCRUM. Dans les conversations, personne n’aimait vraiment le surnom  » Light « , mais il semblait s’imposer pour le moment. 

En septembre 2000, Bob Martin de “Object Mentor” à Chicago, a lancé l’organisation de la prochaine réunion avec un email ; « J’aimerais organiser une petite conférence (de deux jours) dans la période de janvier à février 2001 ici à Chicago. Le but de cette conférence est de réunir tous les leaders des méthodes légères dans une seule pièce. Vous êtes tous invités ; et j’aimerais savoir qui d’autre je devrais approcher. » Bob a mis en place un site Wiki et les discussions ont été vives. 

Dès le début, Alistair Cockburn a donné son avis avec une lettre qui identifiait le mécontentement général envers le mot ‘Léger’ : « Ça ne me dérange pas que la méthodologie soit qualifiée de légère en poids, mais je ne suis pas sûr de vouloir être désigné comme un poids léger participant à une réunion de méthodologues légers. Cela sonne d’une certaine manière comme un groupe de personnes maigres, faibles d’esprit et légères essayant de se rappeler quel jour on est. » 

Le débat le plus animé concernait le lieu ! Il y avait de sérieuses préoccupations concernant Chicago en hiver — froid et rien d’amusant à faire ; Snowbird, Utah — froid, mais des choses amusantes à faire, au moins pour ceux qui skient sur la tête comme Martin Fowler a tenté le premier jour ; et Anguilla dans les Caraïbes — chaud et amusant, mais prenant du temps pour y arriver. Finalement, Snowbird et le ski ont emporté la décision ; cependant, quelques personnes — comme Ron Jeffries — souhaitent un endroit plus chaud pour la prochaine fois. 

Nous espérons que notre travail ensemble en tant que “ The Agile Alliance” aide d’autres dans notre profession à réfléchir au développement logiciel, aux méthodologies et aux organisations, de manières nouvelles – plus agiles. Si c’est le cas, nous avons atteint nos objectifs. 

Jim Highsmith, pour l’Agile Alliance 

©2001 Jim Highsmith