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 concrètes 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 exécuteurs 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 fonctionne déjà pour la moitié de nos tâches. »

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

Chapeau : « 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 d’un collaborateur. La tâche consiste à « 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 cette tâche comme une suppression plutôt que comme 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 un projet. 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 demandent 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 avancée que l’équipe peut livrer et présenter. « Nous avons supprimé le 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 : commencez par identifier les inconnues (ce travail 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, comme une équipe externe ou une tâche planifiée ?
• Quelle serait la procédure de restauration si le nouveau pipeline présentait des problèmes 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 », cela signifie que l’équipe se trouve toujours dans la phase d’infrastructure parallèle et que 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 ; évaluez chaque suppression séparément.

Consultez la section « Découpage horizontal vs vertical » pour comprendre pourquoi « construire le nouveau système » constitue un mauvais axe de découpage, et découvrez d’autres exemples d’estimation réussis. Lancez une session gratuite de « planning poker » dès que l’équipe dispose d’une liste des éléments à supprimer.