Estimation de la mise à niveau d'une dépendance

Les correctifs et les modifications mineures ne sont que du bruit. Les modifications majeures dans les N bibliothèques correspondent à N pics — estimez le pire scénario, et non la moyenne.

Les mises à jour des dépendances se présentent sous deux formes qui semblent identiques dans la sortie du gestionnaire de paquets. La première : une série de correctifs et de mises à jour mineures que l’équipe devrait regrouper, soumettre à la suite de tests, puis fusionner en une seule demande de modification (PR) sans grand intérêt. Cette demande est notée 1, parfois 2, et la seule raison de voter pour celle-ci est de confirmer que l’équipe s’accorde à dire qu’elle est ennuyeuse. La deuxième forme : une mise à jour majeure concernant une ou plusieurs bibliothèques, dont le journal des modifications comporte une section « modifications rompant la compatibilité » que l’équipe doit lire. C’est le cas qui se cache à la vue de tous. L’équipe lui attribue un niveau de priorité 3 parce que « ce n’est qu’une mise à jour » et le déploie avec un niveau de priorité 13 trois sprints plus tard.

Il ne s’agit pas d’une mise à niveau du framework. Une mise à niveau du framework, c’est une bibliothèque pour laquelle vous avez planifié un trimestre ; l’équipe sait qu’il s’agit d’un projet. Une mise à jour de dépendance, c’est le ticket de maintenance discret que quelqu’un crée parce que l’analyse de sécurité a signalé six bibliothèques, et que personne n’a lu les journaux de modifications. Le piège réside dans la répartition : sur les six mises à jour, quatre sont mineures, une correspond à un export renommé et une autre à une refonte complète de l’API. L’estimation qui en fait la moyenne est erronée dans les deux sens.

Ce qui se dit dans la salle

Ingénieur A : « Il y a six bosses. Deux chacun. Treize au total. »

Chapeau : « Sont-ils tous mineurs ? »

Ingénieur A : « Trois mineures, trois majeures. »

Ingénieur B : « Est-ce que quelqu’un a lu les principaux journaux de modifications ? »

Ingénieur A : « …laissez-moi voir. »

Chapeau : « Nous n’avons pas encore d’estimation. Nous avons constaté trois pics. »

Le titre est pertinent. Il n’y a pas de chiffre unique pour cette histoire, car il n’y a pas d’histoire unique. Les petits problèmes s’additionnent et constituent un ensemble à part entière ; chaque problème majeur représente un pic à part entière jusqu’à ce que quelqu’un ait lu le journal des modifications et sache ce qui ne fonctionne plus.

Questions qu’il convient de se poser avant de voter

Combien de mises à jour y a-t-il, et quelle est la répartition entre versions majeures, mineures et correctives ?
Quelqu’un a-t-il lu les journaux des modifications correspondant aux versions majeures ?
Certaines de ces bibliothèques relèvent-elles de la responsabilité de l’équipe, ou sont-elles gérées par des fournisseurs ?
Existe-t-il un conflit de dépendance transitive qui les oblige à se produire simultanément ?
Quelle est la procédure de restauration si l’une des mises à jour perturbe l’environnement de production ?
L’équipe de sécurité a-t-elle un délai à respecter, ou s’agit-il d’une dette technique ?

Si la réponse à la question « Quelqu’un a-t-il lu les journaux de modifications ? » est « non », l’estimation n’est pas réaliste. Prévoyez un pic limité pour chaque mise à jour majeure, identifiez les problèmes réels, puis réévaluez le temps nécessaire à la mise en œuvre en fonction de vos conclusions.

N’évaluez pas les mises à niveau des dépendances en comptant simplement les versions. Lisez d’abord les journaux de modifications, puis évaluez ce que vous y avez trouvé.

Consultez « Estimation d’une mise à niveau du framework » pour la variante concernant une seule bibliothèque et une version majeure, ainsi que les autres « exemples d’estimation concrets ». Lancez une session gratuite de Planning Poker une fois que les spikes auront permis de déterminer ce qui va réellement changer.