Diagramme de Gantt pour le développement logiciel

Le Gantt a sa place dans le logiciel, à la bonne altitude

L'objection est bien connue. Placez un diagramme de Gantt devant une équipe scrum et quelqu'un le qualifiera de cascade déguisée. Ils ont raison sur un point et tort sur le reste. Ils ont raison de dire que planifier des récits individuels sur un Gantt est une erreur, car ces récits changent chaque jour et le diagramme serait périmé avant midi. Ils ont tort de penser qu'un diagramme de Gantt n'a aucune place dans le logiciel.

L'astuce, c'est l'altitude. Un backlog opère au niveau du récit, où le travail est petit, réordonné sans cesse et piloté par le flux plutôt que par les dates. Un Gantt opère un cran au-dessus, au niveau de la livraison, où vous vous engagez sur une date de sortie, coordonnez plusieurs équipes et rendez des comptes à des parties prenantes qui ne lisent pas Jira. Gardez le Gantt à cette hauteur et la tension entre lui et l'agile disparaît tout simplement. Faites-le descendre au niveau du récit et vous aurez mérité chaque reproche que l'équipe vous adressera.

Les cinq phases d'un calendrier logiciel

La plupart des fonctionnalités traversent cinq phases reconnaissables, et un Gantt est conçu pour montrer exactement ce genre de séquence. La découverte clarifie le problème et le périmètre. La conception fixe l'interface, le modèle de données et le contrat d'API. La construction, c'est le gros de l'ingénierie. Les tests couvrent l'intégration, l'assurance qualité et le durcissement. La sortie couvre le déploiement, la migration et la mise en production elle-même. Chaque phase s'appuie sur la précédente, et c'est précisément la relation qu'un diagramme en barres rend visible.

Les phases ne sont pas des sprints. Une seule phase comme la construction peut s'étaler sur trois ou quatre sprints, tandis que la découverte peut tenir dans un seul. C'est très bien ainsi. Le Gantt porte une barre par phase, pas une par sprint et surtout pas une par ticket. Cette vue grossière est ce qui permet à un responsable de jeter un oeil au diagramme et de voir, en une seconde, si l'équipe est encore en construction ou déjà en durcissement avant la sortie. Le backlog ne peut jamais vous donner cette forme, car il masque délibérément les dates.

Là où un Gantt surpasse un backlog

Un backlog est une liste plate triée par priorité. Il est excellent pour ordonner les prochains jours de travail, et aveugle à trois choses dont dépend une livraison. D'abord, la vue de livraison. Une partie prenante qui demande quand le paiement sort veut une image de tout le parcours, de la découverte à la mise en production, pas un défilement de 200 tickets. Un Gantt lui donne cette image en un seul cadre.

Ensuite, les échéances. Une clause contractuelle, une démo en conférence ou une date de conformité est un point fixe dans le temps. Un backlog n'a aucune notion de date calendaire, il ne peut donc pas vous dire si la date promise reste réaliste. Un Gantt ancre ces dates sous forme de jalons et montre la marge, ou son absence, avant elles. Enfin, les dépendances. Quand une équipe en bloque une autre, cette relation n'apparaît sur le tableau d'aucune des deux, pourtant c'est la raison la plus fréquente de glissement des dates logicielles. Un Gantt est le seul artefact qui la rend évidente.

Là où un backlog surpasse un Gantt

L'honnêteté va dans les deux sens, et il existe un vrai travail qu'un Gantt ne devrait jamais toucher. Le quotidien mouvant appartient à un tableau. Quel ticket tirer ensuite, qu'est-ce qui est bloqué ce matin, combien de points restent dans le sprint, qui reprend le test instable qui vient d'échouer : rien de tout cela n'appartient à un Gantt, et l'y forcer, c'est ainsi que les diagrammes de Gantt gagnent leur mauvaise réputation en ingénierie.

Le travail de tableau change d'heure en heure. Les estimations bougent, les récits se scindent, les bugs doublent la file et les priorités se réorganisent après chaque mêlée. Un Gantt redessiné aussi souvent est pire qu'inutile, car il a l'air faisant autorité alors qu'il est faux. Le tableau est fait pour absorber cette volatilité. Il traite le changement comme un flux normal plutôt que comme un écart par rapport à un plan. Laissez donc le détail bruyant et rapide sur le tableau et laissez-le bouillonner. Le Gantt ne se soucie que du résultat produit par chaque sprint, pas du chemin minute par minute que l'équipe a emprunté pour y parvenir.

Gantt et backlog, côte à côte

Les deux outils ne se recoupent presque pas, et c'est précisément pourquoi vous utilisez les deux. Alignez les questions auxquelles chacun répond et la répartition des rôles devient évidente.

Remarquez le peu que partagent les colonnes. Vous ne choisissez pas un outil au détriment de l'autre. Vous couvrez deux ensembles de questions différents avec deux instruments différents.

Les dépendances inter-équipes sont la vraie raison

Si un Gantt logiciel mérite sa place pour une seule chose, ce sont les dépendances inter-équipes. Le travail logiciel est plein de passations qu'aucun tableau isolé ne peut montrer. L'API doit exposer un endpoint avant que l'interface puisse l'appeler. L'infrastructure doit provisionner le cluster avant que quiconque puisse y déployer. L'équipe data doit livrer la migration avant que la fonctionnalité lise le nouveau schéma. Chacune est une dépendance fin à début qui franchit une frontière d'équipe, et chacune est invisible sur les tableaux des équipes concernées.

Sur un Gantt, ces passations sont de simples flèches, et elles changent votre façon de piloter la livraison. Dès que vous voyez que la barre de l'interface ne peut démarrer qu'une fois la barre de l'API terminée, vous savez quel travail protéger et lequel peut fléchir. Vous cessez de traiter le glissement de chaque équipe comme également urgent et commencez à défendre les passations précises qui conditionnent réellement la date. C'est une décision qu'un backlog ne peut jamais éclairer, car le backlog ignore l'existence de l'autre équipe.

Exemple concret : une fonctionnalité de paiement en dix semaines

Une équipe s'engage à livrer un paiement en libre-service en dix semaines. La découverte et la conception passent d'abord, puis trois équipes construisent en parallèle, et enfin tout converge vers les tests et la sortie. Le tableau gère les tickets. Le Gantt gère la livraison. Voici comment les phases et les responsables se projettent sur la frise.

La chaîne qui fixe votre date

Dans l'exemple ci-dessus, la séquence conception vers API de paiement vers interface de paiement vers tests vers sortie est la plus longue chaîne de travail dépendant. L'infrastructure court en parallèle et finit tôt, elle a donc de la marge pour bouger. Cette plus longue chaîne est votre chemin critique, et c'est la seule chose qui fixe réellement la date de sortie. Le travail de plateforme pourrait glisser de quelques jours et la livraison sortirait quand même. L'API de paiement, non.

C'est là qu'un Gantt se rentabilise dans un atelier d'ingénierie. Un graphique de vélocité vous dit à quelle vitesse une équipe avance. Il ne peut pas vous dire lequel des trois flux de travail parallèles retient toute la livraison 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, plutôt que de répartir l'inquiétude uniformément sur chaque équipe. Estimez les barres de cette chaîne avec un débit historique réel, pas avec de l'optimisme, et lisez notre guide sur l'estimation des durées avant de vous engager sur la moindre date qu'un client entendra.

Associer le Gantt de livraison à l'exécution par sprints

Le schéma qui marche est simple. Le Gantt possède la livraison. Les sprints possèdent le détail. Vous dessinez le Gantt au niveau des phases et des épopées, puis vous laissez chaque équipe planifier ses propres récits sur le tableau exactement comme aujourd'hui. Rien ne change dans la cérémonie du sprint. Ce qui change, c'est qu'à chaque revue de sprint vous mettez à jour la barre de phase correspondante : a-t-elle fini, glissé ou rétréci ?

Planifiez les phases proches en détail parce que vous les comprenez, et tenez les phases lointaines comme des blocs grossiers parce que, honnêtement, vous ne les comprenez pas encore. Affinez chaque bloc à mesure qu'il approche du sprint courant. Cette approche par vagues successives garde le Gantt fidèle sans prétendre connaître la semaine 10 pendant la semaine 2. Le Gantt n'est pas un second endroit pour gérer les tâches. C'est une loupe qui transforme un trimestre de résultats de sprint en une seule réponse sur la date de sortie. Le tableau répond à quoi construire ensuite. Le Gantt répond à la question de savoir si la somme de toute cette construction arrive à temps.

Construire le calendrier étape par étape

Vous n'avez besoin ni d'un outil lourd ni d'une certification en gestion de projet pour en construire un. Il vous faut les phases, les dates déjà promises et une heure avec les responsables d'équipe. Voici la séquence.

1. Listez les phases et les grandes épopées de cette livraison, pas les récits. Visez six à douze barres.
2. Marquez d'abord les dates fixes : la mise en production, toute démo et toute échéance de conformité ou de contrat. Dessinez-les en losanges de jalon qui ne bougent pas.
3. Dimensionnez chaque phase avec votre débit réel, puis placez-la sur la frise.
4. Dessinez les dépendances entre phases, surtout chaque passation qui franchit une équipe. C'est l'étape à plus forte valeur.
5. Trouvez la plus longue chaîne de phases dépendantes. C'est le chemin critique que vous défendez.
6. Confiez à une seule personne la mise à jour du diagramme à chaque revue de sprint, et nulle part ailleurs.

Ouvrez un plan vierge dans l'éditeur de Gantt, ajoutez une ligne par phase, reliez les dépendances et vous obtenez une vue de livraison en moins d'une heure. Gardez le détail des tickets sur le tableau, là où il a sa place.

Gardez-le grossier, sinon il pourrit

La principale raison pour laquelle un Gantt échoue dans une équipe logicielle, c'est le poids. Quelqu'un construit un superbe diagramme avec une barre par ticket, il est périmé en un sprint, et l'équipe conclut que les diagrammes de Gantt ne marchent pas. Le diagramme n'a pas échoué. La granularité, si. Un Gantt de livraison doit ê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.

Un diagramme de Gantt construit une fois et jamais retouché n'est pas un plan, c'est un voeu. Mettez-le à jour ou supprimez-le, mais ne le laissez jamais pourrir sur un disque partagé en prétendant être la vérité.

Quand se passer complètement du Gantt

Tout effort logiciel n'a pas besoin d'un Gantt, et en ajouter un là où il n'apporte rien, c'est de la pure surcharge. Si votre travail est un flux continu de petits éléments indépendants, sans échéance externe ni passation inter-équipes, un tableau suffit amplement. Une escouade de maintenance, une file de support ou une équipe unique qui déploie en production plusieurs fois par jour gagne peu à une couche de livraison, car il n'y a aucune livraison à façonner.

Tournez-vous vers un Gantt quand trois signaux apparaissent ensemble : une date externe fixe que vous avez promise, plus d'une équipe dont le travail dépend d'une autre, et une partie prenante qui a besoin de tout le parcours en une seule vue. Quand les trois sont présents, le backlog laisse de vraies questions sans réponse et le Gantt y répond proprement. Quand aucun ne l'est, passez-vous-en la conscience tranquille. Et si vous en voulez un, vous n'avez pas non plus à payer pour cela, car notre comparatif des meilleurs logiciels gratuits de diagramme de Gantt couvre des outils qui gèrent exactement cela.

Questions fréquentes

À lire aussi

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

Cet article est également disponible en anglais.