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, fédération, limitation du débit, sessions) et les questions à se poser avant tout vote.

Comment évaluer l'intégration d'un système d'authentification unique (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 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 un délai 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 un délai pour 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 compte mentionné dans le ticket qui détermine l'ampleur du problème. Comment distinguer la correction en une ligne de la 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 masque 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 fonction de ce qui peut être supprimé. 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 inhérentes 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 est de déterminer des limites qui ne susciteront aucune plainte.

Comment évaluer l'impact d'une modification du 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 é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 une période délimitée dans le temps associée à un livrable, et non une « story ». Comment éviter qu’il ne devienne insidieusement le travail dont il était censé définir le périmètre.

Comment évaluer un prototype : il s'agit d'un livrable destiné à l'apprentissage, et non à une utilisation concrète. Comment éviter que ce prototype, initialement 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 le montant d'un budget, et non pas établir des prévisions.