Estimation de l'impact d'une modification du système de conception

L’article donne une estimation concernant le nouveau composant, mais oublie les 200 sites qui utilisent l’ancien.

Une modification du système de conception comporte deux volets. Le premier concerne le système lui-même : le nouveau composant, le nouveau jeton, la documentation mise à jour. Le second concerne les points d’appel : toutes les fonctionnalités du produit qui utilisaient l’ancienne version et qui doivent être migrées vers la nouvelle. La première portée est restreinte et bien connue. C’est la seconde qui explique pourquoi ce travail prend en réalité un trimestre.

Les équipes qui déploient une modification côté système sans plan de dépréciation déploient en réalité deux systèmes : le nouveau, et tous les endroits où l’ancien est encore utilisé. L’estimation doit inclure le déploiement (modification du code ou migration manuelle, calendrier de dépréciation, stratégie de régression visuelle) ; sinon, le travail s’interrompt tout simplement pendant des mois, le temps que les équipes fonctionnelles s’y attellent quand elles le pourront.

Ce qui se dit dans la salle

Concepteur : « La nouvelle fiche ne nécessite qu’une seule ligne de modification. »

Front-end : « Combien de composants l’utilisent aujourd’hui ? »

Question principale : « Allons-nous procéder à une refonte du code, ou les équipes fonctionnelles se chargent-elles elles-mêmes de la migration ? »

QA : « Régression visuelle : Percy ? Manuel ? Les deux ? »

PM : « Quelle est la période de dépréciation de l’ancienne version ? »

Questions qu’il convient de se poser avant de voter

• Combien de sites d’appel sont concernés, selon des chiffres avérés et non des estimations ?
• Codemod ou migration manuelle ? Quelle est la couverture du Codemod ?
• Quel sera le calendrier de la phase de dépréciation (avertissement, erreur, suppression) ?
• Couverture des tests de régression visuelle sur les écrans concernés ?
• Communication entre équipes : à qui le dire, quand et comment ?
• Faut-il revenir en arrière si le nouveau composant présente un bug qui n’apparaît qu’en production ?

La modification en amont est mineure et c’est le nettoyage en aval qui demande le plus de travail ; il convient donc de les séparer : le nouveau composant correspond à une « story », la migration des points d’appel en est une autre, et la taille de cette dernière est déterminée par le nombre mesuré, et non par une estimation.

Estimez la migration en aval. Le nouveau token est une ligne ; les 200 sites d’appel constituent le trimestre.

Tout comme l’estimation d’une mise à niveau du framework, la modification en amont est mineure et c’est le nettoyage en aval qui représente le plus gros du travail. Consultez les autres exemples d’estimations concrètes, ou lancez une session gratuite de Planning Poker lorsque le volume de travail en aval est connu.