Estimation du déploiement d'un indicateur de fonctionnalité
Comment estimer le déploiement d'un « feature flag » : pourcentages par étapes, « kill-switches », indicateurs de contrôle et le nettoyage que personne ne prévoit. Un « feature flag » est un petit produit, pas un simple déploiement.
L’histoire met le drapeau en place, mais oublie le nettoyage, les indicateurs de performance et le dispositif d’arrêt d’urgence.
Un « feature flag » n’est pas un mécanisme de déploiement ; c’est un petit produit à part entière. Il nécessite une valeur par défaut, une procédure de contournement, une piste d’audit, un « kill-switch » et un plan de retrait. La plupart de ces éléments font défaut dans le ticket d’origine, qui se résume généralement à « intégrez-le dans un flag ». Ce ticket constitue le point de contrôle, et non la fonctionnalité elle-même.
L’estimation doit tenir compte des phases de déploiement (1 % → 10 % → 50 % → 100 %), des indicateurs permettant de décider s’il faut accélérer ou revenir en arrière à chaque phase, ainsi que du ticket de nettoyage visant à supprimer le drapeau une fois que la fonctionnalité est définitive. Les équipes qui ne prévoient pas cette opération de nettoyage se retrouvent, en moins d’un an, avec une base de code truffée de marqueurs obsolètes, ce qui constitue en soi une dette opérationnelle.
Ce qui se dit dans la salle
Backend : « Envelopper l’appel dans un indicateur, quelques lignes. »
SRE : « Quel indicateur nous permet de savoir que le déploiement ne se passe pas comme prévu ? »
PM : « Pour quelles cohortes ce paramètre est-il activé en premier ? »
Chapeau : « Qui retire le drapeau une fois que nous avons atteint les 100 %, et à quel moment ? »
Backend : « Existe-t-il un « kill switch » distinct du drapeau ? »
Questions qu’il convient de se poser avant de voter
- Mode de déploiement : en pente linéaire, par cohortes ou par basculement binaire ?
- Valeur par défaut si le service « flag » est hors service : ancien comportement ou nouveau ?
- Indicateurs permettant de valider chaque phase : qu’est-ce qui signifie que « tout se passe bien » ?
- Le chemin d’accès au « kill switch » est-il indépendant du système de drapeaux ?
- Bon d’enlèvement : à établir dès le départ, ou « on s’en occupera plus tard » ?
- Historique des modifications : qui a modifié le drapeau, quand et pourquoi ?
La solution est la même que pour la plupart des « stories » de déploiement : split la mise en œuvre, le déploiement par étapes et le nettoyage en « stories » distinctes, puis créez le ticket de suppression avant d’oublier qu’il existe.
Un « flag » est un petit produit. Évaluez la phase de montée en puissance, les indicateurs de sélection des projets et le nettoyage, et pas seulement la mise en place.
Consultez « Estimation d’un déploiement avec limitation de débit » pour découvrir le même schéma « le déploiement accapare le travail », ainsi que les autres exemples d’estimation concrets. Lancez une session gratuite de planning poker une fois que les phases ont été nommées.