Menu

Sections thématiques

L'essentiel sur les méthodes Agiles

Découvrez les principes des approches Agiles et leurs apports comparés aux méthodes classiques de gestion de projet - en particulier pour le framework de travail Scrum.

Rédigé par Laurent GRANGER - Mis à jour le 03/09/2023

Qu'est-ce qu'une méthode agile ?

Alors que les méthode traditionnelles visent à traiter les différentes phases d'un projet d'une manière séquentielle (que l'on nomme aussi cycle de développement en cascade ou encore cycle en V ), le principe des méthodes Agiles est de le découper en sous-parties (ou sous-projets) autonomes (on parle également de développement itératif).

Les parties (itérations ) forment le projet dans sa globalité.

Le Manifeste Agile, les principes fondateurs

Ces méthodes découlent du Manifeste Agile, des pratiques édictées par des experts en 2001 pour améliorer le développement de logiciels.

Les 4 valeurs mises en exergues 

  • la primauté des personnes et des interactions sur les processus et outils.
  • une préférence pour un logiciel fonctionnel plutôt qu'une documentation complète.
  • une relation autre avec les clients : une collaboration permanente remplaçant une négociation contractuelle.
  • une adaptation continue au changement et non le suivi rigide d'un plan.

Découlant de ces valeurs, le Manifeste définit 12 principes 

  1. 1 - La priorité n°1 est d' obtenir la satisfaction client au plus tôt par la livraison rapide et régulière de fonctionnalités attendues.
  2. 2 - Accepter les demandes de changement en cours de projet . Ce sont des opportunités pour donner plus de valeur au projet et coller aux vrais besoins des clients.
  3. 3 - Mettre en œuvre des livraisons rapides reposant sur des cycles courts (quelques semaines). Ces livrables doivent être opérationnels pour permettre des tests de validation des fonctionnalités attendues.
  4. 4 - Coopération forte et continue entre les utilisateurs et le développement. A 'inverse des méthode classiques où les rencontres entre les utilisateurs et la maîtrise d'oeuvre interviennent surtout en début et en fin de projet.
  5. 5 - Donner de l'autonomie à des personnes impliquées et leur faire confiance.
  6. 6 - Privilégier le face à face comme canal de communication entre les parties. Les interactions sont plus efficaces et plus riches. Tout va plus vite.
  7. 7 - L'important est d'avoir une application opérationnelle.
  8. 8 - Avancer avec un rythme constant compatible avec ce que peut produire l'ensemble des acteurs.
  9. 9 - Focus sur la qualité technique et la qualité de conception pour construire une base solide renforçant l'agilité.
  10. 10 - Rester simple dans les méthodes de travail : ne faire que ce qui est nécessaire.
  11. 11 - Une équipe qui s'organise elle même produit de meilleurs résultats.
  12. 12 - En revoyant régulièrement ses pratiques, l'équipe adapte son comportement et ses outils pour être plus efficace.

Quels sont les avantages ?

Cette approche permet d'obtenir :

  • - plus de flexibilité en travaillant sur des sous-parties autonomes. Elles peuvent être conçues, testée, modifiées de nouveau sans que l'ensemble du projet ne soit impacté. La prise en compte de besoins non identifiés dans la phase d'analyse ou bien l'émergence de nouvelles fonctionnalités au cours du développement peuvent être implémentées. Par expérience, il est difficile de penser à tout dans la phase de définition de besoin pour une approche classique de gestion de projet.
  • - Plus de fiabilité et de qualité : en simplifiant la complexité, en testant en continu, en favorisant les feedbacks, les échanges avec les clients.
  • - Des risques réduits : détection rapide grâce à des cycles courts.
  • - Une meilleure maîtrise des coûts : pas de coûteux retours en arrière - si nécessaire le projet peut être stoppé rapidement.

Mais aussi des limites

La flexibilité poussée à l'extrême peut conduire à un enlisement du projet . De nombreuses itérations sans que des directions ou décisions ne soient figées représentent un réel danger. L'une des causes possibles des revirements incessants des clients quant à leurs spécifications.

Dans ces situations, le chef de projet  (quelle que soit sa dénomination dans la méthode choisie) doit être capable d'arbitrer pour le bien du projet, mais également celui... du client.

Les méthodes Agiles

Les principes de l'agilité sont repris d'une manière structurée par plusieurs méthodes. Focus sur l'une des plus populaires :

La méthode Scrum

Initiée par Hirotaka Takeuchi and Ikujiro Nonaka puis formalisée par Ken Schwaber et Jeff Sutherland, cette méthode propose un cadre très structuré pour appliquer les principes de l'agilité.

Le Sprint, le coeur de Scrum

Cette approche repose sur des itérations de 2 à 4 semaines. Ce sont les fameux "Sprints" . Il s'agit des sous-parties d'un projet comme le définit le principe Agile. Chaque Sprint a pour objectif de livrer au client une version potentiellement utilisable du produit.

Les Sprints successifs ajoutent des fonctionnalités au produit ou améliorent celles déjà développées. On parle d'incrément de produit.

Un Sprint démarre lorsque le précédent est terminé. Il s'agit d'un processus incrémental.

Ce cadre repose sur 3 piliers que sont :

- la transparence : élaboration d'un standard commun pour permettre une compréhension partagée.

- l'inspection : des vérifications sont effectuées régulièrement.

- l'adaptation : en cas de dérive constatée lors de l'inspection, des ajustements sont décidés.

Les Sprints se structurent autour de plusieurs outils organisationnels (appelés événements)  

  • Sprint planning ( Planification du sprint) : réunion pour sélectionner et planifier les priorités de chaque Sprint en terme de liste des fonctionnalités produit (Sprint Backlog).
  •  S crum  (M élée quotidienne ) : réunion journalière de coordination entre les membres de l'équipe projet. Elle prend fréquemment la forme de "Stand-up meeting" (réunion de courte durée, 10-15mn, tenue debout).
  • Sprint Review  (R evue de Sprint ) : réunion de synthèse à la fin de chaque Sprint afin de valider les fonctionnalités développées.
  • Sprint Retrospective  (R étrospective de Sprint) : venant immédiatement après la revue de Sprint, il s'agit d'un bilan dont l'objectif est l'amélioration continue des pratiques. L'équipe échange sur les réussites, les difficultés, relève ce qui a fonctionné ou non. Avec toujours des leçons à tirer pour les prochains Sprints.

Comprenant des entrants et sortants du processus, appelés "artéfacts"

  • Product Backlog : liste des fonctionnalités du produit.
  • Sprint Backlog : planification   des éléments du Product Backlog à mettre en oeuvre lors du Sprint pour livrer l'incrément de produit doté des fonctionnalités requises pour cette étape. Le Sprint Backlog n'est pas figé, mais est amené à évoluer durant le Sprint.
  • L'incrément de produit : déjà évoqué plus haut.

Avec des rôles définis pour chacun 

  • Product Owner - PO  (propriétaire du produit) :  l'expert métier, le maître d'ouvrage , représente le client et intervient sur le coté fonctionnel.
  • Scrum Master  (maître de mêlée) :  le coordinateur du projet et le garant du respect de la méthode Scrum.
  • Team (équipe) :  les autres intervenants sur le projet (notamment les développeurs).

Les autres méthodes de développement Agile

A côté de Scrum, il existe d'autres approches, avec chacune leurs spécificités :

  • Extreme Programming (XP) : très répandue dans l'ingénierie logicielle
  • FDD (Feature-Driven Development)
  • Dynamic System Development Method (DSDM) : une des plus anciennes
  • Adaptive software development (ASD) 
  • Crystal Clear : orienté "petites équipes" 

Témoignage : des principes agiles qui peuvent vraiment nous aider

JL Roge

Jean-Louis ROGE

 

Jean-Louis est Ingénieur informatique, Directeur des services d'informations (DSI).

Il a été PCO (contrôleur de projet), responsable de la planification, de la mise à jour et du contrôle de projets pendant plus de 20 ans dans différents secteurs d’activités tels que les télécoms, la grande distribution et le service public.  Twitter    Site 

L’origine de la démarche agile, telle qu’on la connait aujourd’hui vient du monde du développement logiciel et se base tout d’abord sur un changement radical de vision du management des projets par rapport à la démarche classique.

On passe d’une approche séquentielle, connue également comme « modèle en cascade » :

À une nouvelle approche itérative et collaborative : 

Cela signifie que l'on passe de réaliser un même projet en un seul cycle à l’aborder en plusieurs itérations. Celles-ci se réalisent en étroite collaboration avec le client et produisent toujours des résultats, adaptés à chaque moment du projet.

On vient d’énoncer tous les éléments qui vont nous aider à gagner en performance et qualité, voyons-les plus en détail :

  • Approche itérative : on ne se soucie pas de tout vouloir définir et résoudre au début du projet. On le décompose en modules qui peuvent être abordés séparément. L’exécution du projet n’est que le traitement itératif de ces parties.
  • Livraison rapide : en appliquant la démarche que l’on vient de décrire, des résultats apparaîtront rapidement. À nous de prioriser le traitement des modules qui peuvent donner les livrables les plus attendus par nos clients.
  • Réduction des étapes non productives et peu utiles : les études, réunions, analyses, élaborations de documentation qui ne sont pas strictement nécessaires sont à éviter. On verra par la suite où concentrer les efforts.
  • Utilisation du savoir-faire métier : la collaboration entre l’équipe projet et le client est cruciale, mais attention : il faut savoir choisir les bons interlocuteurs côté client. Les décideurs ne sont pas toujours ceux qui connaissent dans le détail l’environnement du projet. Il vaut mieux donner la place aux « profils métiers », c’est-à-dire aux personnes qui détiennent l’expertise du domaine traité. Dans cette démarche, il est important de se donner le temps de mettre en place des mesures efficaces afin de passer l’information correctement à l’équipe projet.
  • Adaptation au changement  : communiquer très souvent une information de qualité fait que les acteurs du projet sont en phase avec les besoins réels du client. La démarche itérative permet de traduire rapidement les nécessités en résultats adaptés.
  • Utilisation des meilleures méthodes de conception et des nouvelles techniques : les outils, méthodes de conception et techniques évoluent constamment. Utiliser leurs dernières mises à jour donne une réelle valeur ajoutée au projet.

Maintenant qu’on en sait un peu plus sur les principes de l’approche agile qui nous intéressent, regardons les résultats concrets qu’ils nous apportent.

Objectif numéro 1 : assurer la performance

Les trois premiers éléments décrits ci-dessus (approche itérative, livraison rapide, réduction des étapes non productives et peu utiles) peuvent améliorer très clairement la performance.

L’itération au sens agile, est en effet une courte période de temps de quelques semaines au maximum. Finies les longues étapes d’analyse des besoins, de conception, d’élaboration et validation des plannings propres aux méthodes des projets classiques.

Chaque cycle a des étapes de très courte durée où l’on essaye de réaliser le plus efficacement possible des tâches définies. Le gain en temps d’exécution est donc indiscutable.

De plus, chaque itération doit se terminer par une livraison selon les principes agiles : un résultat est ainsi au rendez-vous après quelques semaines dans le pire des cas.

On est bien loin des projets interminables, orientés processus et outils, qui ne produisent jamais rien !

Faire simple et ne réaliser que ce qui est strictement nécessaire est un autre principe à retenir. En effet, le temps non consacré à des tâches peu ou pas du tout productives, nous fait gagner en performance.

Un exemple très clair est la réduction au strict minimum des réunions projets avec tous les acteurs, qui sont généralement trop longues et peu concrètes. On privilégie alors la conversation en face à face de courte durée pour traiter des thèmes spécifiques.

Objectif numéro 2 : atteindre une qualité optimale

On revient sur la liste des éléments de l’approche agile que l'on a retenus pour leur utilité et on remarque qu’il y en a au moins trois qui peuvent nous apporter beaucoup d’un point de vue qualité.

Le savoir-faire métier, par exemple, permet d’adapter très précisément la solution aux spécificités du domaine du projet. Cela signifie que le résultat répondra probablement mieux aux attentes des demandeurs.

Par ailleurs, le temps qui passe peut changer la donne dans certains secteurs d’activité comme le financier ou les nouvelles technologies. Cette possibilité est monnaie courante !

Ainsi, la qualité dans le scénario décrit ci-dessus passe par une adaptation permanente dans le but d'éviter un non-alignement avec les besoins du moment. L’élément agile « adaptation au changement » est bien présent pour répondre à cette nécessité.

Enfin, être prêt à utiliser les dernières méthodes de conception et les nouvelles techniques a une répercussion directe sur les livrables. Ils bénéficient bien évidemment de ce principe agile en termes de qualité.

Conclusion

L’agilité peut être une très bonne alternative dans la gestion de projet, surtout s'il s'agit de gagner en qualité et en temps d’exécution. Bien sûr, il faut savoir appliquer les principes agiles qui peuvent donner les meilleurs résultats au bon moment.

Je vous ai donné un petit aperçu de comment s’y prendre. C'est désormais à vous de constater leur efficacité !

Un dernier conseil : si vous voulez que la « magie agile » opère, essayez de faire connaitre cette approche à tous les acteurs pour qu’ils puissent comprendre la grande opportunité que cette nouvelle vision du management de projet peut représenter et pour qu’ils vous aident à la saisir.

 

NOUVEAU

Téléchargez nos fiches pratiques en pdf

  • Explications simples pour une mise en oeuvre facile
  • Illustrées par des exemples
  • Fiches pdf agréables et efficaces

Retrouvez notre modèle simple pour rédiger un cahier des charges, voir l'exemple.

A lire en complément

Définitions

Manifeste pour le développement Agile de logiciels

L'original du Manifeste rédigé par des experts du développement informatique. Il s'agit des bases fondatrices des Méthodes Agiles

agilemanifesto.org

Un commentaire peut-être ?

Commentaires

  • Gravatar for Chris

    Chris 14 janv. 2022 à 15:52 (Il y a 3 année)

    Bonjour Norbert,
    Scrum ou Kanban permettent de faire progresser la construction de manière itérative et incrémentale en intégrant la possibilité d'adapter la vision produit.
    La DoD permet de manière collégiale de se mettre d'accord sur les critères d'acceptance de ce qui doit être réalisé.
    Fabriquer un produit en utilisant ces pratiques agiles n'occulte pas du tout la recette.
    L'équipe agile test et recette ce qu'elle livre en fin de sprint mais rien n'empêche de faire des recettes métiers ou d'intégration avec le reste du SI.
    Bien souvent dans les organisation de grande taille, ce n'est pas l'équipe agile qui met en production ni en service.

  • Gravatar for Norbert

    Norbert 20 nov. 2019 à 10:11 (Il y a 5 année)

    La présentation des principes Agiles / Scrum sont tous les mêmes. Ils partent d'un postulat simpliste. Une TPE/PME veut mettre en place un site web, une gestion des ventes ou un truc de relation client genre CRM.
    Dans tous les cas, c'est toujours :
    - une petite structure
    - une application unique

    Au delà, l'agilité se perd dans le n'importe quoi. Agile ne permet pas de faire avancer des Ecosystèmes d'applicatifs, notamment dans des grandes entreprises qui doivent gérer de multiples outils : base de connaissance, outil de vente, outil de rémunération des commerciaux, gestion de stocks, relation client etc ...
    Agile et Scrum occultent tout concept de recette au bénéfice du seul "definition of done". A fortiori les recette transverse multi-applications.

    Que dire quand l'Agilité est décrétée pour masquer l'incapacité du/des PO a avoir une vue globale de ce qu'ils veulent et avancer dans le brouillard, à la petite semaine .... A l'arrivée, des verrues applicatives dans tous les sens, des adhérences multiples et une architecture fonctionnelle et technique hérétiques ...

    Agile est-elle une méthode adaptée aux grosses structures aux écosystèmes applicatifs lourdement imbriqués ?