Techniques d'Estimation de Projet

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

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         │
└─────────────────────────────────────────────────┘

Solutions Connexes

• Techniques d'Estimation Agile
• Planification Sprints avec Capacité Précise
• Planification de Capacité pour Équipes Dev