Diagramme de Gantt de projet logiciel : de la découverte à la production
Un diagramme de Gantt de développement logiciel modifiable : découverte, conception, développement, QA, déploiement, mise en production et bilan, avec dépendances et jalons. Changez une durée, les dates suivent.
Qu'est-ce que le processus diagramme de gantt de projet logiciel : de la découverte à la production ?
Les plannings logiciels dérapent dans un ordre bien particulier. Les exigences sont rédigées, la conception démarre sur le premier brouillon, le développement commence avant que la conception soit relue, et les tests sont comprimés dans le temps qu'il reste à la fin. Un diagramme de Gantt n'empêche pas cela, mais il rend la compression visible très tôt, car les dépendances sont sous les yeux : les tests ne peuvent pas se terminer avant l'intégration, et la mise en production ne peut pas avoir lieu avant la décision go / no-go.
Ce modèle compte cinq étapes : Découverte, Conception, Développement, Assurance qualité et Mise en production, avec 17 tâches. Le développement backend et frontend se déroule en parallèle et se rejoint à « Intégration », et « Plan de test et jeux de données » est préparé pendant le développement pour que « Tests système » puisse démarrer le jour où l'intégration se termine. Il n'est volontairement lié à aucune méthode. Si vous travaillez par sprints, considérez les tâches de développement comme un bloc de sprints et gardez le reste comme l'enveloppe de la version ; le diagramme sert au plan autour des itérations, pas à chaque itération.
Les durées sont en jours ouvrés et ne sont que des valeurs indicatives. Une vraie estimation vient de l'équipe, et la bonne habitude est de changer les chiffres et de regarder ce qui bouge. Si le frontend prend 25 jours au lieu de 18, « Intégration » se décale, et tout ce qui suit aussi. Le plan n'a aucune date fixe, donc il commence le jour de sa création.
La mise en production est un processus à part : le processus de publication du logiciel, sur /fr/templates/organigramme-du-processus-de-publication-du-logiciel, et le processus de déploiement, sur /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production, détaillent les étapes à l'intérieur des tâches « Déploiement en production » et « Mise en production ».
Ce que couvre cet organigramme
Dans ce modèle
- Cinq étapes, Découverte, Conception, Développement, Assurance qualité et Mise en production, avec 17 tâches et trois jalons de décision : « Périmètre validé », « Revue de conception » et « Décision go / no-go ».
- Un développement en parallèle : « Développement backend » et « Développement frontend » démarrent tous deux après « Revue de conception » et se rejoignent à « Intégration ».
- Une préparation des tests hors du chemin critique : « Plan de test et jeux de données » se déroule pendant le développement, donc « Tests système » ne l'attend pas.
- Une mise en production par étapes : « Recette utilisateur » mène à « Décision go / no-go », puis à « Déploiement en production » et au jalon « Mise en production ».
- Le support et l'apprentissage après le lancement : « Support renforcé » suivi de « Bilan post-livraison », pour que le projet se termine par une décision sur ce qu'il faudra changer la prochaine fois.
Quand utiliser ce modèle
- Vous devez dire à une partie prenante quand une version peut sortir et de quoi cette date dépend.
- Une fonctionnalité est en retard et vous devez voir quelles tâches suivantes se décalent et lesquelles non.
- Les tests sont sans cesse comprimés en fin de projet et vous voulez montrer clairement l'effet d'un développement tardif.
- Vous démarrez un projet et voulez une structure standard à adapter, de la découverte à la mise en production.
Le plan, tâche par tâche
Toutes les tâches du diagramme avec leur durée en jours ouvrés et ce qu'elles attendent. Une dépendance est un numéro d'étape ; SS signifie début à début, FF fin à fin et +n un décalage en jours ouvrés.
| # | Tâche | Groupe | Jours ouvrés | Dépend de |
|---|---|---|---|---|
| 1 | Entretiens avec les parties prenantes | Découverte | 4 | |
| 2 | Rédiger les exigences | Découverte | 5 | 1 |
| 3 | Périmètre validé | Découverte | Jalon | 2 |
| 4 | Architecture technique | Conception | 4 | 3 |
| 5 | Conception UX et prototype | Conception | 8 | 3 |
| 6 | Revue de conception | Conception | Jalon | 4, 5 |
| 7 | Développement backend | Développement | 20 | 6 |
| 8 | Développement frontend | Développement | 18 | 6 |
| 9 | Intégration | Développement | 5 | 7, 8 |
| 10 | Plan de test et jeux de données | Assurance qualité | 4 | 6 |
| 11 | Tests système | Assurance qualité | 8 | 9, 10 |
| 12 | Recette utilisateur | Assurance qualité | 5 | 11 |
| 13 | Décision go / no-go | Mise en production | Jalon | 12 |
| 14 | Déploiement en production | Mise en production | 2 | 13 |
| 15 | Mise en production | Mise en production | Jalon | 14 |
| 16 | Support renforcé | Mise en production | 10 | 15 |
| 17 | Bilan post-livraison | Mise en production | 2 | 16 |
Comment cela fonctionne
Remplacez les tâches par les vôtres
Renommez les 17 tâches et les cinq étapes. Ajoutez des tâches à l'intérieur d'une étape plutôt que de nouvelles étapes, sauf si votre processus en compte vraiment une de plus.
Estimez le développement en flux parallèles
Donnez à chaque flux de développement sa propre tâche, comme le fait le modèle pour le backend et le frontend, afin que le planning montre le plus long des deux comme celui qui fixe la date.
Faites des jalons de décision de vrais jalons
Traitez « Revue de conception » et « Décision go / no-go » comme des points de passage avec un responsable et des critères. Un jalon sans personne pouvant dire non n'est qu'une date.
Lancez les tests dès que leurs entrées existent
Reliez la préparation des tests à la conception, pas à la fin du développement. Reliez les tests système à l'intégration. Utilisez des liens début à début quand les tests chevauchent la fin d'une tâche.
Ajoutez le temps après la mise en production
Gardez « Support renforcé » et « Bilan post-livraison » dans le plan. Les équipes qui arrêtent le planning à la mise en production voient le projet suivant démarrer avec le même support non planifié.
Activez le chemin critique
Utilisez le menu Affichage pour voir quelles tâches fixent la date de mise en production. Raccourcir une tâche hors du chemin ne déplace pas la date.
Questions fréquentes
Comment créer un diagramme de Gantt pour un projet logiciel ?
Listez les étapes que traverse votre version, découpez chacune en tâches, donnez à chaque tâche une durée en jours ouvrés et indiquez ce qu'elle attend. Ce modèle le fait pour un projet générique, de la découverte à un bilan après la mise en production. Modifiez les tâches et les durées, et les dates en sont calculées.
Puis-je l'utiliser avec Agile ou Scrum ?
Oui, pour le plan autour des sprints. Représentez le développement par une seule tâche ou une courte série de tâches de la taille d'un sprint, et gardez dans le diagramme les jalons de mise en production, les tests et le support renforcé. Un diagramme de Gantt n'est pas un tableau de sprint : il ne suit ni les user stories ni la vélocité.
Quels doivent être les jalons ?
Les jalons marquent des décisions, pas du travail : périmètre validé, revue de conception et décision go / no-go dans ce modèle. Ajoutez-en un partout où quelqu'un doit approuver avant que l'étape suivante puisse commencer.
Puis-je importer des tâches depuis un tableur ?
Vous pouvez coller un tableau de tâches, de durées et de dépendances dans la feuille à côté du diagramme. Il n'existe pas encore d'import de fichier pour les diagrammes de Gantt ; copiez donc les lignes de votre tableur et collez-les dans la feuille à côté du diagramme.
