+ 33 6 68 40 27 75 contact@odeven.fr
Sélectionner une page

Depuis plus d’une décennie, la gestion de projet agile est une thématique courante dans le monde de l’entreprise, particulièrement en informatique. Pourtant, j’observe de réelles difficultés pour les organisations à mettre en œuvre une transformation agile réussie.

Le jargon, les certifications onéreuses, les injonctions à l’agilité… Ce qui est une véritable culture, un paradigme de travail radicalement différent de celui qu’il tend à remplacer semble souvent dénaturé. La dilution des valeurs fondatrices dans l’application rigide de framework comme SCRUM ou XP rend la mise en œuvre des approches agiles peu efficace, parfois même néfaste pour une organisation. Dave Thomas parlait déjà de la dénaturation du mouvement agile en 2015, lors d’une mémorable conférence sur la mort de l’agilité.

Rassurez vous, les approches agiles vont bien ! Dans un monde de plus en plus complexe et chaotique, je crois même qu’elles ont un avenir rayonnant. Lors de sa conférence, Thomas explique que la transformation de l’adjectif agile en nom « agilité » prouve la récupération du mouvement par un marché qui a construit un business basé sur la peur. La peur de ne pas suivre la tendance, de ne pas être à la page, d’être dépassé.

Ok, très bien. Mais finalement, c’est quoi l’agilité ? Ou plutôt, étant donné qu’il s’agit d’un adjectif, c’est quoi travailler avec une approche agile ? Un bon dessin valant mieux qu’un long discours, je vais tenter de vous exposer ce qui me semble être l’ADN des approches agiles avec une représentation graphique simple. À vos crayons !

Dessine moi la gestion de projet

Prenons deux triangles modélisant un projet. Le gris représente le projet géré avec une approche séquentielle, le bleu avec une approche agile. Chaque sommet représente un axe du projet ; son coût, délais et périmètre (alternative au sempiternel triangle Qualité, Coût, Délais). Le périmètre représente l’étendu des fonctionnalités proposées par l’objet du projet, il s’agit donc du périmètre fonctionnel de la future application si on parle d’un projet de développement informatique. Le coût et le délais ne devraient pas nécessiter plus d’explications !

En gestion de projet traditionnelle, c’est à dire en approche séquentielle (Cycle en V, Waterfall), l’équipe s’attache à définir les besoins, écrire un cahier des charges puis des spécifications avant de réaliser, tester et enfin livrer l’application. Le périmètre est donc fixé par le cahier des charges, le coût et les délais, eux, peuvent varier (et en général, varient !), quand bien même vous avez travaillé sur un diagramme de Gantt très précis et un chiffrage méticuleux. Finalement, le pilotage du projet se fait via un PLAN défini par l’équipe dans le cahier des charges et les spécifications. Le Gantt, ou le planning du projet, peu importe son formalisme, précise ce qui sera fait et quand. La boussole de l’équipe est donc le cahier des charges, cet épais document se voulant exhaustif. C’est lui qui défini ce que vous allez faire durant les X prochains mois et qui permet de planifier l’ensemble des tâches de l’équipe dès le départ.

En approche agile, l’équipe travaille de manière différente. Le coût et les délais peuvent être simplement fixés en définissant un nombre d’itérations (les fameux sprints si vous travaillez avec SCRUM) et la taille de l’équipe en charge du projet. En revanche, l’équipe accepte de faire évoluer le périmètre d’itérations en itérations, selon les besoins réels des utilisateurs. C’est le feedback régulier des parties prenantes (clients, futurs utilisateurs, experts, …) qui va guider l’équipe dans la réalisation de ce qu’elle va construire, d’où l’importance d’organiser régulièrement des démonstrations et tests (review). En approche agile, ce qui guide l’équipe dans le développement d’une application est donc la VALEUR délivrée aux utilisateurs.

C’est la quintessence des approches agiles ; considérer que l’équipe délivrera plus de valeur en itérant rapidement et en recueillant régulièrement le feedback des utilisateurs et parties prenantes. Dès lors, les traditionnelles semaines passées à spécifier et planifier en détail deviennent inutiles, l’équipe ne cherche pas à atteindre un objectif fixé par un plan rédigé il y a parfois plusieurs mois, elle s’attache à livrer régulièrement de la valeur et à échanger avec ses clients et/ou utilisateurs afin de prioriser les développements futurs.

Pourquoi ça fonctionne ?

Inspirées de l’univers de la construction, les approches séquentielles reposent sur des hypothèses cachées :

  • Nous connaissons l’ensemble des besoins des utilisateurs en amont
  • Nous sommes capable de déterminer la meilleure solution technique avant d’avoir commencé à la développer

Ces hypothèses nous poussent à adopter des pratiques de l’ingénierie traditionnelle où formalisme et planification permettent de limiter les risques et de rendre le déroulement du projet relativement prédictible. Le problème est que ces hypothèses ne tiennent pas dans la dure réalité du développement logiciel (et produit en général). Même dans un environnement peu risqué, des aléas vont souvent à l’encontre de l’exécution précise d’un plan. En informatique, ce manque de prédictibilité est renforcé par l’émergence continue de nouvelles technologies.

Finalement, avec un peu d’expérience en la matière, nous pouvons reconnaître des faits antagonistes aux hypothèses énumérées précédemment :

  • Entre l’expression du besoin et la livraison il peut se passer plusieurs mois durant lesquels le besoin va évoluer
  • Les utilisateurs ne savent véritablement ce qu’ils veulent après avoir testé une première version de l’application

Le développement d’un produit ou la conduite d’un projet en approche agile s’aligne avec ces constats. Dès lors, l’expérimentation en cycle court prévaut sur la planification. L’équipe à besoin de savoir ce qu’elle va faire me direz vous ! Oui, la boussole de l’équipe sera une vision forte et partagée des objectifs. La construction d’une roadmap agile vous permettra également de jalonner votre projet avec des résultats attendus et des objectifs plutôt qu’avec des tâches précises mais rapidement obsolètes .

Et vous, plutôt triangle gris ou triangle bleu ?