Exemples d'estimations détaillées

Comment évaluer une fonctionnalité de connexion : les aspects cachés — réinitialisation du mot de passe, authentification à deux facteurs (2FA), fédération, limitation du débit, sessions — et les questions à poser avant que quiconque ne vote.

Comment évaluer une intégration SSO : le travail ne se limite pas à votre base de code, mais réside dans les particularités du fournisseur d'identité. Les questions auxquelles il faut répondre avant de fixer un budget.

Comment évaluer une intégration de paiement : environnement de test vs environnement de production, remboursements, webhooks, idempotence, périmètre PCI. La discussion qui doit avoir lieu avant que le moindre chiffre ne soit arrêté.

Comment évaluer une fonctionnalité de recherche : pertinence, classement, facettes et responsable de l'index. Les questions qui transforment la simple idée d'« ajouter une barre de recherche » en une véritable évaluation.

Comment évaluer un système de notification : canaux, préférences, déduplication et garanties de livraison. Pourquoi « envoyer un e-mail » se transforme insidieusement en un projet de six semaines.

Comment évaluer le téléchargement d'un fichier : limites de taille, analyse antivirus, reprise du téléchargement, stockage et conservation. Le glisser-déposer, c'est la partie la plus simple ; c'est tout ce qui se passe en arrière-plan qui est le plus délicat.

Comment évaluer un tableau de bord : sources de données, fréquence d'actualisation, fuseaux horaires, exploration en profondeur, autorisations. Le graphique est simple ; c'est le pipeline de données qui se cache derrière qui demande du travail.

Comment estimer un test instable : pourquoi il faut deux estimations, et non une seule, et pourquoi il vaut mieux fixer une limite de temps plutôt que de débattre du nombre de points lorsque la réponse dépend de ce que vous découvrirez.

Comment évaluer un bug impossible à reproduire : vous ne pouvez pas estimer le temps nécessaire à la correction, mais uniquement celui de la recherche. Comment fixer une durée limite à l'investigation plutôt que de voter sur une tâche que personne ne peut voir.

Comment évaluer une baisse de performances : le travail consiste principalement à établir un diagnostic, et non à apporter une solution. Comment en évaluer l'ampleur lorsque la cause est inconnue et qu'un SLO est en jeu.

Comment évaluer un bug signalé par un client : c'est le contenu du ticket qui détermine son ampleur. Comment faire la distinction entre une correction d'une ligne et une réponse qui va accaparer tout le sprint.

Comment estimer la durée d'une migration de base de données : remplissage, durée du verrouillage, déploiement et restauration. La commande « Ajouter une colonne » ne représente qu'une ligne de code SQL ; l'estimation porte sur la seconde.

Comment estimer la durée d'une migration de données : transfert de données entre systèmes, rapprochement et basculement. La transformation dure une heure ; le nettoyage dure un trimestre.

Comment évaluer la mise à niveau d'un framework : pourquoi un changement de version majeur constitue un projet et non un ticket, et comment le décomposer en « stories » dont vous pouvez réellement évaluer l'ampleur.

Comment évaluer la mise à niveau d'une dépendance : l'augmentation à long terme qui cache N pics dans un seul ticket. Lisez d'abord les journaux de modifications, puis évaluez ce que vous avez trouvé.

Comment évaluer l'ampleur d'une refonte CI/CD : le travail sur le pipeline ne se prête pas à une démonstration, il faut donc le décomposer en éléments pouvant être supprimés. Ce projet d'une durée d'un trimestre qui se cache dans le backlog sous la forme d'une refonte.

Comment évaluer le remplacement d'une API tierce : lacunes sémantiques, exécution parallèle et hypothèses sous-jacentes aux particularités de l'ancien fournisseur. La nouvelle API n'en a qu'apparemment l'air.

Comment planifier la mise en place d'une limitation de débit : seuils, périodes de test, communication avec les clients. L'écriture du code ne prend qu'une demi-journée ; le plus difficile, c'est de définir des limites qui ne suscitent aucune plainte.

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.

Comment évaluer l'ampleur d'une correction en matière d'accessibilité : les problèmes d'accessibilité (a11y) correspondent à des fonctionnalités que vous n'avez pas intégrées dès le départ. Pourquoi il faut évaluer l'ampleur du problème dans son ensemble, et non pas un cas isolé.

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.

Comment évaluer un « spike » de recherche : un « spike » est un intervalle de temps défini avec un livrable, et non une « story ». Comment éviter qu’il ne devienne insidieusement le travail dont il était censé délimiter le périmètre.

Comment évaluer un prototype : il s'agit d'un livrable conçu pour l'apprentissage, et non pour une utilisation réelle. Comment éviter que ce prototype, destiné à être jeté, ne devienne le code de production que personne n'avait prévu.

Comment évaluer une expérience d'apprentissage automatique : il s'agit de recherche associée à l'ingénierie — le modèle est simple, ce sont les données qui demandent du travail. Comment déterminer un budget, et non pas une prévision.