Méthode agile

Un article de Wikipédia, l'encyclopédie libre.

En ingénierie logicielle, les pratiques agiles mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients[1]. Elles s'appuient sur l'utilisation d'un cadre méthodologique léger mais suffisant centré sur l'humain et la communication[2]. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement[3],[4].

Cette approche a été popularisée à partir de 2001 par le Manifeste pour le développement agile de logiciels[5]. Les quatre valeurs et les douze principes adoptés dans ce manifeste sont issus d'un large éventail de méthodes dont Scrum et eXtreme Programming [4],[6]. Depuis lors, les méthodes qui s'inscrivent dans la philosophie de ce manifeste sont appelées « méthodes agiles[4] ».

Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles, impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles reposent sur un cycle de développement itératif, incrémental et adaptatif.

Fondements[modifier | modifier le code]

Le Manifeste pour le développement agile de logiciels est un texte rédigé aux États-Unis en 2001 par dix-sept experts du développement logiciels. Ils estimaient que le taux important d'échecs des projets de développements logiciels était dû à la lourdeur des méthodes traditionnelles inspirées du génie civil et s'appuyant sur un cycle de développement en cascade[4]. Chacun d'entre eux avait déjà mis au point et expérimenté de nouvelles méthodes plus légères. Les méthodes agiles ne sont donc pas apparues avec le manifeste agile. Cependant celui-ci a défini leurs dénominateurs communs et consacré le terme d'« agile » pour les référencer[4],[7]. Les valeurs et les principes du manifeste agile sont défendus et promus par l'Agile Alliance créée par certains des signataires.[8]

En s'appuyant sur leur expérience combinée du développement logiciel, les dix-sept signataires du manifeste ont proclamé qu'ils attachaient de l'importance « aux individus et leurs interactions plutôt qu'aux processus et aux outils », « à un logiciel fonctionnel plutôt qu’à une documentation exhaustive », « à la collaboration avec les clients plutôt qu'à la négociation contractuelle » et « à l’adaptation au changement plutôt qu'à l'exécution d’un plan ». Cela signifie que les éléments à gauche du mot « plutôt » dans chaque citation sont réputés avoir plus de valeur que ceux à droite, bien qu'il y ait aussi de la valeur dans ces derniers. Ces quatre citations sont appelées les quatre « valeurs » du manifeste agile[9].

Les quatre valeurs du manifeste agile ont été déclinées en douze principes afin d'aider opérationnellement les équipes qui souhaitaient les suivre.

Historique[modifier | modifier le code]

Les travaux sur le cycle de production itératif et incrémental remontent aux années 1930 et 1940, avec les travaux de Walter Shewhart et William Edwards Deming. Ces recherches sont appliquées à la production informatique à la fin des années 1950, notamment avec le développement de parties logicielles dans le cadre du programme Mercury[7]. Gerald Weinberg (en) mentionne un projet de développement réalisé en 1957 pour Motorola qui utilisait une technique similaire à ce qui sera plus tard l'eXtreme programming[7].

Les méthodes agiles sont l'aboutissement de nombreux travaux tels que ceux de Tom Gilb (cycle de vie évolutif)[10] en 1981, de Scott Shultz (production en itérations rapides), de Brian Gallagher et de Alex Balchin. Elles intègrent aussi les techniques JRP (Joint Requirements Planning) et JAD (Joint application design) (en) qui furent initiées par Dan Gielan, puis formalisées par Chuck Morris d'IBM en 1984 et diffusées sous forme de livres en 1989 par, entre autres, J. Wood et D. Silver. La première méthode agile[11] serait la méthode EVO[12], de Tom Gilb, publiée en 1976.

En 1986, Barry Boehm publie le modèle en spirale (développement incrémental) tandis que Hirotaka Takeuchi (en) et Ikujiro Nonaka publient « The new new product developpement game[13] » un modèle de développement de produits industriels basé sur l'engagement simultané des diverses disciplines concernées (ingénierie concourante).

En 1991, James Martin (en) (RAD), s’appuyant sur une vision de l'évolution continue des techniques informatiques, propose une méthode de développement rapide d’application. Sa structure itérative, incrémentale et adaptative, base des approches agiles actuelles, détermine le phasage essentiel et met en œuvre un principe adaptatif non restrictif fondé sur la validation permanente des utilisateurs et leur responsabilité directe dans la dynamique applicative.

À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publié par le Gartner Group en 1999, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisent des compléments et des évolutions (détails Développement rapide d'applications).

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se réunissent pour débattre d'un thème unificateur de leurs méthodes respectives. Les plus connus d'entre eux sont Ward Cunningham, l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber créateur de Scrum et Jeff Sutherland (en) son promoteur, Jim Highsmith (en), prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler et Dave Thomas, ainsi qu'Arie van Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts extraient alors de leurs usages respectifs les critères communs et les principes qui, selon eux, conduisent aux meilleures concepts de direction de projets et de développement de logiciels. De cette réunion émerge le Manifeste agile, considéré comme la définition canonique des valeurs du développement agile de logiciels et de ses principes sous-jacents par les praticiens et les universitaires[14],[15].

Pour décrire leur manifeste au mieux, les dix-sept signataires ont d'abord pensé au terme lightweight (léger) pour se fixer finalement sur agile (traduit à l'identique en français). D'après Fowler, ce terme traduit mieux l'aspect rapidement adaptatif de ces méthodes[16].

Au début des années 2000, une dizaine de méthodes agiles (dont XP Extreme programming et Scrum sont les principales représentantes) sont popularisées. L'apport méthodologique d'XP réside dans la préconisation de pousser à l’extrême les principales pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation consensuelle, de planification pilotée par l'utilisateur et de reporting visuel en temps réel de l'avancement ainsi que des problèmes rencontrés (affichage mural à base de post-it). Scrum propose un ensemble réduit de pratiques concentrées sur le développement de l'adaptabilité par l'apprentissage et l'auto-organisation.

Méthodes agiles au sens strict[modifier | modifier le code]

Les méthodes pouvant être qualifiées d'agiles, depuis la publication du manifeste Agile, sont :

Exemples de pratiques agiles[modifier | modifier le code]

Critiques[modifier | modifier le code]

Parmi les 17 signataires du manifeste agile, certains ont depuis émis des critiques non sur les principes Agiles, mais sur leur mise en pratique.

Ron Jeffries[19] montre plusieurs problèmes :

  • le dévoiement des méthodes agiles, notamment à des fins commerciales ;
  • le rejet des méthodes agiles par les développeurs ;
  • l'imposition de ces méthodes aux équipes (notamment lors d'une mauvaise utilisation des méthodes SAFe, Scaled Scrum, LeSS etc.).

Il conseille aux développeurs, non pas d'abandonner l'agile comme le titre de sa note laisse penser, mais de détacher sa réflexion des méthodes agiles imposées et de rester concentré sur le développement d'un logiciel qui marche, par exemple en mettant en pratique l'Extreme Programming.

Andy Hunt[20] quant à lui pense que si la mise en pratique des méthodes agiles ne marche pas, c'est parce que nous préférons appliquer des règles simples alors qu'elles imposent une constante remise en question. Les deux valeurs "inspection" et "adaptation au changement" étant essentielles, notamment dans la méthode Scrum, mais peu respectées, du fait de la nécessité de remise en question sous-jacente.

Martin Fowler[21] indique que la plupart des projets agiles en 2018 sont « faux-agile » et ne respectent pas ses valeurs et ses principes. Ainsi, les trois principaux défis sont de :

  • se battre contre l'industrie agile complexe et sa tendance à imposer les processus aux équipes ;
  • insister sur l'importance de l’excellence technique ;
  • organiser les équipes autour d'un produit et non d'un projet.

Dave Thomas[22] pointe du doigt le fait que beaucoup de personnes et d'entreprises ont profité du courant « agile » afin de vendre des produits et des services. De manière humoristique, il dit « l'Agile est mort, vive l'agilité ». Utiliser un nom plutôt qu'un adjectif permettrait selon lui de mieux détecter les vendeurs peu scrupuleux de produits et services prétendument agiles.

Robert C. Martin (Uncle Bob)[23] pense que le mouvement agile étant censé promouvoir les idéaux du Software craftsmanship mais a en fait horriblement échoué. Selon lui, le mouvement agile est devenu commercial, et a mis de coté ses valeurs d'origine.

Notes et références[modifier | modifier le code]

  1. (en) Ken Collier, Agile analytics : a value-driven approach to business intelligence and data warehousing, Addison-Wesley, (ISBN 978-0-321-66954-4 et 0-321-66954-1, OCLC 748597334, lire en ligne), p. 121
  2. (en) Alistair Cockburn, Agile software development : the cooperative game, Addison-Wesley, (ISBN 0-321-48275-1, 978-0-321-48275-4 et 978-0-321-48275-4, OCLC 70867033, lire en ligne), p. 34
  3. (en-US) « What is Agile Software Development? | Agile Alliance », (consulté le 18 septembre 2020)
  4. a b c d et e Véronique Messager, Gestion de projet agile : avec Scrum, Lean, eXtreme Programming ..., Eyrolles, (ISBN 978-2-212-13666-1 et 2-212-13666-8, OCLC 851918096, lire en ligne), p. 42, 49
  5. « Manifeste pour le développement Agile de logiciels », sur agilemanifesto.org (consulté le 18 septembre 2020)
  6. (en) Craig Larman, Agile and iterative development : a manager's guide, Addison-Wesley, (ISBN 0-13-111155-8 et 978-0-13-111155-4, OCLC 52638756, lire en ligne), p. 27
  7. a b et c (en) Craig Larman, Victor R. Basilii, « Iterative and incremental development : a brief history » [PDF], sur craiglarman.org,
  8. (en-US) « About Agile Alliance | Agile Alliance », (consulté le 23 septembre 2020)
  9. « Manifeste pour le développement Agile de logiciels », sur agilemanifesto.org (consulté le 18 septembre 2020)
  10. Tom Gilb, « Evolutionary Development », SIGSOFT Softw. Eng. Notes, vol. 6, no 2,‎ , p. 17–17 (ISSN 0163-5948, DOI 10.1145/1010865.1010868, lire en ligne, consulté le 31 mai 2019)
  11. "EVO is perhaps the oldest IID method with a significant agile and adaptative quality, first taking shape in the 1960s then published in 1976."(en) Craig Larman, « Agile & Iterative Development : Chap 7 », sur craiglarman.com, (consulté le 3 mai 2014)
  12. (en) Tom Gilb, « Fundamental Principles of Evolutionary Project Management », sur gilb.com, (consulté le 3 mai 2014)
  13. (en) Hirotaka Takeuchi (en) et Ikujiro Nonaka, « The New New Product Development Game (Article preview) », sur The magazine (Harvard business review), (consulté le 14 mai 2012)
  14. (en) Carmen Zannier, Hakan Erdogmus et Lowell Lindstrom, Extreme Programming and Agile Methods - XP/Agile Universe 2004: 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004, Proceedings, Springer Science & Business Media, (ISBN 978-3-540-22839-4, lire en ligne), p. 105, 106 :

    « The Agile Manifesto ans its principles represent quite pioneering work in coalescing and extending the critique of formalised software methods over the past decade or so and have been well received by practioners and academics. »

  15. (en) « A decade of agile methodologies: Towards explaining agile software development », Journal of Systems and Software, vol. 85, no 6,‎ , p. 1213–1221 (ISSN 0164-1212, DOI 10.1016/j.jss.2012.02.033, lire en ligne, consulté le 23 septembre 2020)
  16. « Writing The Agile Manifesto », sur martinfowler.com (consulté le 17 septembre 2020)
  17. Claude Aubry, Scrum, 5e édition - Pour une pratique vivante de l'agilité, Dunod, (ISBN 978-2-10-080133-6, lire en ligne), p. 21, 27
  18. Cockburn, Alistair., Crystal clear : a human-powered methodology for small teams, Addison-Wesley, [ca. 2010] (ISBN 0-201-69947-8 et 978-0-201-69947-0, OCLC 730557758, lire en ligne)
  19. (en) « Developers Should Abandon Agile », sur https://ronjeffries.com, (consulté le 24 mai 2018)
  20. (en) « The Failure of Agile », (consulté le 24 mai 2018)
  21. « The State of Agile Software in 2018 », sur martinfowler.com (consulté le 2 septembre 2019)
  22. (en) Dave Thomas (pragdave), « Agile is Dead (Long Live Agility) », sur Agile is Dead (Long Live Agility) (consulté le 2 septembre 2019)
  23. « Clean Coder Blog », sur blog.cleancoder.com (consulté le 3 septembre 2019)

Annexes[modifier | modifier le code]

Sur les autres projets Wikimedia :

Articles connexes[modifier | modifier le code]