Estimation des coûts liés à la mise à niveau d'un framework

Les mises à niveau de version majeures ne sont pas des tickets. Ce sont des projets.

Les versions de correctifs sont des tickets. Les versions mineures sont généralement des tickets. Les versions majeures (celles qui comportent des changements rompant la compatibilité, des cycles de dépréciation, des cascades de dépendances entre bibliothèques et la mention « nous recommandons de migrer vers… » dans le journal des modifications) sont des projets, et le « planning poker » n’est pas l’outil adapté pour en estimer l’ampleur dans leur ensemble. La tâche intitulée « passer à React 19 » ou « Postgres 16 » ne correspond pas au travail en soi ; il s’agit d’un cadre englobant ce travail.

Considérer la mise à niveau comme une estimation unique conduit à un seul scénario d’échec : l’équipe vote 13, manque de temps dès la troisième semaine et livre une base de code à moitié migrée, qui comporte à la fois les bogues du nouveau framework et les conventions de l’ancien. La démarche la plus honnête consiste à décomposer la mise à niveau en une série de petites tâches, chacune pouvant faire l’objet d’une estimation indépendante, la mise à niveau elle-même constituant le projet global.

Ce qui se dit dans la salle

Ingénieur : « Le Codemod s’occupe de la majeure partie. »

Chapeau : « La plupart de quoi ? Qu’est-ce qu’il ne gère pas ? »

SRE : « Toutes nos dépendances prennent-elles déjà en charge la nouvelle version ? »

Question : « Quelle est notre stratégie de tests de régression pour ce diff ? »

PM : « Avons-nous d’autres livraisons prévues pour ce sprint, ou est-ce que c’est tout pour ce sprint ? »

Questions qu’il convient de se poser avant de voter

• Combien de modifications entraînant des incompatibilités vers l’arrière s’appliquent à notre base de code (lisez le journal des modifications et comptez-les) ?
• Les dépendances entre éléments prennent-elles en charge la version cible, ou faut-il les appliquer en cascade ?
• Codemod ou manuellement ? Quelle est la couverture du Codemod ?
• Couverture des tests sur les surfaces modifiées : est-elle suffisante, ou faut-il d’abord ajouter des tests ?
• Quelle stratégie de retour en arrière adopter si les choses tournent mal en cours de sprint ?
• Un PR ou plusieurs ? S’il y en a plusieurs, quel est l’ordre de dépendance ?

La conclusion appropriée de cette discussion est souvent : « Ce n’est pas une story, c’est un projet, alors planifions-le en conséquence », puis divisez-le en parties que chaque membre de l’équipe pourra estimer par rapport à une story de référence.

Ne attribuez pas un seul chiffre à une mise à jour majeure. Décomposez-la en « stories », puis évaluez l’ampleur de chacune d’entre elles.

Consultez la page « Techniques d’estimation » pour les travaux plus flous ou de plus grande envergure, et la page « Estimer un pic de recherche » pour connaître les étapes d’analyse qui doivent précéder l’estimation. Parcourez les autres exemples d’estimations concrètes.