MÉTHODES AGILES : Pourquoi les adopter ?

1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)
Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TechnoratiSubmit to TwitterSubmit to LinkedIn

46-methodes-agiles-pourquoi-les-adopter

Les méthodes Agiles consistent en un ensemble de pratiques imaginées pour pallier les difficultés rencontrées dans les cycles de développement en cascade ou en V, encore omniprésentes.

1. Les méthodes traditionnelles

Les méthodes traditionnelles prônent un enchaînement séquentiel des différentes activités, depuis les spécifications jusqu’à la validation du système, selon un planning préétabli. Elles visent à mieux prédire la façon dont les choses « devraient » se passer. Malheureusement, cette vision rassurante est bien loin de la réalité des projets. Les activités d’ingénierie ne sauraient se succéder strictement sans qu’aucun changement ne vienne perturber un planning qui n’a de durée de vie que le temps de le prononcer.

La conséquence est que plus de 80% des projets exécutés selon ces méthodologies connaissent des retards, des dépassements budgétaires, quand ils ne finissent pas en échec total, pour n’avoir pas su satisfaire les attentes des clients.

Ces problèmes sont liés à plusieurs caractéristiques fondamentales de ces anciennes méthodologies :

  • le rôle joué par le client : le client intervient principalement au moment du lancement du projet, à quelques jalons majeurs parfois espacés de plusieurs mois, et surtout en fin de projet pour la réception et la recette du système. Cet « effet tunnel » conduit à une solution souvent inadaptée et de piètre qualité.
  • le mode contractuel forfaitaire qui : durcit les relations entre client et fournisseur, rend le passage de témoin long et douloureux à la fin du projet.
  • une trop grande standardisation des activités d’ingénierie, dont l’enchaînement se révèle souvent inefficace. Formellement, les contrôles d’avancement et de qualité ne peuvent être menés que sur la base de documents dans les premières étapes, et bien des organisations sont devenues des usines à produire de la documentation au lieu de produire de la valeur (fonctions logicielles) pour les clients et les utilisateurs.
  • le passage de relai entre les phases successives dans lesquelles oeuvrent des équipes différentes, généralise une relation de type client-fournisseur et n’encourage ni l’empathie ni l’esprit d’équipe, bien au contraire. Chaque transition se traduit par une perte de temps, de savoir, d’informations ou de responsabilité.

2. Les méthodes agiles

Les méthodes agiles préconisent :

  • L’adoption d’un cycle itératif et incrémental permettant à une équipe de s’adapter au contexte ainsi qu’aux changements qui ne manquent pas de survenir au cours d’un projet.
  • L’implication du client dans le développement, permettant au client et à l’utilisateur de donner leur feedback quant au devenir de l’application en cours de développement, annulant ainsi tout « effet tunnel ».
  • La définition d’objectifs à court terme qui permet de maintenir une pression constante mais supportable sur l’équipe, alors qu’au début d’un cycle en V chacun a l’impression d’avoir suffisamment de temps devant lui et subit finalement une pression énorme à l’approche de la livraison.
  • La collaboration entre les personnes et l’intégration des équipes qui combat les fameux passages de relais en rassemblant dans un même espace toutes les énergies et la compétence de personnes centrées sur l’application à réaliser. Plus aucune barrière et des tâches définies par l’équipe au meilleur moment, c’est-à-dire quand on en a besoin, plutôt qu’au début du projet.
  • La livraison d’un produit opérationnel de bonne qualité parce que souvent testé, doté de la seule documentation strictement nécessaire, et répondant à coup sûr aux vrais besoins des utilisateurs puisqu’il est régulièrement soumis à leur feedback.

3. Le manifeste Agile

Le Manifeste Agile propose 4 principes fondamentaux : 

principes agiles

Forts de ces principes, on voit qu’une organisation, un département, une business unit, un projet et même une équipe peuvent adopter l’Agilité avec succès.

Mais qu’en est-il d’un projet déjà démarré ou en difficulté ? L’Agilité peut également dans ce cas améliorer les résultats déjà obtenus et faciliter la résolution de bon nombre des difficultés vécues. Elle va amener les personnes impliquées à :

  • mieux collaborer,
  • prendre du recul sur l’application en priorisant les actions et en remettant à plat le chiffrage initial,
  • donner plus de visibilité aux clients et utilisateurs,
  • éliminer « l’effet tunnel » induit par le cycle en V, en le remplaçant par des itérations courtes et maîtrisées.

4. Les pratiques agiles les plus répandues

Il existe de nombreuses méthodes Agiles (XP, Crystal, FDD, Scrum...pour les plus connues) fondées sur les principes évoqués ci-dessus. Chaque méthode apporte son propre lot de techniques et de pratiques, les unes concernant plutôt le pilotage de projet, les autres, plutôt l’ingénierie.

Les pratiques Agiles les plus répandues sont issues de ces différentes méthodes :

  • l’implication forte du client à travers le rôle de Product Owner,
  • l’utilisation d’un Product Backlog pour gérer dynamiquement les fonctions du produit à réaliser, et les priorités métier associées ; le Product Backlog est élaboré en début de projet, et révisé autant que nécessaire,
  • le Scrum Meeting, est une courte réunion quotidienne (environ 15’) qui rassemble tous les membres de l’équipe de développement. Cette réunion permet aux personnes d’échanger des informations sur l’avancement des tâches, signaler les problèmes rencontrés et demander de l’aide si nécessaire,
  • le Retrospective Meeting est une réunion de fin d’itération, focalisée sur les événements survenus et l’analyse causale des dysfonctionnements, des pertes de productivité et de qualité. Un ou deux axes d’amélioration seront privilégiés de façon consensuelle et se traduiront par des tâches dans le backlog de l’itération suivante,
  • l’Iteration Planning, en début d’itération, permet à l’ensemble de l’équipe projet de découvrir la liste des fonctions à implémenter, d’identifier et d’estimer les tâches de réalisation,
  • la Vélocité est un indicateur qui mesure le « volume » de logiciel produit par l’équipe au cours d’une itération. Ce « volume » est estimé préalablement pour chaque fonction (ou User Story),
  • le Burndown Chart est une représentation graphique de l’avancement des travaux au cours d’une itération : la courbe représente simplement le reste à faire (en charge) tel qu’il est estimé chaque jour par l’équipe. Le point initial représente l’effort total estimé pour l’itération pour l’ensemble de l’équipe, généralement en heures,
  • l’Intégration Continue consiste à compiler, assembler, vérifier et tester l’ensemble du code source dès qu’un nouvel élément est mis à disposition, soit, idéalement, une à plusieurs fois par jour,
  • le Test Driven Development (TDD) consiste à écrire les programmes de tests unitaires avant de programmer les fonctions elles-mêmes, puis d’adapter le code source testé unitairement jusqu’à obtenir un code de qualité (Refactoring),
  • le Test Driven Requirement (TDR) permet de spécifier le logiciel par l’exemple – i.e. les exigences logicielles sont exprimées sous forme de cas de test,
  • enfin le Pair Programming consiste à programmer en binôme dans le but d’être plus efficace en termes de conception, de revue de code et de transfert de compétences.
128x128 download Fiche à télécharger 
MÉTHODES AGILES - Le manifeste
Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TechnoratiSubmit to TwitterSubmit to LinkedIn