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 la modification côté système sans plan de dépréciation déploient 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 restera simplement en suspens pendant des mois, le temps que les équipes fonctionnelles s’en occupent quand elles le pourront.

Ce qui se dit dans la salle

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

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

Introduction : « 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 réels plutôt que des estimations ?
• Codemod ou migration manuelle ? Quelle est la couverture du Codemod ?
• Quel sera le calendrier de dépréciation (avertissement, erreur, suppression) ?
• La couverture des tests de régression visuelle a-t-elle été assurée sur les écrans concernés ?
• Communication entre équipes : à qui, quand et comment en parler ?
• 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 du travail ; il convient donc de les séparer : le nouveau composant constitue une « story », la migration des points d’appel en est une autre, et l’ampleur de cette dernière est déterminée par le nombre mesuré, et non par une estimation.

Évaluez la migration en aval. Le nouveau token représente une ligne ; les 200 sites d’appel correspondent au trimestre.

Tout comme pour l’estimation d’une mise à niveau de 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’estimation concrets, ou lancez une session gratuite de « planning poker » une fois que l’ampleur du travail en aval aura été évaluée.