Gestion de projet: Origine et valeurs des méthodes agiles

Le mouvement des méthodes agiles est né en 2001 aux États-Unis. Devant l’observation

faite du taux important d’échec des projets, notamment dans les années 1990, dix-sept

experts en développement logiciel, qui avaient chacun déjà mis au point et expérimenté

de nouvelles méthodes, se sont réunis afin d’échanger et de trouver un socle commun de

valeurs et de bonnes pratiques.

Le résultat de cette réflexion a abouti au Manifeste pour le développement logiciel agile1

et la création de l’Agile Alliance2, chargée de promouvoir l’agilité dans les organisations

et d’apporter du soutien aux équipes qui veulent démarrer un projet agile.

Le Manifeste décline quatre valeurs en treize principes applicables dans toute démarche

agile. Chaque méthode adopte ensuite sa propre terminologie et préconise un certain

nombre de pratiques.

Quelles sont les quatre valeurs du Manifeste ?

– Les individus et leurs interactions avant les processus et les outils.

– Des fonctionnalités opérationnelles avant la documentation.

– Collaboration avec le client plutôt que contractualisation des relations.

– Acceptation du changement plutôt que conformité aux plans.

Cela ne signifie évidemment pas qu’aucun processus n’est défini, qu’on ne se dote d’aucun

outil ; bien entendu, des plans et une documentation, certes plus réduits, sont produits.

Plus récemment, en 2005, a été publiée la « Déclaration d’interdépendance »3 avec,

parmi ses signataires, des acteurs majeurs de l’Agile Alliance. Cette communauté a

formalisé les valeurs mises en pratique qui les amenaient à rencontrer tant de succès et de

bons résultats dans leurs projets.

Elles se résument en six concepts, qui doivent être considérés de façon interdépendante :

valeur, incertitude, client, individus, équipe et contexte ; vous ne pouvez créer de la valeur si

vous ne collaborez pas avec un client qui, précisément, définit ce qu’est sa valeur ; vous

ne pouvez attendre d’une équipe qu’elle soit performante si vous ne reconnaissez pas la

contribution des individus qui la composent ; vous ne pouvez maîtriser l’incertitude si

vous ne prenez pas en considération la spécificité du contexte.

dans un document Word toute la décoration d’une maison virtuelle sans assistance informatique.

Cette chimère donne lieu à des batailles ou à des tensions régulières entre maîtr ise

d’ouvrage et maîtrise d’oeuvre. Je joue moi-même le rôle du client dans le cadre du développement

d’un outil de contrôle de qualité logicielle (Sonar). Autant je sais exactement où je veux

aller, autant il m’est très difficile de spécifier mon besoin. Chaque période de test offerte à la fin

d’une itération me permet d’ajuster ma vision du produit. C’est aussi cela l’agilité.

Une fois la question du pourquoi levée, les problématiques réelles de mise en oeuvre qui

peuvent se poser portent essentiellement sur le niveau d’implication du client. Cependant, si

on arrive à expliciter auprès de ce même client les bénéfices qu’il peut retirer de cette démarche

itérative et incrémentale, il y a de grandes chances qu’il soit prêt à jouer le jeu.

2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.

J’aime renverser cette question : comment penser que l’on peut être capable de livrer en une seule

fois une application ? Développer seulement quelques fonctionnalités à la fois permet un engagement

concret des utilisateurs. Le fait de leur montrer régulièrement l’application en cours de

croissance facilite leur feedback et leur permet de mieux creuser leurs propres besoins.