Contenu connexe
Historique des méthodes agiles
- 1. Introduction aux méthodesagiles Agile Tour 2008 - Toulouse
- 2. Un peu d'histoireMimétisme des disciplines de l'ingénierie pour organiser le développement logiciel MAIS La division du travail ne fonctionne pas (Le mythe du mois-homme - F.Brooks – 1975) Les problèmes sont plus sociologiques que technologiques (Peopleware – DeMarco/Lister – 1987)
- 3. Un contexte favorableL'émergence d'une communauté qui s'interroge sur les pratiques de développement logiciel Patterns - C.Alexander - 1977 OOPSLA - 1986+ / PLoP - 1994+ WikiWikiWeb & Portland Pattern Repository - W.Cunningham – 1995+ La montée du « Lean » Toyota Production System - T.Ohno - 1988
- 4. Une famille deméthodes Mise en forme des diverses pratiques Extreme Programming Scrum Crystal Clear ... Adaptative Software Development Feature Driven Development Dynamic Systems Development Method Un approche globale qui propose des principes d'organisation (et non plus une réaction à des méthodes lourdes en place) « The New Methodology » (M.Fowler - 2000) Plus adaptatif que prédictif Plus centré sur les personnes que sur les process Un fonctionnement « chaordique » Agile Manifesto & Agile Alliance (2001)
- 5. Manifesto for AgileSoftware Development Nous découvrons de meilleures manières de développer du logiciel par la pratique et en aidant les autres. À travers ce travail, nous en sommes arrivés à donner plus de valeur : Aux individus et à leurs interactions qu'aux processus et aux outils Au logiciel opérationnel qu'à la documentation exhaustive À la collaboration avec le client qu'à la négociation contractuelle À la réactivité face aux changements qu'au suivi d’un plan Bien qu’il y ait de la valeur dans les items de droite, nous accordons plus de valeur à ceux de gauche.
- 6. 12 Principes Satisfaireen livrant tôt et régulièrement Accepter les changements tardifs comme un avantage Livrer fréquemment une application opérationnelle Collaborer quotidiennement Faire confiance et supporter Transmettre les informations en face à face Mesurer l'avancement avec le logiciel réalisé Avancer à un rythme de développement durable Porter une attention continue à l'excellence technique Faire simple S'auto-organiser Réfléchir à ses pratiques et les ajuster régulièrement
Notes de l'éditeur
- #2 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.
- #3 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.
- #4 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.
- #5 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 ».
- #6 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.
- #7 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.