Un projet agile, c’est quoi ?

Ca y est le projet a dérapé. Il faut se rendre à l’évidence, la livraison ne pourra pas avoir lieu à la date prévue. Et là, un super directeur de projet débarque et vous annonce : « Mais si ! On va passer en mode agile ! ». En creusant un peu, vous comprenez que son mode agile consiste à ne plus faire de spécifications, à tester à l’arrache et à s’affranchir de tout un tas de procédures jugées trop lourdes. A ce moment là, je considère que vous avez deux options : lui lancer au visage l’objet contondant le plus proche ou ouvrir un blogue. C’est donc grâce à ma nature profondément non-violente que vous lisez ces lignes.

Pour commencer, autant repartir des bases : l’agilité dans la gestion de projet informatique a été définie dans le manifeste des méthodes agiles. La bible de l’agilité est donc là et nulle par ailleurs. Ce texte remarquablement clair et concis fait passer en 4 principes et 12 pratiques, l’essence des méthodes agiles telles qu’imaginées par leurs créateurs respectifs.

Néanmoins, ce texte, bien qu’extrêmement épuré, est sans doute trop abrupt pour beaucoup de lecteurs qui peuvent faire en de mauvaises interprétations. J’en propose donc les passages qui me semblent les plus fondamentaux :

  • « 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 méthodes agiles sont itératives : pour être agile, vous devez réaliser une planification stratégique avec des cycles variant de 6 semaines (pour les lots de début de projet) à 2 semaines (plutôt en fin de projet).
  • « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. » Un chef de projet n’est pas là pour faire l’interface entre utilisateurs pilotes et développeurs : ce serait tout le contraire de l’agilité. Le bon chef de projet saura les mettre en relation directe et les « coacher » pour qu’ils travaillent bien ensemble. Cette relation est également quotidienne : on n’attend pas une réunion hebdomadaire pour faire un point d’avancement ou poser des questions.
  • « La simplicité – c’est-à-dire l’art de minimiser la  quantité de travail inutile – est essentielle. » Les méthodes agiles ne font pas travailler plus vite : elles font diminuer les besoins de retouches et de re-conception grâce à une meilleure priorisation des tâches et une communication plus efficace. Si vous priorisez et communiquez « comme d’habitude », c’est que vous n’êtes pas agiles.
  • « Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité. » L’agilité n’implique pas la disparition des processus… l’agilité, c’est se donner le choix de la bonne méthode et du bon outil au bon moment. C’est à dire que l’on se donne des règles mais que si enfreindre ou modifier une règle à un moment donné est pertinent, on doit le faire en communiquant clairement sur le sujet (c’est à dire avec une trace écrite lue par tous les acteurs concernés).

Pour rendre tout cela concret, regardons comment Scrum (la méthode agile la plus en vogue aujourd’hui) met en oeuvre ces différents principes :

  • Scrum découpe les projets en sprints (itérations) d’une durée moyenne de 3 semaines.
  • Scrum préconise de faire travailler le « Product Owner » (celui qui définit, teste et priorise le fonctionnel) dans la même pièce que les développeurs. La notion de chef de projet disparaît au profit de celle de Scrum Master qui est là pour coacher l’équipe au niveau méthodologique, mais qui n’a aucune autorité particulière pour prendre des décisions fonctionnelles ou techniques dans le projet.
  • Scrum met en avant la transparence au quotidien, en particulier à l’aide de la mêlée quotidienne (réunion matinale de 15 minutes maximum) afin de mieux communiquer et prioriser. La priorisation est principalement effectuée au sein du Product Backlog qui définit les différents lots fonctionnels qui peuvent être réordonnancés à tout moment. A l’inverse, le sprint backlog (les spécifications du cycle en cours de développement) ne peut être modifié.
  • Scrum met en avant des conditions de travail (absence de perturbations extérieures, tableau blanc, équipe dans la même pièce…) permettant à l’équipe technique de développer de manière qualitative. Néanmoins, Scrum ne préconise de méthodologies techniques particulières. Cela aboutit souvent à une dérive appelée « Flaccid Scrum » : des projets Scrum manquant de la rigueur technique nécessaire à une véritable agilité du projet (regarder du côté de l’eXtrem Programming peut être utile à ce sujet).

Cet article n’aura certainement pas de vous un expert de l’agile, mais il vous permettra au moins de ne pas croire aux mythes de l’agile trop souvent répandus. Mon expérience personnelle, c’est qu’environ les 3 quarts des intervenants d’un projet informatique donné n’ont pas conscience des principes énoncés plus haut… parfois même dans des projets dits « agiles » !

Pour aller plus loin, lisez pour commencer le manifeste agile in extenso, et jetez ensuite un oeil à la page wikipedia traitant de Scrum.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s