5 min lecture • Guide 174 of 877
Estimer la durée des tâches avec précision
Une estimation précise est essentielle pour la planification mais notoirement difficile. La plupart des estimations sont optimistes parce qu'elles supposent que tout va bien. Une meilleure estimation combine données historiques, décomposition, input collaboratif et fourchettes d'incertitude explicites.
Défis de l'estimation
| Pourquoi les estimations échouent | Comment améliorer |
|---|---|
| Biais d'optimisme | Ajouter buffer explicite |
| Inconnues inconnues | Décomposer plus petit |
| Scope creep | Définir scope clairement |
| Étapes sautées | Inclure tout le travail |
| Variation individuelle | Estimation d'équipe |
Techniques d'estimation
Décomposition
DÉCOMPOSITION DE TÂCHE
══════════════════════
ESTIMATION ORIGINALE :
"Construire feature login" - 3 jours ❌ Trop vague
DÉCOMPOSÉE :
─────────────────────────────────────
"Construire feature login"
├── Concevoir endpoints API 2h
├── Implémenter auth backend 4h
├── Écrire tests unitaires 2h
├── Créer formulaire frontend 3h
├── Validation frontend 1h
├── Connecter frontend à API 2h
├── Tests end-to-end 2h
├── Gestion des erreurs 2h
├── Cycles de code review 2h
├── Corrections bugs de revue 2h
├── Mise à jour documentation 1h
├── Déployer et vérifier 1h
─────────────────────────────────────
TOTAL : 24h = 3 jours de codage
+ Buffer (30%) : 7h
= 4 jours réalistes ✓
RÈGLE DE DÉCOMPOSITION :
├── Aucune tâche > 4 heures
├── Si plus grande, décomposer encore
├── Inclure tâches non-codage
└── Être spécifique, pas vague
Comparaison historique
UTILISER LES DONNÉES HISTORIQUES
════════════════════════════════
TÂCHES PASSÉES SIMILAIRES :
─────────────────────────────────────
Type de feature : Formulaire utilisateur avec API
Exemples passés :
├── Formulaire inscription : Est 3j → Réel 4j
├── Mise à jour profil : Est 2j → Réel 3j
├── Page paramètres : Est 2j → Réel 2.5j
─────────────────────────────────────
Ratio moyen réel/estimé : 1.4x
NOUVELLE ESTIMATION :
Estimation feature login : 3 jours
Estimation calibrée : 3 × 1.4 = 4.2 jours
Arrondir : 5 jours
SUIVI DE CALIBRATION :
├── Enregistrer estimation pour chaque tâche
├── Enregistrer temps réel passé
├── Calculer ratio au fil du temps
├── Utiliser ratio pour calibrer
└── Améliorer ratio avec le temps
Estimation d'équipe
PLANNING POKER
══════════════
PROCESSUS :
1. Présenter la tâche à l'équipe
2. Clarifier les exigences
3. Chacun estime silencieusement
4. Révéler les estimations simultanément
5. Discuter des différences
6. Ré-estimer jusqu'à convergence
ÉCHELLE FIBONACCI :
├── 1, 2, 3, 5, 8, 13, 21, ?
├── L'écart augmente avec la taille
├── Reflète l'incertitude
└── ? = Trop grand, nécessite décomposition
EXEMPLE DE SESSION :
─────────────────────────────────────
Tâche : "Ajouter login OAuth"
Tour 1 : Sarah : 5, Mike : 8, Alex : 13
Discussion :
Sarah : "Intégration bibliothèque simple"
Mike : "Besoin gestion erreurs, tests"
Alex : "N'oubliez pas les fournisseurs multiples"
Tour 2 : Sarah : 8, Mike : 8, Alex : 8
Consensus : 8 points ✓
─────────────────────────────────────
Estimation en trois points
ESTIMATIONS EN TROIS POINTS
═══════════════════════════
POUR CHAQUE TÂCHE :
├── Optimiste (O) : Tout va bien
├── Plus probable (M) : Conditions normales
├── Pessimiste (P) : Les choses vont mal
FORMULE PERT :
Estimation = (O + 4M + P) / 6
EXEMPLE :
─────────────────────────────────────
Tâche : Implémenter feature recherche
Optimiste : 2 jours (exigences simples, pas de bugs)
Plus probable : 4 jours (développement normal)
Pessimiste : 8 jours (cas limites complexes, rework)
Estimation PERT = (2 + 4×4 + 8) / 6 = 4.3 jours
RAPPORTER COMME FOURCHETTE :
"4-5 jours, peut aller jusqu'à 8 si complications"
─────────────────────────────────────
Buffers et incertitude
GESTION DES BUFFERS
═══════════════════
TYPES DE BUFFERS :
├── Buffer de tâche : +20-30% sur chaque tâche
├── Buffer de sprint : +10-15% sur le sprint
├── Buffer de projet : +20% sur le projet total
└── Buffer d'inconnues : Selon niveau de risque
RÈGLES DE BUFFER :
─────────────────────────────────────
Nouveau domaine technique : +50%
Première intégration tierce : +40%
Refactoring code legacy : +30%
Développement standard : +20%
Correction de bug connu : +10%
─────────────────────────────────────
Bonnes pratiques
- Décomposez en morceaux de 4h max avant d'estimer
- Utilisez les données historiques pour calibrer
- Estimez en équipe pas individuellement
- Incluez tout le travail (tests, revue, déploiement)
- Utilisez des fourchettes pas des points uniques
- Ajoutez des buffers explicites selon le risque
- Suivez réel vs estimé pour chaque tâche
- Apprenez et ajustez continuellement