Tous les participants à cette manifestation ne sont pas au même niveau de connaissance sur les méthodes agiles. Cette introduction est destinée à présenter aux néophytes les idées principales véhiculées par ces méthodes et leur donner quelques clefs pour profiter de l'ensemble des présentations Et pour ceux qui connaissent déjà, cela reste une bonne occasion de se pencher à nouveau sur les fondamentaux.
Pour comprendre comment sont apparues les méthodes agiles, il faut un peu se placer dans le contexte historique. Depuis ses débuts, le développement logiciel s'est structuré en important des pratiques issues des disciplines de l'ingénierie qui l'ont précédé et qui opèrent sur le monde « physique ». Ce phénomène a notamment été amplifié par la longue proximité du logiciel et du matériel. On peut donc « fabriquer » un logiciel en divisant le travail, en affectant des ressources à des tâches et en établissant le diagramme de Gantt correspondant. Un classique en gestion de projet. Dans un tel cas, on fabrique un logiciel comme on fabrique une maison.Sauf qu'un logiciel n'a pas vraiment les mêmes caractéristiques qu'une maison. Une différence notable, c'est que cette division du travail pour faire un logiciel, ça n'existe pas vraiment. Ce n'est pas un fait nouveau : Frederick Brooks l'a montré il y a plus de 30 ans dans « Le mythe du mois-homme ». Il y expliquait, entre autres, que faire un enfant, ça prend 9 mois, quel que soit le nombre de femmes affectées à la tâche. Une des raisons majeures derrière cette impossibilité, c'est que la complexité de réalisation de la plupart des logiciels n'est pas un problème technique mais une question de communication et de compréhension mutuelles entre des personnes. Et ça on le sait aussi depuis longtemps : Tom DeMarco et Tim Lister ont écrit Peopleware il y a plus de 20 ans.
C'est sur ce terreau qu'ont grandi les méthodes agiles en profitant par ailleurs de l'émergence d'une communauté, celle du développement logiciel orienté objet qui s'est peu à peu emparée du concept de « pattern ». Les patterns, c'est une notion que l'on doit à Christopher Alexander, dans l'architecture, un domaine qui n'a rien à voir avec le logiciel. Et cette notion a été récupérée par les développeurs, d'abord pour formaliser des pratiques de conception, puis pour formaliser des pratiques de développement au sens le plus large. En 1995, Ward Cunningham crée le principe du wiki pour donner un support à cette communauté et faciliter, fluidifier les échanges qui mènent à la formalisation de ces pratiques. Depuis, le wiki a eu un destin plus large avec l'avènement d'internet... A côté de ça, on observe la montée du « Lean » tirée par la popularisation dans le monde industriel du système de production de Toyota.
A l'époque, on ne parle pas de « méthodes agiles », on a, avant tout, une communauté et des pratiques, qui engendrent la formalisation de toute une famille de méthodes de développement. Les plus connues sont Extreme Programming et Scrum mais elles sont loin d'être les seules. C'est à partir des années 2000 que la synthèse débute. Martin Fowler ecrit son article « The New Methodology » où il met en évidence les caractéristiques principales de ces méthodes : elles fonctionnent de manière plus adaptative que prédictive car elles souhaitent faire face aux exigences mouvantes et elles portent plus d'attention aux personnes qu'au process parce que les individus ne sont pas des unités de programmation interchangeables comme voudraient le faire croire certaines approches du développement logiciel. Cette « nouvelle méthodologie » est en fait un singulier mélange de chaos et de discipline. On peut parler de fonctionnement « chaordique ». C'est un terme imaginé par Dee Hock, le créateur de la carte Visa pour qualifier des organisations qui sont quelque part entre l'organisation hiérarchique et l'anarchie. Le terme « agile » n'est popularisé que l'année suivante. Début 2001, les principaux promoteurs de ces méthodes se réunissent. Ils écrivent le « manifeste agile » et ils fondent l' « alliance agile ».
Le manifeste agile, avec ses 4 valeurs et ses 12 principes, c'est un peu les tables de la loi des méthodes agiles. Ces lois ont une origine empirique : « par la pratique », « by doing it » en version originale. Les 4 valeurs sont donc : L'équipe. L'attention portée aux individus et à leurs interactions a plus de valeur pour un projet que les procédures et les outils utilisés. Le produit, le logiciel qui fonctionne. Il a bien plus de valeur que tous les documents, quelle que soit leur exhaustivité. La collaboration. Un client impliqué dans le développement du logiciel est un apport plus important qu'un contrat finement négocié. L'acceptation du changement. Il faut un plan, mais ce qui lui donne sa vraie valeur c'est la capacité que l'on a à le modifier pour intégrer les imprévus et notamment les demandes qu'un client n'aurait pas réussi à formuler plus tôt. Tout ça ne veut pas dire qu'il faut négliger le process, la doc et les contrats. Ca veut simplement dire qu'il y a des choses plus importantes sur un projet et que les méthodes agiles sont là pour garantir que l'on accorde la bonne importance à chaque chose.
Les 4 valeurs sont déclinées en 12 principes : La 1ère des priorités, c'est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles pour lui. Le changement est bienvenu, même tardivement dans le développement. Il est exploité comme avantage compétitif pour le client. Livrer fréquemment une application opérationnelle. « Fréquemment », c'est une variable qui dépend du contexte. On parle de périodes de deux semaines à deux mois. La plupart des méthodes privilégient la partie la plus courte de cette fourchette. Collaboration quotidienne entre le client, les utilisateurs ou leurs représentants et l'équipe de développement. Tout projet est bati autour de personnes motivées à qui on donne le soutien dont elles ont besoin. Il faut croire en leur capacité, leur faire confiance et ne surtout pas les blamer. La communication la plus efficace c'est en face à face et non pas à travers des intermédiaires qu'ils soient humains ou documents écrits. Le logiciel qui fonctionne est la meilleure mesure de la progression du projet. Le rythme de développement est soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. L'attention à l'excellence technique et à la qualité de la conception est permanente. En clair, on ne bacle pas la réalisation pour tenir des délais. La simplicité est essentielle. Il ne faut pas faire aujourd'hui ce dont on n'est pas sûr d'avoir besoin demain. Les agilistes disent « YAGNI » Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent. Enfin, à intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis ajuste son comportement dans ce sens.
![Un peu d'histoire ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)