Estimation d'une refonte du processus CI/CD

Le travail sur le pipeline ne fait pas l’objet d’une démonstration. Limitez-vous à déterminer « quelle version peut être supprimée aujourd’hui » afin que cela reste estimable.

Les refontes CI/CD constituent les tâches les moins bien définies du backlog. Elles n’offrent aucun résultat visible pour l’utilisateur, aucune démo, aucune capture d’écran que l’on puisse inclure dans les notes de mise à jour. Le travail est de nature structurelle : remplacer un pipeline par un autre, migrer un système de build, regrouper trois outils d’exécution de tests en un seul, passer d’un script shell créé manuellement à un fichier de workflow conforme. L’équipe sait que ce travail doit être effectué. Elle sait également qu’il prendra un trimestre, et que ce trimestre restera invisible en dehors de l’organisation technique.

Le mode de défaillance de l’estimation est prévisible. L’équipe vote « 13 » car « c’est une refonte, c’est un gros projet ». Après trois sprints, l’ancien pipeline fonctionne toujours en parallèle du nouveau, les deux systèmes sont partiellement configurés, et chaque ingénieur a une vision différente quant à celui qu’il faut utiliser. La story n’est pas terminée car il n’y a pas de définition de « terminé » : les pipelines ne sont pas « livrés » ; ils sont adoptés, et leur adoption est une question distincte du simple fait que « la nouveauté existe ».

Ce qui se dit dans la salle

SRE : « Il faut remplacer l’ancien coureur. Deux sprints. »

Chapeau : « Qu’entend-on par « terminé » ? »

SRE : « … le nouveau fonctionne. »

Chapeau : « Le nouveau modèle est déjà opérationnel pour la moitié de nos missions. »

Backend : « Mais l’ancien fonctionne toujours pour l’autre moitié. »

Lead : « Exactement. Nous aurons donc terminé lorsque nous pourrons supprimer l’ancien. »

C’est ça, l’essentiel. L’objectif n’est pas de « construire le nouveau pipeline » — l’équipe l’a probablement déjà mis en place il y a plusieurs mois, lors d’un projet ponctuel réalisé pendant le temps libre de l’un des membres. L’objectif, c’est de « supprimer l’ancien pipeline ». Tant que l’ancien système de build n’aura pas disparu, la refonte ne sera pas terminée ; il s’agit d’une infrastructure parallèle qui engendre tous les coûts sans apporter aucun avantage. Considérer cet objectif comme une suppression plutôt qu’une création donne à l’équipe une définition de « terminé » sur laquelle elle peut se prononcer.

Comment le découper ?

Faites l’inventaire des tâches encore en cours d’exécution sur l’ancien système. Pour chaque tâche : que faudrait-il faire pour supprimer l’ancienne version ? C’est là tout l’enjeu. Certaines sont simples (la tâche a déjà été répliquée dans le nouveau pipeline ; il suffit de supprimer l’ancien fichier YAML). D’autres nécessitent un véritable travail (la suite de tests comporte un chemin d’accès codé en dur ; l’étape de déploiement dépend d’une ancienne variable d’environnement). Chaque suppression constitue une petite étape que l’équipe peut livrer et présenter. « Nous avons supprimé le fichier Jenkinsfile du service d’authentification » est un résultat que l’on peut présenter.

Chaque suppression peut être estimée de la manière habituelle : identifiez d’abord les inconnues (ce projet comporte-t-il des utilisateurs dont nous n’avons pas connaissance ?), puis estimez la suppression par rapport à une suppression de référence que vous avez déjà mise en œuvre. La plupart des tranches se situent autour de 2 ou 3 points. Ce qui était présenté comme « 13, refactorisation, importante » correspondait en réalité à quinze « 2 » et un « 3 » déguisé.

Questions qu’il convient de se poser avant de voter

Qu’est-ce qui sera supprimé une fois cet article publié ?
Quels sont les emplois qui dépendent encore de l’ancien système ?
Y a-t-il un utilisateur de l’ancien pipeline dont nous n’avons pas connaissance — une équipe externe, une tâche planifiée ?
Quelle serait la procédure de restauration si le nouveau pipeline présentait une régression après la suppression de l’ancien ?
Qui fait autorité en ce qui concerne l’affirmation selon laquelle « le nouveau pipeline est la source de vérité » ?
Y a-t-il quelqu’un qui recense, semaine après semaine, les tâches exécutées sur l’ancien système par rapport à celles exécutées sur le nouveau ?

Si la réponse à la question « Qu’est-ce qui est supprimé ? » est « rien pour ce sprint », l’équipe se trouve toujours dans la phase d’infrastructure parallèle et la story ne passe pas le contrôle de préparation.

Les travaux sur le pipeline sont effectués une fois l’ancien système supprimé. Procédez par étapes ; estimez chaque suppression séparément.

Consultez la rubrique « Découpage horizontal ou vertical » pour comprendre pourquoi « construire le nouveau système » ne constitue pas un axe de découpage approprié, ainsi que les autres exemples d’estimations concrètes. Lancez une session gratuite de Planning Poker dès que l’équipe dispose d’une liste des éléments à supprimer.