9 min lecture • Guide 49 of 877
Définir des Deadlines de Projet Réalistes
Les deadlines irréalistes préparent les projets à l'échec dès le premier jour. Les équipes s'épuisent à courir pour atteindre des objectifs impossibles, la qualité souffre et la confiance s'érode quand les dates glissent. GitScrum fournit les outils basés sur les données pour créer des chronogrammes réalistes basés sur la capacité réelle de l'équipe, la performance historique et l'évaluation honnête des risques.
Le Problème du Deadline
Pourquoi les deadlines échouent et leurs conséquences:
| Cause Racine | Résultat |
|---|---|
| Définir date top-down | Deadline existe avant comprendre scope |
| Ignorer capacité équipe | Plus travail que heures disponibles |
| Pas de données historiques | Estimations basées sur espoir, pas réalité |
| Dépendances cachées | Travail bloqué par autres non comptabilisé |
| Pas de buffers | Un seul retard cascade jusqu'à date finale |
| Scope assumé fixe | Nouvelles exigences non factorisées |
Estimation Bottom-Up
Estimation par Story Points
PROCESSUS D'ESTIMATION:
┌─────────────────────────────────────────────────────────────┐
│ ÉTAPE 1: DÉCOMPOSER EPICS EN STORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Epic: Système d'Authentification Utilisateur │
│ ├── Story: UI formulaire login (3 pts) │
│ ├── Story: Validation mot de passe (2 pts) │
│ ├── Story: Génération token JWT (5 pts) │
│ ├── Story: Gestion session (5 pts) │
│ ├── Story: Flux reset mot de passe (5 pts) │
│ ├── Story: Intégration OAuth (8 pts) │
│ ├── Story: Configuration MFA (8 pts) │
│ └── Story: Verrouillage compte (3 pts) │
│ TOTAL: 39 points │
│ │
└─────────────────────────────────────────────────────────────┘
ÉTAPE 2: SESSION ESTIMATION ÉQUIPE:
┌─────────────────────────────────────────────────────────────┐
│ RÉSULTATS PLANNING POKER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Story: Intégration OAuth │
│ │
│ Votes développeurs: │
│ @Alex: 8 @Kim: 5 @Sam: 8 @Pat: 13 @Jordan: 8 │
│ │
│ Discussion: @Pat explique 13 pour particularités API LinkedIn│
│ Équipe accepte d'ajouter tâche recherche │
│ │
│ Estimation révisée: 8 points + 2 points spike LinkedIn │
│ │
│ Final: 10 points total │
│ │
└─────────────────────────────────────────────────────────────┘
Prévision Basée Vélocité
CALCUL VÉLOCITÉ:
┌─────────────────────────────────────────────────────────────┐
│ VÉLOCITÉ ÉQUIPE (6 Derniers Sprints) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sprint │ Engagé │ Complété │ Vélocité │
│ ──────────┼────────┼──────────┼────────── │
│ Sprint 19 │ 45 │ 38 │ 38 │
│ Sprint 20 │ 40 │ 42 │ 42 │
│ Sprint 21 │ 42 │ 40 │ 40 │
│ Sprint 22 │ 45 │ 44 │ 44 │
│ Sprint 23 │ 42 │ 41 │ 41 │
│ Sprint 24 │ 44 │ 43 │ 43 (en cours) │
│ ──────────┴────────┴──────────┴────────── │
│ │
│ VÉLOCITÉ MOYENNE: 41 points/sprint │
│ PLAGE: 38-44 points/sprint │
│ │
│ RECOMMANDATION: │
│ ├── Planification optimiste: 44 pts/sprint │
│ ├── Planification réaliste: 41 pts/sprint ← UTILISER │
│ └── Planification conservative: 38 pts/sprint │
│ │
└─────────────────────────────────────────────────────────────┘
CALCUL TIMELINE PROJET:
┌─────────────────────────────────────────────────────────────┐
│ PROJET: Portail Client v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TRAVAIL TOTAL ESTIMÉ: 245 story points │
│ VÉLOCITÉ ÉQUIPE: 41 points/sprint (sprints 2 semaines) │
│ │
│ CALCUL: │
│ 245 points ÷ 41 points/sprint = 5.97 sprints │
│ │
│ SCÉNARIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Optimiste (44 pts): 245 ÷ 44 = 5.6 sprints = 11 sem ││
│ │ Réaliste (41 pts): 245 ÷ 41 = 6.0 sprints = 12 sem ││
│ │ Conservateur (38 pts): 245 ÷ 38 = 6.4 sprints = 13 sem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RECOMMANDATION: 12-13 semaines (6-6.5 sprints) │
│ BUFFER AJOUTÉ: +2 semaines (15% contingence) │
│ DEADLINE PROPOSÉE: 14-15 semaines depuis début │
│ │
└─────────────────────────────────────────────────────────────┘
Gestion Buffers
Types de Buffers
STRATÉGIE BUFFERS:
┌─────────────────────────────────────────────────────────────┐
│ TYPES BUFFER ET ALLOCATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. BUFFER INCERTITUDE ESTIMATION (10-20%) │
│ Pour: Complexité inconnue, nouvelle technologie │
│ Règle: Plus élevé pour travail nouveau │
│ │
│ Exemple: 245 pts × 15% = ~37 points additionnels │
│ Temps: +1.5 semaines │
│ │
│ 2. BUFFER CHANGEMENT SCOPE (10-15%) │
│ Pour: Changements inévitables, clarifications │
│ Règle: Plus élevé clients externes │
│ │
│ Exemple: 245 pts × 10% = ~25 points additionnels │
│ Temps: +1 semaine │
│ │
│ 3. BUFFER RISQUE (5-15%) │
│ Pour: Risques connus qui pourraient matérialiser │
│ Règle: Basé sur évaluation registre risques │
│ │
│ Exemple: 2 risques élevés = 10% buffer │
│ Temps: +1 semaine │
│ │
│ 4. BUFFER INTÉGRATION/DÉPLOIEMENT (1-2 semaines) │
│ Pour: Tests finaux, prep déploiement, documentation │
│ Règle: Temps fixe, pas pourcentage │
│ │
│ Temps: +1.5 semaines │
│ │
│ TIMELINE TOTAL PROJET: │
│ ├── Travail core: 12 semaines │
│ ├── Buffer estimation: +1.5 semaines │
│ ├── Buffer scope: +1 semaine │
│ ├── Buffer risque: +1 semaine │
│ └── Intégration: +1.5 semaines │
│ ════════════════════════════ │
│ TOTAL: 17 semaines │
│ │
└─────────────────────────────────────────────────────────────┘
Niveaux de Confiance
FRAMEWORK CONFIANCE DEADLINE:
┌─────────────────────────────────────────────────────────────┐
│ COMMUNICATION BASÉE CONFIANCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Au lieu de: "Ce sera prêt le 15 avril" │
│ Dire: "Nous avons 80% confiance de livrer d'ici 15 avril" │
│ │
│ NIVEAUX CONFIANCE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 50% Confiance: 1 Avril (optimiste, pas buffers) ││
│ │ 70% Confiance: 8 Avril (réaliste, buffer minimal) ││
│ │ 80% Confiance: 15 Avril (engagement recommandé) ││
│ │ 90% Confiance: 22 Avril (conservateur, plus buffers) ││
│ │ 95% Confiance: 29 Avril (très sûr, max buffers) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMMUNICATION STAKEHOLDER: │
│ │
│ "Basé sur la vélocité de notre équipe et le scope défini, │
│ nous avons 80% confiance de livrer d'ici le 15 avril. │
│ │
│ Cela assume: │
│ - Pas d'ajouts majeurs de scope │
│ - Stabilité équipe (pas de départs) │
│ - Dépendances livrées à temps │
│ │
│ Si vous avez besoin de plus de certitude, le 22 avril │
│ nous donne 90% confiance avec buffer additionnel." │
│ │
└─────────────────────────────────────────────────────────────┘
Gestion Dépendances
Mapping Dépendances
VISUALISATION DÉPENDANCES:
┌─────────────────────────────────────────────────────────────┐
│ MAP DÉPENDANCES PROJET │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 │
│ ────────────────────────────────────────────────────────── │
│ │
│ [Système Auth]───────┐ │
│ │ │
│ [Design BD]──────────┼────►[Développement API]──────────┐ │
│ │ │ │
│ [Composants UI]──────┼────►[Dashboard UI] │ │
│ │ │ │ │
│ │ ▼ ▼ │
│ └────►[Intégration]────────►[Tests] │
│ │
│ CHEMIN CRITIQUE: BD → API → Intégration → Tests │
│ Durée: 5 semaines (minimum avec exécution parfaite) │
│ │
│ DÉPENDANCES AJOUTANT RISQUE: │
│ ├── Externe: Accès sandbox API Paiements (Semaine 2) │
│ ├── Interne: Infrastructure DevOps prête (Semaine 1) │
│ └── Client: Approbation contenu/copy (Semaine 4) │
│ │
└─────────────────────────────────────────────────────────────┘
Alignement Stakeholders
Négociation Deadline
SCÉNARIOS NÉGOCIATION:
┌─────────────────────────────────────────────────────────────┐
│ SCÉNARIO: STAKEHOLDER VEUT DEADLINE PLUS TÔT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stakeholder: "On a besoin pour le 15 mars, pas 22 avril." │
│ │
│ FRAMEWORK RÉPONSE: │
│ │
│ 1. RECONNAÎTRE LE BESOIN │
│ "Je comprends que le 15 mars est important pour la │
│ conférence ventes. Voyons ce qui est possible." │
│ │
│ 2. PRÉSENTER TRADE-OFFS │
│ "Pour atteindre 15 mars, on devrait ajuster le scope. │
│ Voici trois options:" │
│ │
│ Option A: Réduire scope │
│ ├── Retirer: Module reporting, OAuth │
│ ├── Garder: Auth core, Dashboard, Paiements │
│ └── Timeline: 10 semaines → 15 mars atteignable │
│ │
│ Option B: Augmenter équipe │
│ ├── Ajouter: 2 contractors pour 8 semaines │
│ ├── Coût: +40K€ │
│ └── Timeline: Peut-être 22 mars (amélioration 1 sem) │
│ │
│ Option C: Release par phases │
│ ├── 15 Mars: MVP (Auth, Dashboard basique) │
│ ├── 22 Avril: Release complet │
│ └── Conférence: Démo MVP, promettre complet avril │
│ │
│ 3. LAISSER STAKEHOLDER DÉCIDER │
│ "Quelle option correspond mieux à vos besoins?" │
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Anti-Patterns Deadline
CE QU'IL NE FAUT PAS FAIRE:
✗ DEADLINES PENSÉE MAGIQUE
"On travaillera plus dur" / "On trouvera une solution"
Réalité: Équipes ne peuvent pas soutenir crunch
✗ DEADLINE D'ABORD, SCOPE APRÈS
"Lancement est 1er juin, faites-le marcher"
Réalité: Scope ou qualité souffrira
✗ IGNORER DONNÉES VÉLOCITÉ
"Cette équipe devrait faire 60 points, pas 41"
Réalité: Données historiques sont meilleur prédicteur
✗ PAS DE BUFFERS
"Chaque jour est comptabilisé parfaitement"
Réalité: Quelque chose tourne toujours mal
✗ DEADLINES CACHÉES
"Dites avril mais on a vraiment besoin mars"
Réalité: Destruction confiance quand découvert