Planifier une mise en production logicielle sur un Gantt
Planifiez la période entre la dernière fonctionnalité et la production : gel du code en jalon, tests menés en parallèle, jonction avant validation et chemin critique pour voir ce qui fixe la date de mise en production.
Les dates de mise en production sont souvent annoncées avant que le plan de test existe. Ce guide montre comment transformer la période entre le gel et la production en planning que vous pouvez confronter à la date qu'on vous a donnée.
En bref
- Faites du gel du code un jalon de durée nulle que toutes les tâches de développement doivent atteindre.
- Lancez les flux de test, les notes de version et le runbook à partir du gel, pour qu'ils avancent côte à côte.
- Réunissez tous les flux dans une tâche avant la validation, puis conditionnez le déploiement à la validation et aux documents.
- Planifiez les jours après le déploiement comme des tâches : un test de fumée, une annonce et une fenêtre de surveillance.
- Activez le chemin critique pour voir quel flux fixe la date, et comparez la fin avec la date dont vous avez besoin.
Planifier la période après la dernière fonctionnalité
Un plan de mise en production est court mais dense. Dix-sept tâches peuvent tenir en un mois environ, et la plupart dépendent de deux ou trois autres. C'est pourquoi une simple liste échoue ici : elle dit ce qui doit se passer, mais pas que la recette utilisateur peut démarrer deux jours après le gel alors que les tests de non-régression ne peuvent pas finir avant lui, ni que le runbook doit être prêt le jour où le déploiement démarre, pas le jour où les tests se terminent.
La méthode se déroule en quatre temps. D'abord, faites du gel un jalon que tout ce qui précède doit atteindre. Ensuite, lancez les flux de test à partir du gel et laissez-y démarrer aussi la documentation. Troisièmement, réunissez les flux dans une tâche avant la validation, pour que la validation ne puisse pas apparaître trop tôt. Quatrièmement, donnez au déploiement ses verrous et planifiez les jours qui suivent comme de vraies tâches. Les dates sont ensuite calculées à partir des durées et des liens, et vous comparez la fin avec la date dont vous avez besoin au lieu d'écrire d'abord la date.
Un planning ne rend pas une mise en production sûre. Il montre quand le travail devrait finir si chaque estimation tient, et ne détectera ni un test manquant ni un retour arrière non testé. Gardez les résultats de test, les approbations et la liste des défauts dans les systèmes qui les détiennent. Le diagramme planifie l'ordre et le temps, et ne se connecte ni à un dépôt de code, ni à un outil de tickets, ni à un outil de déploiement.
L'exemple est le modèle de mise en production logicielle sur /fr/templates/diagramme-de-gantt-mise-en-production-logiciel. Si vous avez besoin du processus et de ses décisions plutôt que du planning, voyez les organigrammes sur /fr/templates/organigramme-du-processus-de-publication-du-logiciel et /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production. Pour une construction complète, des exigences au lancement, utilisez /fr/templates/modele-diagramme-de-gantt-projet-logiciel.
Un planning de mise en production, construit par étapes
Dix-sept tâches en quatre groupes. Les durées sont des jours ouvrés illustratifs ; fixez les vôtres. Ouvrez le panneau tableur pour voir les lignes derrière chaque étape.
Le développement s'achève sur un jalon
« Terminer les fonctionnalités restantes » dure 10 jours ouvrés. « Corriger les défauts connus » (6 jours) démarre 5 jours ouvrés après le début de la tâche précédente, un lien début à début avec décalage, de sorte que la correction des défauts chevauche la fin du développement. « Fonctionnalités terminées » est un jalon de durée 0.
Le gel et trois flux de test
« Gel du code » est un jalon. « Tests de non-régression » (5 jours), « Contrôles de performance et de sécurité » (4) et « Recette utilisateur » (6) le suivent tous, et la recette démarre 2 jours ouvrés après le gel. « Corriger les bloquants » (3 jours) attend les trois.
Préparation et verrous du déploiement
« Rédiger les notes de version » et « Mettre à jour le runbook et le plan de retour arrière » (3 jours chacun) démarrent au gel, pas après les tests. « Déployer en production » (1 jour) attend « Validation de la version », les notes et le runbook. « Test de fumée en production » le suit.
Les jours après le déploiement
« Annoncer la version » (1 jour) et « Surveiller et traiter les premiers incidents » (5 jours) attendent tous deux le test de fumée, ils avancent donc côte à côte. « Rétrospective de la version » est la dernière tâche, une journée pour ce que le prochain plan devra changer.
Comment cela fonctionne
Lister les tâches entre la dernière fonctionnalité et le premier utilisateur
Écrivez chaque tâche qui doit finir avant et après la production, documents et plan de retour arrière compris. Donnez à chacune une durée en jours ouvrés. Jours entiers seulement : arrondissez à la hausse une tâche d'une demi-journée.
Définir le gel comme un jalon
Ajoutez une tâche de durée 0 pour le gel. Faites-la dépendre des tâches de développement, et faites dépendre d'elle les flux de test, les notes de version et le runbook.
Faire chevaucher ce qui peut l'être
Utilisez un lien début à début avec décalage là où le travail commence en cours de route d'une autre tâche, par exemple 4SS+2 dans Dépend de. Servez-vous-en pour la correction de défauts pendant le développement et pour une recette qui démarre quelques jours après le gel.
Réunir les flux avant la validation
Donnez à la tâche qui suit les tests une dépendance vers chaque flux, écrite sous forme de liste séparée par des virgules. La validation ne peut alors pas précéder le flux le plus lent.
Conditionner le déploiement et planifier les jours qui suivent
Faites dépendre le déploiement de la validation et des documents. Ajoutez un test de fumée, l'annonce et une fenêtre de surveillance comme tâches, pour que le temps de support fasse partie du plan.
Vérifier le chemin critique par rapport à votre date
Ouvrez le menu Affichage et activez le chemin critique. Comparez la date de fin avec la date dont vous avez besoin. Si la date est imposée, agissez sur la chaîne qui la fixe, car raccourcir d'autres tâches ne la fera pas bouger.
Erreurs à éviter
Rédiger les documents après les tests
Des notes de version et un plan de retour arrière écrits après les tests ajoutent leur durée à la fin du plan. Lancez-les au gel et faites attendre le déploiement pour qu'ils ne soient pas sautés sous la pression du temps.
Une validation sans jonction
Si la validation ne dépend que d'un seul flux de test, le diagramme affiche une date que les autres flux peuvent ne pas tenir. Liez-la, directement ou via une tâche de correction, à chaque flux.
Oublier les jours après le déploiement
Un plan qui s'arrête au déploiement masque la surveillance et les corrections qui suivent. Gardez une fenêtre de surveillance dans le diagramme, même si sa durée est une estimation.
Épingler la date de mise en production comme un début
Un début fixe sur la tâche de déploiement ne fait pas tenir le travail précédent. Si la date calculée est plus tardive que la date épinglée, le diagramme signale le conflit. Lisez cette alerte comme le message que la date ne peut pas être tenue avec ces estimations.
Ouvrir le diagramme de Gantt de mise en production
Ouvrez le modèle de mise en production, remplacez les durées par les vôtres et voyez quel flux de test fixe la date.
Guides associés
Questions fréquentes
Quelle doit être la durée d'un planning de mise en production ?
Autant que le travail entre le gel et la production en demande dans votre équipe. Les durées du modèle sont illustratives. Remplacez-les par ce que vos dernières mises en production ont pris, et incluez les jours après le déploiement.
Le gel doit-il être une tâche ou un jalon ?
Un jalon, c'est-à-dire une tâche de durée 0 dessinée en losange. Il marque le point que tout ce qui précède doit atteindre, et les flux de test s'y relient.
Puis-je voir quel flux de test fixe la date de mise en production ?
Oui. Activez le chemin critique dans le menu Affichage. Il éclaire la chaîne de tâches qui fixe la fin, et sélectionner une tâche éclaire ce dont elle dépend et ce qui dépend d'elle.
Est-ce adapté aux correctifs urgents ?
Un correctif urgent est un diagramme court : corriger, tester, valider, déployer, test de fumée. Dupliquez un diagramme de mise en production, supprimez ce dont vous n'avez pas besoin et gardez les verrous.
Où se trouve le processus de mise en production lui-même ?
Dans les modèles d'organigramme, qui dessinent les décisions et les approbations : /fr/templates/organigramme-du-processus-de-publication-du-logiciel et /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production. Utilisez le diagramme de Gantt pour la durée, et l'organigramme pour savoir qui décide de quoi.
