Agile et diagrammes de Gantt : comment utiliser les deux ensemble

Oui, ils coexistent. Voici la réponse honnête

Posez la même question à un puriste scrum et à un responsable de livraison et vous obtiendrez des réponses opposées. Le puriste dit qu'un diagramme de Gantt est du cycle en cascade déguisé. Le responsable dit qu'un backlog ne peut pas dire à un client quand la fonctionnalité sort. Les deux ont à moitié raison. Un diagramme de Gantt et agile ne sont pas rivaux, ils opèrent à des altitudes différentes. Agile gère le travail quotidien à l'intérieur de chaque sprint. Un Gantt décrit la forme de la version au-dessus des sprints : les phases, les dates fermes et les transmissions entre équipes qu'aucun backlog ne peut montrer à lui seul.

La vraie erreur est de forcer un seul outil à faire les deux métiers. Planifiez un sprint de deux semaines sur un Gantt et vous le redessinerez chaque matin à mesure que les récits bougent. Promettez une date de lancement à partir d'un seul backlog et vous devinez la vélocité. Mettez chaque outil là où il convient et la vieille tension disparaît sans bruit.

Deux outils, deux altitudes

Un tableau et un backlog sont conçus pour le flux. Ils répondent à ce qu'une équipe devrait prendre ensuite, à ce qui est bloqué aujourd'hui et à ce qu'il reste dans le sprint en cours. Ils sont délibérément aveugles aux dates du calendrier, car les dates ne sont pas la manière de piloter un sprint. Un Gantt est conçu pour le temps. Il répond à quand une phase commence, à quelles équipes doivent terminer avant qu'une autre puisse commencer, et à savoir si la version atterrit toujours à la date promise.

Question	Tableau et backlog	Gantt de version
Que construisons-nous ensuite ?	Oui, le haut du backlog	Non
Sommes-nous bloqués aujourd'hui ?	Oui	En partie
Tiendrons-nous la date de lancement ?	Non	Oui
Quelle équipe conditionne la nôtre ?	Rarement visible	Oui, comme une dépendance
Quelle est la phase après celle-ci ?	Non	Oui

Remarquez que les colonnes ne se recoupent presque pas. C'est tout l'intérêt. Vous ne choisissez pas entre les deux, vous couvrez deux ensembles de questions différents.

Les trois couches d'un plan agile

Une livraison agile saine repose sur trois couches, et une seule d'entre elles est le sprint. Les garder séparées, c'est ce qui permet à un Gantt et à un tableau de cohabiter sans se marcher dessus.

• Couche feuille de route. Trimestres et thèmes. Ce qui compte ce semestre et, grosso modo, dans quel ordre. C'est une vue stratégique, pas un calendrier.
• Couche version. C'est ici que vit le Gantt. Une seule version est un ensemble de phases réparties sur plusieurs sprints, avec de vraies dates, des jalons et des dépendances entre équipes. C'est ici que vous vous engagez auprès des clients.
• Couche sprint. Le tableau et le backlog. Récits, points, flux quotidien. Les estimations changent ici en permanence et c'est très bien, car la couche au-dessus absorbe la variation.

Quand quelqu'un dit que les diagrammes de Gantt tuent l'agilité, il veut généralement dire que quelqu'un a essayé de gérer la couche sprint sur un Gantt. Remontez le Gantt à la couche version et l'objection s'évapore.

Ce qu'un Gantt apporte et qu'un backlog ne peut pas

Un backlog est une liste plate, triée par priorité. Il excelle à ordonner le travail et il est désastreux sur trois points dont dépend une version. Premièrement, les dépendances entre équipes. Quand l'équipe API doit livrer une passerelle avant que l'équipe app puisse construire le paiement, cette relation est invisible dans le backlog de l'une ou l'autre, mais évidente comme une dépendance sur un Gantt. Deuxièmement, les échéances fermes. Un salon professionnel, une clause contractuelle ou une date réglementaire est un point fixe qu'un backlog ne représente tout simplement pas. Troisièmement, la vue de version : une seule image qui montre à une partie prenante tout le parcours, de la conception au lancement.

Un backlog dit à une équipe quoi faire ensuite. Un Gantt dit à l'organisation si la somme de tout ce travail arrive à temps. Ce ne sont pas les mêmes questions, et un plan de version a besoin que les deux soient traitées.

Utiliser un Gantt pour la version, les sprints pour le détail

Le schéma qui fonctionne est la planification par vagues successives. Vous dessinez le Gantt de version au niveau des phases et des épopées, grosso modo une barre par épopée ou par sprint, pas une barre par récit. Le court terme est détaillé parce que vous le connaissez. Le long terme est un bloc grossier parce que, honnêtement, vous ne le connaissez pas encore, et prétendre le contraire, c'est ainsi que les diagrammes de Gantt gagnent leur mauvaise réputation.

À chaque sprint, l'équipe planifie ses récits sur le tableau comme d'habitude. Rien de cela ne change. Ce qui change, c'est qu'à la fin du sprint vous mettez à jour la barre correspondante sur le Gantt : l'épopée a-t-elle fini, glissé ou rétréci ? Le Gantt n'est pas un second endroit pour gérer les tâches. C'est une lentille qui transforme huit semaines de résultats de sprint en une seule réponse sur la date de version. Estimez les barres grossières avec la vélocité réelle de votre équipe, pas avec des calculs optimistes, et lisez notre guide sur l'estimation des durées avant d'engager les dates.

Exemple concret : version 2.0 sur quatre sprints

Une équipe paiements s'engage à livrer un paiement en libre-service en huit semaines, quatre sprints de deux semaines. Le tableau gère les récits. Le Gantt gère la version. Voici comment les épopées se répartissent sur les sprints et où se situe le risque.

Épopée	Équipe	Sprints	Dépend de
Intégration de la passerelle de paiement	API	1 à 2	Rien
Interface de paiement	App	3 à 4	Passerelle (fin à début)
Règles antifraude	Risque	2 à 3	Passerelle (début à début)
Lancement et validation de conformité	Toutes	4	Tout ce qui précède

La chaîne qui fixe votre date

Dans l'exemple ci-dessus, la séquence passerelle, puis paiement, puis lancement est le plus long chemin de travail dépendant. Tout le reste, comme les règles antifraude menées en parallèle, a de la marge pour bouger. Cette chaîne la plus longue est votre chemin critique, et c'est la seule chose qui fixe vraiment la date de lancement. Les règles antifraude pourraient glisser de quelques jours et la version sortirait quand même. La passerelle, non.

C'est là qu'un Gantt gagne sa place dans une boutique agile. Les graphiques de vélocité vous disent à quelle vitesse avance une seule équipe. Ils ne peuvent pas vous dire lequel de quatre flux de travail parallèles est celui qui tient toute la version en otage. Le chemin critique le peut, et il vous permet de placer votre attention là où un glissement vous coûte vraiment la date, au lieu de répartir l'inquiétude uniformément sur toutes les équipes.

Objections courantes, réponses honnêtes

La résistance est prévisible, et la plupart est justifiée quand un Gantt est mal utilisé. Voici les objections qu'une équipe scrum soulèvera et la réponse honnête à chacune.

Objection	Réponse honnête
Les diagrammes de Gantt, c'est du cycle en cascade	Seulement si vous y planifiez des récits. À la couche version, ce n'est qu'une vue des dépendances et des dates.
Les estimations changent à chaque sprint	Vrai, alors gardez les barres au niveau de l'épopée et mettez-les à jour après chaque sprint. Ne dessinez pas de récits.
Il va devenir obsolète	Il le deviendra, si personne ne s'en occupe. Désignez un responsable qui le met à jour à chaque revue de sprint, pas plus tôt.
Le tableau montre déjà les blocages	Au sein d'une équipe, oui. Les verrous entre équipes et les dates fixes, non.
Les parties prenantes devraient lire le backlog	Elles ne le feront pas. Un Gantt de version est l'artefact que dirigeants et clients comprennent réellement.

Aucune de ces objections ne survit au contact d'un Gantt tenu à la bonne altitude. Presque toutes sont en réalité des plaintes sur des Gantts tenus à la mauvaise.

Comment construire un Gantt de version en une après-midi

Vous n'avez pas besoin d'un outil lourd ni d'une certification. Vous avez besoin des épopées, des dates sur lesquelles vous vous êtes déjà engagé et d'une heure avec les chefs d'équipe. Voici la marche à suivre.

1. Listez les épopées de cette version, pas les récits. Visez entre cinq et douze barres.
2. Marquez d'abord les dates fixes : lancement, démos, échéances contractuelles. Ce sont des jalons, dessinés en losanges, et ils ne bougent pas.
3. Dimensionnez chaque épopée en sprints en utilisant votre vélocité réelle, puis placez-la sur la frise chronologique.
4. Dessinez les dépendances entre épopées, surtout celles qui traversent les équipes. C'est l'étape qui a le plus de valeur.
5. Trouvez la plus longue chaîne d'épopées dépendantes. C'est le chemin que vous défendez.
6. Désignez un responsable pour mettre à jour le graphique à chaque revue de sprint, et nulle part ailleurs.

Ouvrez un plan vierge dans l'éditeur de Gantt, ajoutez une ligne par épopée, reliez les dépendances et vous aurez une vue de version en moins d'une heure. Gardez le détail des récits sur votre tableau, là où il a sa place.

Gardez-le léger ou il meurt

La principale raison pour laquelle un Gantt échoue dans une équipe agile est le poids. Quelqu'un construit un magnifique graphique de cent lignes, il devient obsolète en un sprint, et l'équipe conclut que les diagrammes de Gantt ne marchent pas. Le graphique n'a pas échoué, la granularité, si. Un Gantt de version devrait être assez petit pour qu'une personne le mette à jour en dix minutes à la revue de sprint, en glissant quelques barres et en déplaçant une date.

Suivez la version comme vous suivez tout plan face à la réalité, en comparant où vous aviez dit que chaque épopée serait et où elle a réellement atterri. Une rapide vérification de référence à chaque revue vous dit si la date dérive bien avant que cela ne devienne une crise. Un diagramme de Gantt construit une fois et jamais touché n'est pas un plan, c'est un vœu. Mettez-le à jour ou supprimez-le, mais ne le laissez pas pourrir dans un lecteur partagé en prétendant être la vérité.

Quand sauter le Gantt complètement

L'honnêteté coupe dans les deux sens. Tout effort agile n'a pas besoin d'un Gantt, et en ajouter un là où il n'apporte rien n'est que du poids inutile. Si votre travail est un flux continu de petits éléments indépendants, sans échéance externe ni transmissions entre équipes, un tableau suffit. Une équipe de maintenance pure, une file de support ou une seule escouade qui livre en production chaque jour gagnent peu d'une couche version, car il n'y a pas de version à façonner.

Recourez à un Gantt quand trois signaux apparaissent ensemble : une date externe fixe que vous avez promise, plus d'une équipe dont le travail dépend de celui d'une autre, et une partie prenante qui a besoin de voir tout le parcours d'un coup. Quand les trois sont présents, le backlog laisse de vraies questions sans réponse et le Gantt y répond. Quand aucun ne l'est, sautez-le la conscience tranquille et laissez le tableau faire son travail.

Questions fréquentes

À lire aussi

• La méthode du chemin critique expliquée
• Les dépendances entre tâches expliquées
• Jalons et tâches
• Retour aux guides

Cet article est également disponible en anglais.