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 en place le drapeau, 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 sont absents du ticket initial, qui se résume généralement à « intégrez-le dans un flag ». Ce ticket constitue la porte d’entrée, 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 qui supprime 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 bien ? »
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 dispositif d’arrêt d’urgence distinct de l’indicateur ? »
Questions qu’il convient de se poser avant de voter
- Mode de déploiement : rampe linéaire, par cohorte ou 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 : faut-il le créer 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 : divisez la mise en œuvre, le déploiement par étapes et le nettoyage en « stories » distinctes, et créez le ticket de suppression avant d’oublier qu’il existe.
Un drapeau est un petit produit. Évaluez la phase de démarrage, les indicateurs de lancement et le nettoyage, et pas seulement la mise en place.
Consultez la section « Estimation du déploiement d’une limitation de débit » pour découvrir le même schéma « le déploiement accapare le travail », ainsi que d’autres exemples d’estimation concrets. Lancez une session gratuite de « planning poker » lorsque les phases auront été nommées.