Évaluation de l'impact d'une modification du système de conception
Comment évaluer l'impact d'une modification apportée à un système de conception : déploiements de tokens, parcours de dépréciation, couverture par Codemod et les 200 points d'appel qui utilisent l'ancien composant. Évaluez l'impact en aval.
L’article évalue 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 token, 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 au niveau du 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 —, sans quoi le travail restera simplement en suspens pendant des mois, les équipes fonctionnelles s’y attelant quand bon leur semble.
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 ? »
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 : « Quel est le délai prévu pour l’abandon 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 ?
- Processus de dépréciation : avertissement, erreur, suppression — selon quel calendrier ?
- Couverture des tests de régression visuelle sur les écrans concernés ?
- Communication entre équipes : à qui, quand et comment en parler ?
- Faut-il revenir à la version précédente 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 correspond à 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 marqueur est une ligne ; les 200 sites d’appel constituent le quart.
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 travail en aval a été chiffré.