Estimation en XP

Les humains sont mauvais pour estimer le temps absolu. « Ça va prendre 3 jours » est presque toujours faux. Nous sous-estimons la complexité et surévaluons notre productivité.

Mais les humains sont bons pour la comparaison relative. « Cette histoire est environ deux fois plus grosse que celle-là » est quelque chose que nous pouvons faire de manière fiable.

XP utilise l'estimation relative. Au lieu d'estimer des heures, nous estimons la taille. Une histoire peut être un « 2 » ou un « 5 » ou un « 13 ». Ces chiffres ne signifient pas des heures ou des jours — ils signifient une taille relative par rapport à d'autres histoires.

Pourquoi le relatif fonctionne :

• Nous comparons des choses que nous comprenons (histoire à histoire, pas histoire à temps)
• C'est plus rapide (vous n'avez pas besoin de décompositions détaillées des tâches)
• C'est plus honnête (pas de fausse précision)
• Ça s'auto-corrige grâce au suivi de la vélocité

Les story points sont l'unité la plus courante pour l'estimation relative.

Les points représentent l'effort, la complexité et l'incertitude combinés — pas le temps. Une histoire de 5 points représente environ deux fois l'effort d'une histoire de 2 points (à peu près), mais pas nécessairement deux fois les heures.

Échelles de points courantes :

• Fibonacci : 1, 2, 3, 5, 8, 13, 21, ? (les écarts vous forcent à choisir)
• Puissances de 2 : 1, 2, 4, 8, 16 (simple doublement)
• Tailles de t-shirt : XS, S, M, L, XL (non numérique, bon pour la planification de haut niveau)

Conseils pour pointer les histoires :

• Comparez à des histoires de référence (« Est-ce plus gros ou plus petit que l'histoire X ? »)
• Ne réfléchissez pas trop (les points sont flous par conception)
• Incluez l'incertitude dans l'estimation (inconnu = plus gros)
• Ré-estimez si vous apprenez quelque chose qui change votre compréhension

Le Planning Poker est une technique pour atteindre un consensus d'équipe sur les estimations.

Comment ça fonctionne :

1. Le propriétaire de produit lit une histoire
2. Les membres de l'équipe posent des questions de clarification
3. Tout le monde sélectionne une carte d'estimation en privé
4. Toutes les cartes sont révélées simultanément
5. Les estimateurs les plus élevés et les plus bas expliquent leur raisonnement
6. L'équipe discute et revote si nécessaire
7. Un consensus émerge (ou la moyenne est prise)

Pourquoi une révélation simultanée ? Pour éviter l'ancrage. Si le développeur senior dit « 5 » en premier, tout le monde s'ajuste vers 5. Révéler simultanément capture des opinions indépendantes.

Pourquoi discuter des valeurs aberrantes ? La personne qui a dit « 13 » pourrait savoir quelque chose que les autres ne savent pas (« cela nécessite une migration de base de données »). La personne qui a dit « 2 » pourrait avoir une approche plus simple. Les deux points de vue améliorent l'estimation.

Le Planning Poker vise autant à construire une compréhension partagée qu'à obtenir un chiffre. La discussion fait ressortir les hypothèses, les risques et les décisions de conception.

La vélocité est le nombre de points que l'équipe complète par itération. C'est la clé pour transformer les estimations relatives en prédictions.

Si l'équipe a complété 30 points lors de la dernière itération, elle complétera probablement environ 30 points lors de la prochaine itération. C'est ce qu'on appelle la météo d'hier — le meilleur prédicteur de la météo de demain est la météo d'aujourd'hui.

Utiliser la vélocité :

• Si vous avez 100 points de travail et une vélocité de 20, attendez-vous à environ 5 itérations
• Si le client veut livrer en 3 itérations, vous pouvez faire environ 60 points de travail
• La vélocité fluctue ; utilisez une moyenne mobile (3 à 5 dernières itérations)

Ce qui affecte la vélocité :

• Composition de l'équipe (vacances, nouveaux membres)
• Environnement technique (nouveau framework, changements d'infrastructure)
• Type de travail (nouvelle fonctionnalité vs corrections de bogues)
• Concentration de l'équipe (les interruptions tuent la vélocité)

Ne truquez pas la vélocité. Ce n'est pas une métrique de productivité — c'est un outil de planification. Gonfler les points ou prendre des raccourcis pour « augmenter la vélocité » va à l'encontre du but.

Les estimations sont des suppositions. Elles seront erronées. XP reconnaît cela et intègre l'adaptabilité.

Échecs d'estimation courants :

• Inconnues inconnues : Une complexité imprévue émerge
• Dépendances : Des équipes ou systèmes externes causent des retards
• Dérive de la portée : L'histoire grandit au fur et à mesure que vous la construisez
• Dette technique : Le code existant est plus difficile à modifier que prévu

Que faire quand on est hors piste :

1. Faites-le remonter immédiatement (transparence)
2. Ré-estimez en fonction de la nouvelle compréhension
3. Discutez avec le propriétaire de produit
4. Négociez la portée si nécessaire (incrément plus petit, reporter des fonctionnalités)

Ne le cachez pas. Ne faites pas d'heures supplémentaires pour atteindre une mauvaise estimation. Le but de l'estimation est de planifier — si le plan est faux, changez-le.

Au fil du temps, les estimations s'améliorent. À mesure que l'équipe acquiert de l'expérience avec la base de code et entre eux, l'incertitude diminue. Mais elles ne seront jamais parfaites — c'est pourquoi XP met l'accent sur l'adaptation plutôt que la prédiction.