En réalité, c’est quoi la méthode agile ?

Les origines

Au départ cantonnée à l’univers informatique, la première méthode agile largement exploitée fut la méthode Scrum, datée du début des années 90.

L’envol débuta réellement au printemps de l’an 2000 en Oregon avec la rencontre de figures éminentes du développement logiciel. Objectif, croiser leurs méthodologies respectives sur la gestion de projet. De cette première rencontre émergèrent différents concepts autour d’une méthodologie « Light ».

Des articles furent rédigés sur le sujet mais aucun consensus ne fut vraiment trouvé. Et pour l’anecdote, personne n’aimait le nom « Light » bien qu’il était difficile de s’en éloigner tant il était pertinent. Ce sentiment est bien résumé par Alistair Cockburn, auteur et entrepreneur intéressé dès les années 90 par la méthodologie projet :

« I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting. It somehow sounds like a bunch of skinny, feebleminded lightweight people trying to remember what day it is. »

L’histoire ne pouvait pas en rester là et du 11 au 13 février 2001 dans les montagnes Wasatch au cœur de l’Utah, 17 méthodologistes et spécialistes du développement logiciel se re-rencontrèrent pour donner naissance au « Manifesto for Agile Software Development ».

Le Manifeste pour le développement Agile de logiciel

Ce sont 4 valeurs :

« 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. »

Une rédaction quasi biblique dont les impacts ont transformé nos manières de travailler.

En effet, lors de la rédaction de ce manifeste, les co-auteurs anticipèrent qu’à l’aube du e-business, du e-commerce et d’internet, c’était l’organisation même des entreprises qui allait devoir s’adapter. Et ils eurent le nez creux. Les entreprises sont aujourd’hui largement séquencées en projets qui reprennent ces fondamentaux.

Attention cependant, il n’y a pas une méthode agile

En informatique notamment, il existe plusieurs méthodes agiles largement utilisées. Et si vous êtes de la partie, vous avez surement déjà entendu parler de méthodes répandues comme Scrum, eXtreme Programming, RAD, Chrystal Clear etc.

Les fondations restent cependant similaires et peuvent s’appliquer à n’importe quel projet.

L’approche en cascade : au lieu de séquencer un projet suivant une structure de pensée logique, il est plus efficace de paralléliser les travaux et procéder petit pas à petit pas sur chaque sujet.

Deux bonnes raisons à cela : si vous êtes dans l’attente d’une réponse, c’est tout le projet qui est arrêté. Par ailleurs, vous aurez plus de chances avec cette méthode de trouver des nouvelles idées ou des opportunités d’optimiser votre projet lors de son développement !

En effet, un des principes de la méthode agile estime que détailler l’intégralité d’un projet avant de commencer à le développer est contre-productif.

Un des risques bien connu est l’effet tunnel : on établit un cahier des charges précis, avec un budget très précis et contractualisé à la virgule près avec des interlocuteurs identifiés. On se revoit ensuite à la fin du projet sans échanger entre temps avec un rendu final respectant toutes les closes.

Vous le savez déjà, ceci est une chimère car dans la majorité des cas :

  • Le projet sera abandonné en cours de route car bloqué par un imprévu non contractualisé en amont
  • Sera terminé au prix d’un dépassement de budget important
  • Ne prendra pas en compte de nouveaux besoins qui auront pu émerger mais ne pourront être adressés

Dans un monde où tout va très vite, il est difficile de définir un cahier des charges précis dès le début. Nous n’avons pas toutes les cartes pour anticiper l’ensemble des contraintes et risques inhérents à un projet, d’autant plus quand celui-ci est complexe.

L’analogie du… Roadbook pour rédiger votre cahier des charges

La rédaction agile de votre cahier des charges peut être comparée à la rédaction de votre itinéraire de vacances.

Tout commence par la définition de la ligne de départ qui représente votre situation – ressources, organisation, budget, outils, besoins – au moment de débuter le projet et une ligne d’arrivée qui sera votre vision, votre objectif.

On va ensuite regarder l’itinéraire général pour atteindre la ligne d’arrivée. Pas besoin d’être particulièrement précis, nous ne maitrisons de toute façon tous les facteurs qui viendront impacter le trajet (conditions météo, état de la route…).

Enfin, on va découper ce trajet en étapes aussi appelées lots ou sprints. On peut comparer un lot à une fonctionnalité par exemple. On décrira pour chacune de ces étapes des caractéristiques générales propres pour, encore une fois, avoir un fil conducteur et savoir globalement où on doit aller.

L’analogie s’arrête là, on passe maintenant au concret

Quand on prend la route, c’est une étape après l’autre. Dans la méthode agile au contraire, on va aborder chaque lot en même temps et progresser sur chacun par petits pas.

Les intérêts sont multiples :

  • Délivrer des résultats concrets rapidement
  • Maintenir un contact permanent avec son client qui peut tester tout le temps
  • Intégrer de nouveaux besoins à son cahier des charges à coût moindre
    Contourner un problème rencontré sans que la réussite du projet en dépende
  • Il faut aussi correctement s’organiser avec :

Une personne responsable de la bonne réussite du projet qui pilote son bon avancement

  • Une équipe dont les rôles et responsabilités sont bien déterminés
  • Un référentiel projet rédigé qui hiérarchise les résultats attendus
  • Des outils collaboratifs qui permettent de facilement voir la situation du projet à tout moment
  • Des réunions d’avancement avec toutes les parties prenantes (quotidiennes dans le meilleur des cas)

Pourquoi cet article ?

La méthode agile est devenue un terme marketing répandu qui traduit pourtant une méthodologie qui requiert une certaine discipline et on sait de quoi on parle !

Il est dès lors important de distinguer « l’approche agile » qui relève plus d’un état d’esprit ouvert et pragmatique de la « méthode » qui est plus un cadre organisationnel dans lequel on va faire rentrer un projet.

N’hésitez pas à venir poursuivre l’échange avec nous !

Les 12 principes sous-jacents de la méthode agile

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

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.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

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.

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.

Un logiciel opérationnel est la principale mesure d’avancement.

Les processus Agiles 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.

Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées.

À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

Retour aux articles