Techniques d'Estimation de Projet
Estimez le travail projet avec précision en utilisant des techniques éprouvées. Améliorez l'estimation au fil du temps avec la calibration et les données historiques.
4 min de lecture
Une estimation précise est la base d'une planification réaliste—sous-estimez et vous ratez les délais, surestimez et vous perdez la confiance. Les points d'effort de GitScrum et les données de vélocité historique aident les équipes à calibrer les estimations par rapport à la performance réelle, améliorant la précision au fil du temps. La clé est de traiter l'estimation comme une compétence à développer, pas une science exacte.
Approches d'Estimation
| Technique | Idéale Pour | Précision | Effort |
|---|---|---|---|
| Story Points | Planification sprint | Moyenne-Haute | Moyen |
| Planning Poker | Consensus équipe | Moyenne-Haute | Moyen |
| T-Shirt Sizing | Planification roadmap | Basse-Moyenne | Faible |
| Données Historiques | Prévision | Haute | Faible |
| Trois Points | Estimations conscientes risque | Moyenne-Haute | Élevé |
Estimation en Story Points
FONDAMENTAUX STORY POINTS
CE QUE REPRÉSENTENT LES POINTS:
┌─────────────────────────────────────────────────┐
│ Les story points mesurent l'effort relatif: │
│ │
│ Effort = Complexité + Incertitude + Volume │
│ │
│ PAS mesuré en heures parce que: │
│ ├── Différentes personnes travaillent à vitesses│
│ │ différentes │
│ ├── Même personne varie jour après jour │
│ └── Les points sont plus stables dans le temps │
└─────────────────────────────────────────────────┘
ÉCHELLE DE POINTS (Fibonacci):
┌─────────────────────────────────────────────────┐
│ 1 point: Trivial, bien compris │
│ Exemple: Changement texte, config │
│ │
│ 2 points: Petit, simple │
│ Exemple: Ajouter champ au formulaire │
│ │
│ 3 points: Moyen, quelque complexité │
│ Exemple: Nouvel endpoint API │
│ │
│ 5 points: Grand, plusieurs composants │
│ Exemple: Feature avec UI + backend │
│ │
│ 8 points: Très grand, inconnues significatives │
│ Exemple: Nouvelle intégration │
│ Considérer: Doit-on découper ? │
│ │
│ 13 points: Taille Epic, trop grand │
│ Doit être découpé │
└─────────────────────────────────────────────────┘
STORIES DE RÉFÉRENCE:
┌─────────────────────────────────────────────────┐
│ Établir des stories de calibration équipe: │
│ │
│ "Ajouter widget au dashboard" = 3 points │
│ "Correction bug simple" = 1 point │
│ "Nouvelle feature end-to-end" = 5-8 points │
│ │
│ Comparer nouvelles stories aux références: │
│ "Est-ce plus dur ou plus facile que le widget?"│
└─────────────────────────────────────────────────┘
Planning Poker
PROCESSUS PLANNING POKER
CONFIGURATION:
┌─────────────────────────────────────────────────┐
│ Participants: Équipe développement (tous ceux │
│ qui travailleront sur les items) │
│ │
│ Cartes: 0, 1, 2, 3, 5, 8, 13, ?, ☕ │
│ ├── 0: Déjà fait ou trivial │
│ ├── 1-13: Estimations story points │
│ ├── ?: Besoin de plus d'information │
│ └── ☕: Besoin d'une pause │
└─────────────────────────────────────────────────┘
PROCESSUS:
┌─────────────────────────────────────────────────┐
│ 1. Product Owner lit la user story │
│ │
│ 2. L'équipe pose des questions de clarification│
│ (Time-box: 2-3 minutes) │
│ │
│ 3. Chacun sélectionne privément une carte │
│ │
│ 4. Tous révèlent simultanément │
│ │
│ 5. Discuter les différences: │
│ ├── Plus haut: "Pourquoi tu penses 8 ?" │
│ ├── Plus bas: "Pourquoi tu penses 2 ?" │
│ └── Discussion révèle complexité cachée │
│ │
│ 6. Re-voter si nécessaire │
│ (Converge généralement en 2 tours) │
│ │
│ 7. Enregistrer estimation consensuelle │
└─────────────────────────────────────────────────┘