Estimation d'une refonte du processus CI/CD

Les travaux sur le pipeline ne font pas l’objet d’une démonstration. Limitez-vous à déterminer « quelle version peut être supprimée aujourd’hui » afin de pouvoir continuer à estimer le travail.

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 version. 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 personnalisé à un fichier de workflow approprié. 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 d’ingénierie.

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 de 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 qu’on laisse tomber 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é. »

Chapeau : « D’accord. Nous aurons donc terminé lorsque nous pourrons supprimer l’ancien. »

C’est là tout l’enjeu. 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, dans le cadre d’un projet ponctuel mené 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 achevé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 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 demandent un réel travail (une suite de tests comporte un chemin d’accès codé en dur ; une é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 projet comporte-t-il des utilisateurs dont nous n’avons pas connaissance ?), puis estimez la suppression en la comparant à 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é en trench-coat.

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é sur le fait que « 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 au 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 l’histoire 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 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 d’éléments à supprimer.