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

Les mises à jour majeures de version 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 évaluer 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 simplement d’un cadre englobant ce travail.

Considérer la mise à niveau comme un seul et même projet entraîne 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 être estimée indépendamment, la mise à niveau elle-même constituant le projet global.

Ce qui se dit dans la salle

Ingénieur : « Le codemod s’occupe de l’essentiel. »

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

SRE : « Est-ce que toutes nos dépendances prennent déjà en charge la nouvelle version ? »

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

PM : « Y a-t-il 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 une incompatibilité vers l’arrière s’appliquent à notre base de code ? Faut-il lire le journal des modifications et les compter ?
Les dépendances entre éléments sont-elles compatibles avec la version cible, ou faut-il les appliquer en cascade ?
Codemod ou manuellement ? Quelle est la couverture du Codemod ?
La 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 ? Si 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 — planifions-le en conséquence », puis divisez-le en tranches 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 rubrique « Techniques d’estimation » pour les travaux plus flous ou de plus grande envergure, et la rubrique « Estimer un pic de recherche » pour l’analyse qui doit précéder l’estimation. Parcourez les autres « exemples d’estimations concrètes ».