Préface

En l’honneur du 18e anniversaire du Manifeste Agile pour le développement logiciel, où 17 gars extraordinaires se rencontrent (maintenant 16 en vie, Salud à Mike Beedle), Agile Lounge ™ souhaite marquer cette semaine avec des blogues et/ou des vlogues chaque jour entre le 11 et le 13 février 2001.

Alexandre-Frederic, fondateur d’Agile Lounge et auteur du blog ScrumMaster Lounge, souhaite rendre hommage en posant également la question suivante: 18 ans – l’agilité a-t-elle suffisamment mûri dans notre monde du travail? Quel est l’état de la mentalité. Combien d’évolution ou de dévolution se sont produits depuis lors. Les Agilistas sont-ils vraiment agile dans la culture de la transformation? Combien de personnes sont créatives versus réactives?

Vous verrez également le début de la série Vlog Agility GaGa pour aborder de manière sarcastique et musicale les questions et réflexions dont NOUS avons besoin en tant qu’agent de transformation avec une agilité, une culture agile et des soi-disant pratiques autonomes.

Aujourd’hui, j’aimerais continuer la semaine du 18e anniversaire avec un peu d’histoire en reproduisant l’article de Jim Highsmith dans la version française de cette histoire de l’agilité tel que promis hier lors de la publication en anglais car, oui, nos traductrices ont réussi l’objectif du sprint. Nous aurons quelques surprises tout au long de la semaine. Alors asseyez-vous, détendez-vous et profitez de la semaine du 18e anniversaire du Manifesto Agile au Agile Lounge™

Du 11 au 13 février 2001, à l’hôtel The Lodge à Snowbird, dans les montagnes de Wasatch, en Utah, dix-sept personnes se sont réunies pour discuter, skier, se détendre et essayer de trouver un terrain commun, et bien sûr, pour manger. 

Ce qui a émergé est le Manifeste Agile pour le «Développement de logiciels». 

Des représentants de Extreme Programming, SCRUM, DSDM, développement de logiciels adaptatifs, Crystal, développement basé sur les fonctionnalités, programmation pragmatique, et d’autres sympathisants face au besoin d’une alternative aux processus de développement de logiciel basés sur la documentation et la lourdeur procédurale se sont convoqués.

Il serait difficile de trouver un plus grand rassemblement d’anarchistes organisationnels. Le résultat de cette réunion était donc symbolique: un Manifeste pour le développement logiciel agile, signé par tous les participants. 

Le seul problème avec le terme agile est venu de Martin Fowler (un Britannique pour ceux qui ne le connaissent pas) qui a admis que la plupart des Américains ne savaient pas comment prononcer le mot “agile”.

Les préoccupations initiales d’Alistair Cockburn reflétaient les premières idées de nombreux participants. “Personnellement, je ne m’attendais pas à ce que ce groupe particulier d’agilités soit jamais d’accord sur quoi que ce soit de fond.” Mais ses sentiments après la réunion ont également été partagés: «En ce qui me concerne, je suis ravi du phrasé final [du Manifeste]. J’ai été surpris que les autres aient semblé tout aussi ravis du phrasé final. Nous nous sommes donc mis d’accord sur quelque chose de profond. “

Se nommant nous-mêmes “The Agile Alliance”, ce groupe de penseurs indépendants sur le développement de logiciels, et parfois concurrents, s’est mis d’accord sur le Manifeste pour le développement de logiciels agiles affiché sur la page de titre du site web du Manifeste.

Mais si le Manifeste contient des idées spécifiques, il existe un thème plus profond qui anime de nombreux membres de l’alliance, mais pas tous. À la fin de la réunion de deux jours, Bob Martin a dit en plaisantant qu’il était sur le point de faire une déclaration “pâteuse”. Cependant, tout en étant empreints d’humour, peu étaient en désaccord avec les sentiments de Bob – 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 la promotion de modèles organisationnels basés sur les gens, la collaboration et la construction des types de communautés organisationnelles dans lesquelles nous voudrions travailler. À la base, je pense que les méthodologistes agiles ont vraiment pour objectif de fournir des produits de qualité aux clients en opérant dans un environnement qui fait plus que parler des “personnes comme notre atout le plus important”, mais en réalité des “actes” comme le plus important, et perdre le mot “atout”. Ainsi, en dernière analyse, la montée fulgurante de l’intérêt pour les méthodologies agiles – et parfois d’énormes critiques à leur égard – concerne les méthodologies agiles.

Par exemple, je pense qu’au bout du compte, la programmation extrême a gagné en popularité et en intérêt, non pas à cause de la programmation par paire ou du refactoring, mais parce que, dans leur ensemble, les pratiques définissent une communauté de développeurs libérée du bagage des sociétés de Dilbertesque. 

• 

• 

• 

• 

Kent Beck raconte l’histoire d’un premier travail dans lequel il a estimé un effort de programmation de six semaines pour deux personnes. Après que son responsable ait réaffecté l’autre programmeur au début du projet, il a achevé le projet en douze semaines et s’est senti terriblement mal! Le patron – bien sûr – a expliqué à Kent à quel point il avait été lent au cours des six dernières semaines. Kent, quelque peu découragé parce qu’il était un “échec” en tant que programmeur, a finalement réalisé que son estimation initiale de 6 semaines était extrêmement précise – pour 2 personnes – et que son “échec” était en réalité l’échec du manager, voire l’échec de l’état d’esprit standard des processus «fixes» qui sévit si souvent dans notre industrie.

Ce genre de situation se produit tous les jours – marketing, gestion, clients externes, clients internes et même les développeurs – ne veulent pas prendre de décisions difficiles, ils imposent donc des exigences irrationnelles en imposant aux entreprises des structures de pouvoir. Ce n’est pas simplement un problème de développement logiciel, il s’applique à toutes les organisations de type Dilbertesque.

Pour réussir dans la nouvelle économie, pour entrer de manière agressive dans l’ère du commerce électronique et du Web, les entreprises doivent se débarrasser de leurs manifestations de Dilbert et  de politiques «make-work» et arcanes. 

Cette liberté des inanités de la vie d’entreprise attire les partisans des méthodologies agiles et effraie les amateurs de musique (vous ne pouvez pas utiliser le mot «merde» dans un journal professionnel) pour les traditionalistes. 

Très franchement, les approches Agiles effraient les bureaucrates des entreprises, du moins ceux qui sont heureux de pouvoir agir pour le processus plutôt que d’essayer de faire de son mieux pour le “client” et de fournir quelque chose de concret, opportun et tangible – car ils sont à court de ressources. endroits pour se cacher.

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 dans le but de classer un diagramme dans un référentiel d’entreprises poussiéreux. Nous embrassons la documentation, mais pas des centaines de pages de « ne seront pas lu » et resterons des tomes conservés et rarement utilisés. Nous planifions, mais reconnaissons les limites de la planification dans un environnement turbulent. Ceux qui qualifieraient de “hackers” les partisans de XP, de SCRUM ou de l’une des autres méthodologies agiles ignorent à la fois les méthodologies et la définition originale du terme pirate.

La réunion de Snowbird avait été préparée lors d’une réunion antérieure de promoteurs de la programmation extrême et de quelques “étrangers”, organisée par Kent Beck au Rogue River Lodge dans l’Oregon au printemps 2000. 

Au cours de la réunion, les participants ont exprimé leur soutien à une variété de méthodologies “légères”, mais rien de formel ne s’est produit. Au cours de l’année 2000, plusieurs articles ont été écrits faisant référence à la catégorie des processus “légers”. Un certain nombre de ces articles faisaient référence à des “méthodologies légères –  telles que la programmation extrême, le développement de logiciels adaptatifs, Crystal et SCRUM”. Au cours des conversations, personne n’a vraiment aimé le surnom “Light”, mais il a semblé s’encrer pour le moment.

En septembre 2000, Bob Martin, d’Object Mentor à Chicago, a lancé la prochaine réunion avec un courrier électronique. “J’aimerais organiser une petite conférence (deux jours) entre janvier et février 2001 à Chicago. Le but de cette conférence est de réunir tous les responsables des méthodes légères dans une même salle. Vous êtes tous invités; Je serais intéressé de savoir à qui d’autre je devrais m’adresser. ” Bob a créé un site Wiki et les discussions ont fait rage.

Dès le début, Alistair Cockburn a écrit une épître qui identifiait le mécontentement général avec le mot ‘Light’: “Cela ne me dérange pas que la méthodologie soit qualifiée de légère, mais je ne suis pas sûr que je veuille être appelé un poids léger assistant à une réunion de méthodologistes légers. Cela ressemble en quelque sorte à un groupe de personnes légères ou maigres et débraillés qui essaient de se souvenir du jour.

Le débat le plus acharné était sur l’emplacement! Chicago suscitait de vives inquiétudes en hiver: froid et rien d’amusant à faire; Snowbird, Utah – des choses froides mais amusantes à faire, du moins pour ceux qui skient sur la tête, comme l’a essayé Martin Fowler le premier jour; et Anguilla dans les Caraïbes – chaleureuse et amusante, mais longue à s’y rendre. Snowbird et le ski ont fini par l’emporter; Cependant, quelques personnes, comme Ron Jeffries, veulent un endroit plus chaud la prochaine fois.

Nous espérons que notre collaboration en tant qu’Alliance Agile aidera les autres membres de notre profession à réfléchir au développement, aux méthodologies et aux organisations de logiciels, de manière nouvelle – plus agile -. Si tel est le cas, nous avons atteint nos objectifs.

Jim Highsmith, pour l’Agile Alliance

© 2001 Jim Highsmith, tous droit réservée.