Agilité : principes et méthodologies

Histoire et évolution de l'Agilité en programmation

Introduction

Dans cet article, je vais vous expliquer à partir d’où, en quoi et comment l’avènement et la reconnaissance des méthodes Agiles se sont effectués. Si d’aucuns pensent que les méthodes dites ‘Agiles’ ne sont qu’une tendance, force est de constater qu’elles font aujourd’hui partie intégrante de l’écosystème de gestion de projet de développement.

Plutôt que de parler de méthode (trop réducteur), nous parlerons à travers cet article de philosophie, de cultured’approche ou de mouvement agile. Le terme méthode agile nous permettra en revanche de déterminer les outils méthodiques ayant découlé de cet état d’esprit.

Une histoire sur fond de contestation

Alors que les échecs de création et de développement de logiciel se succèdent lors des années 90, un mécontentement général gagne les experts qui se soulèvent alors contre le dictat des méthodes traditionnelles.

Un petit conglomérat de logisticiens – tous experts dans leur domaine – se réunit les 11 et 13 février 2001 afin de proposer d’éventuelles améliorations et apporter une vision plus moderne. De ces réunions naîtra le « Manifeste Agile » qui cherche à 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. »

Il est important de souligner l’importance de cette dernière phrase qui permet de ne pas tomber dans le cliché accordant de faux propos aux créateurs et sous-tendant le fait qu’un projet agile ne laisse pas de place à la spécification, aux plans et aux outils.

Les signataires sont : Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Sous les pavés philosophiques, la plage des principes

Après avoir établi les bases par ces quatre socles indissociables, les créateurs du manifeste ont apposé une liste de douze principes découlant de ce dernier, à savoir :

  1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  2. 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.
  3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  5. 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.
  6. 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.
  7. Un logiciel opérationnel est la principale mesure d’avancement.
  8. Les processus Argiles 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.
  9. Une attention continue à l’excellence technique et à une conception renforce l’Agilité.
  10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  11. Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  12. À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

En cherchant à contrecarrer les approches trop traditionnelles comme les cycles en V et waterfall (cascade dans la langue de Molière), ces 17 esprits savants ont permis l’émergence d’un principe gagnant – gagnant. En effet, par l’autorisation d’une plus large adaptabilité, le projet initial peut se targuer d’obtenir des spécificités qui n’étaient pas prévues au départ tandis que d’autres, pouvant s’avérer inutiles, ne se trouveront pas dans la version finale. Si les développeurs y gagnent du temps, le client se retrouve avec un produit final de qualité supérieure et dans un délai souvent plus court qu’annoncé.

Une même enquête menée par le « Standish Group » réalisée à 14 ans d’intervalle (1994 – 2008) démontre de l’intérêt d’un changement de mentalité. En effet, le constat qui en était tiré en 1994 était catastrophique : « 31% des projets informatiques sont arrêtés en cours de route, 52% n’aboutissent qu’au prix d’un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu’il n’en était demandé ; seuls 16% des projets peuvent être considérés comme des succès. » Situation qui n’avait guère évoluée en 2008 bien que le taux de complétion soit tout de même passé à 35%.

Réussite projet - Standish Group

En 2015, le Rapport Chaos du Standish Group (rapport annuel présentant l’état de l’art du développement logiciel) démontrait une nouvelle fois l’apport non négligeable du mouvement Agile dans la réussite de conception de logiciel avec un taux de réussite 2 à 3 fois supérieur vis-à-vis des méthodologies waterfall (cf. tableau ci-dessous).

Chaos Resolutioin By Agile Versus Waterfall

Lors d’un entretien donné au site InfoQ, la chargée de communication du Standish Group, Jennifer Lynch, a tenu a rappelé que ce sont l’ensemble des pratiques Agiles qui ont été pris en compte et non seulement certaines méthodes telles que Scrum ou Kanban.

Info Q

Les différentes méthodes Agiles

Si le choix d’adopter une gestion de développement adapté aux méthodologies Agile peut paraître une décision aisée, elle l’est jusqu’au moment de choisir la bonne méthode. Nombreuses par le nombre, elles le sont d’autant plus par les utilisations qui peuvent en être faites. En termes d’usage, voici les 10 méthodes Agiles les plus usitées en gestion de projet :

  • L’eXtreme Programming (XP)
  • Scrum
  • Test Driven Development (TDD)
  • Behavior Driven Development (BDD)
  • Domaine Driven Design (DDD)
  • Feature Driven Development (FDD)
  • Lean Software Development,
  • Agile Unified Process (Agile Up ou AUP)
  • Crystal
  • Dynamic Systems Development Method (DSDM)

Retrouvez le détail de chacune de ces méthodologies sur notre article dédié.

Quel avenir pour le mouvement

Imaginé pour répondre à des problématiques de développement web et autres écosystèmes informatiques, l’approche Agile tend à se diversifier pour atteindre finalement de nombreux autres secteurs et notamment industriels. En plaçant les nécessités du Product Owner (client) au cœur de la stratégie, elle offre une véritable possibilité d’adaptation aux chargés de projets, développeurs et autres techniciens.

Quelques chiffres

  • 56% – Le pourcentage d’équipes de gestion de projets qui utilisent exclusivement la méthode Scrum (source : VersionOne).
  • 24% – Le pourcentage d’équipes qui s’en servent en parallèle avec la méthode XP (source : VersionOne).
  • 58% – Le pourcentage de développeurs logiciels déclarant avoir entre trois et cinq ans d’expérience avec les méthodes agiles (source : VersionOne).
  • 5% – Le pourcentage d’entreprises ne possédant aucune équipe se classifiant comme « agile » (source : VersionOne).
  • 84% – Le pourcentage de sondés qui constatent une amélioration de la productivité grâce aux méthodes agiles (source : VersionOne).
  • 60% – L’augmentation en productivité dans le cas où une entreprise a une équipe agile stable (source : Rally Software, acquis par CA Technologies)

Si beaucoup lui promette un avenir radieux, les sceptiques se montrent de plus en plus nombreux. Ainsi, l’un des fondateurs du Manifeste, Andy Hunt, estime qu’Agile n’a pas du tout atteint son but initial. Ron Jeffries, lui aussi signataire du Manifeste n’a pas tardé à lui emboiter le pas en souhaitant « que le monde soit sûr pour les développeurs » tout en reprochant à la philosophie agile d’être écœurante au point de compliquer les tâches des développeurs. Rien que ça…

Nous vous laissons vous faire une idée. N’hésitez pas à partager en commentaire vos différentes expériences au sein d’entreprise ayant admis l’Agile comme une évidence ou, au contraire, réfutant son intérêt.

Notez cet article
0/5

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.