Gantt de développement logiciel : planifier une version, de A à Z
Planifiez un projet logiciel en diagramme de Gantt : découverte, conception, développement, tests, déploiement, mise en production et bilan, avec flux parallèles et points de décision, et sa place à côté des sprints Agile.
Le diagramme de Gantt d'un projet logiciel montre comment les flux de travail dépendent les uns des autres et quand une version peut sortir. Il répond à une question que le tableau de sprint ne traite pas : compte tenu des dépendances, quelle est la première date possible pour la mise en production ?
En bref
- Planifiez au niveau de la version : flux, points de passage et dépendances, pas tickets individuels.
- Les flux parallèles se montrent par des tâches qui attendent le même prédécesseur ; le plus long fixe la date.
- Les points de décision comme périmètre validé et go / no-go ont leur place dans le graphique sous forme de jalons.
- Un flux de développement peut être dimensionné en sprints convertis en jours ouvrés.
- La capacité et l'effort ne sont pas modélisés ; utilisez votre outil de suivi pour cela.
Où un diagramme de Gantt aide une équipe logicielle, et où il n'aide pas
La plupart des équipes logicielles travaillent déjà en sprints, et un tableau de sprint est le bon endroit pour gérer le travail à l'intérieur. Un diagramme de Gantt se place au-dessus. Il couvre toute la version : ce qui doit finir avant que la conception puisse démarrer, quels flux peuvent avancer en parallèle, où les tests doivent attendre l'intégration, et quelles décisions conditionnent le déploiement. C'est une vue de la forme du projet, pas un remplaçant du backlog.
Ce qu'un Gantt montre et qu'un tableau ne montre pas, c'est le temps et la dépendance ensemble. Un tableau dit ce qui est en cours. Un Gantt dit que le frontend et le backend doivent tous deux finir avant l'intégration, que les tests ne peuvent pas démarrer avant, et que le plus long de deux développements parallèles fixe la date. Cela le rend utile pour planifier une version, pour parler à des personnes extérieures à l'équipe et pour repérer le seul flux qui retient tout.
Gardez des tâches grossières. Planifiez au niveau de la découverte, de la conception, des flux de développement, de l'intégration, des tests, de la mise en production et du bilan, en jours ouvrés, et laissez les récits et les tickets à votre outil de suivi. Si vous travaillez en sprints, un flux de développement peut simplement être une tâche dont la durée est un nombre de sprints exprimé en jours ouvrés. N'essayez pas de modéliser le contenu de chaque sprint ici ; le graphique est périmé dès que le backlog bouge.
Ajoutez les points de décision comme jalons de durée zéro : périmètre validé, revue de conception, go ou no-go. C'est là que le planning se décide vraiment, et les mettre dans le graphique rend difficile d'éluder la question de qui décide, et quand. QueryChart ne suit ni l'effort ni la capacité, donc la taille de l'équipe n'est pas modélisée. L'exemple ci-dessous est un plan de version complet, étape par étape.
Une version logicielle, des entretiens au bilan post-livraison
Dix-sept tâches. Ouvrez le panneau tableur pour voir les dépendances derrière chaque étape.
La découverte s'achève sur une décision de périmètre
« Entretiens avec les parties prenantes » (4 jours ouvrés) mène à « Rédiger les exigences » (5). « Périmètre validé » est un jalon de durée 0, et les deux flux de conception l'attendent.
Deux flux de conception, une revue
« Architecture technique » (4 jours ouvrés) et « Conception UX et prototype » (8) démarrent tous deux après « Périmètre validé ». « Revue de conception » attend les deux : le travail UX, flux le plus long, décide donc de sa date.
Flux de développement et préparation des tests
« Développement backend » (20 jours ouvrés) et « Développement frontend » (18) démarrent après « Revue de conception » et se rejoignent à « Intégration » (5). « Plan de test et jeux de données » (4) démarre aussi après la revue, et il est donc prêt bien avant que les tests en aient besoin.
Tester, décider, livrer, faire le bilan
« Tests système » attend « Intégration » et la préparation des tests. « Décision go / no-go » est un jalon avant « Déploiement en production » (2 jours ouvrés), puis viennent « Mise en production », « Support renforcé » (10) et « Bilan post-livraison » (2).
Comment cela fonctionne
Décider du niveau de détail
Planifiez au niveau de la version. Chaque tâche doit être un flux ou une étape qui prend des jours ou des semaines, pas un ticket. Si une tâche dure moins de deux jours, intégrez-la à sa tâche parente.
Saisir la découverte et la conception, avec les jalons de décision
Ajoutez les tâches de découverte et de conception avec des durées en jours ouvrés, et des jalons de durée zéro pour le périmètre validé et la revue de conception. Faites dépendre l'étape suivante du jalon, pas de la dernière tâche.
Mettre les flux parallèles sur le même prédécesseur
Backend, frontend et préparation des tests doivent tous dépendre de la revue de conception. Ne les enchaînez pas l'un après l'autre : le but du graphique est de montrer ce qui peut se chevaucher.
Convertir les sprints en jours ouvrés
Si un flux prend quatre sprints de deux semaines, saisissez 40 jours ouvrés. N'ajoutez un décalage que pour une vraie attente, comme un gel de version.
Ajouter les points de passage de la version
Ajoutez go / no-go comme jalon avant le déploiement, et donnez au support renforcé et au bilan post-livraison leurs propres tâches pour que le plan couvre les semaines après le lancement.
Activer le chemin critique et partager
Activez Affichage, Chemin critique pour voir l'enchaînement qui fixe la date de mise en production, puis partagez le graphique par lien ou exportez un PDF pour les parties prenantes.
Erreurs à éviter
Planifier au niveau des tickets
Un Gantt de centaines de petites tâches est périmé en un sprint. Gardez le niveau des flux et laissez l'outil de suivi porter le détail.
Enchaîner des flux parallèles
Mettre le frontend après le backend parce qu'une seule personne fait les deux masque la vraie structure des dépendances. Reliez les tâches selon ce dont elles ont réellement besoin, et notez les personnes partagées dans le champ Personnes.
Oublier que la capacité n'est pas modélisée
Deux tâches confiées à la même personne peuvent se chevaucher sans avertissement. QueryChart enregistre les responsables mais ne vérifie pas la charge.
Omettre les semaines après la mise en production
Le support renforcé et un bilan sont du vrai travail. Sans eux, le plan s'arrête le jour de la mise en production, ce qui est rarement le moment où l'équipe est libre.
Ouvrir le modèle de projet logiciel
Ouvrez le plan de projet logiciel comme votre propre graphique, remplacez les flux par les vôtres et partagez le calendrier de la version.
Guides associés
Questions fréquentes
Un diagramme de Gantt convient-il à une équipe Agile ?
Oui, au niveau de la version. Utilisez-le pour la forme du projet, ses dépendances et ses points de passage, et gardez le contenu des sprints dans votre outil de backlog. Les deux répondent à des questions différentes.
Que montre un diagramme de Gantt qu'un tableau ne montre pas ?
Le temps et la dépendance ensemble : quels flux avancent en parallèle, lesquels doivent finir avant que le suivant démarre, et quel enchaînement fixe la date de mise en production.
Comment planifier un sprint dans le graphique ?
En général, on ne le fait pas. Exprimez un flux de développement comme une tâche dont la durée est son nombre de sprints en jours ouvrés, et laissez le contenu des sprints au tableau.
Puis-je le relier à mon outil de suivi de tickets ?
Non. QueryChart n'a pas d'intégration avec les outils de suivi de tickets. Vous pouvez coller dans le tableur des lignes issues d'un export de tableur.
Puis-je montrer qui travaille sur quoi ?
Oui, chaque tâche a un champ Personnes. Il n'y a pas de contrôle de charge ni de surcharge.
