11 min lecture • Guide 868 of 877
Outils pour aligner la livraison de sprint entre équipes d'ingénierie
Aligner la livraison entre équipes d'ingénierie nécessite plus que le suivi des tâches. Plusieurs équipes travaillant sur le même produit ont besoin d'une visibilité partagée sur les engagements de sprint, d'un suivi des dépendances entre les livrables des équipes, et d'une planification coordonnée des releases qui tient compte des bloqueurs inter-équipes.
Aperçu de l'alignement de sprint
| Défi | Solution | Fonctionnalité GitScrum |
|---|---|---|
| Visibilité cloisonnée | Vues inter-projets | Tableaux de bord multi-boards |
| Conflits de dépendances | Liaison explicite | Relations entre tâches |
| Coordination des releases | Jalons partagés | Suivi des milestones |
| Timing d'intégration | Sprints coordonnés | Config. sync sprint |
| Escalade des bloqueurs | Visibilité + alertes | Suivi blockers, notifications |
Le défi de livraison multi-équipes
RÉALITÉ DE L'INGÉNIERIE MULTI-ÉQUIPES
═════════════════════════════════════
STRUCTURE TYPIQUE DE PRODUIT :
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ RELEASE PRODUIT v2.5 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ PLATEFORME │ │ FRONTEND │ │ MOBILE │ │
│ │ │ │ │ │ │ │
│ │ - API v2 │ │ - Dashboard │ │ - App iOS │ │
│ │ - Auth │ │ - Paramètres│ │ - Android │ │
│ │ - Database │ │ - Billing │ │ │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DÉPENDANCES PARTAGÉES │ │
│ │ Frontend a besoin API v2 → Plateforme doit livrer │ │
│ │ Mobile a besoin Auth → Plateforme doit terminer │ │
│ │ Les deux ont besoin migration DB → Coordination │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
SANS ALIGNEMENT :
├── Équipe A livre changement breaking d'API
├── Frontend de l'Équipe B casse en staging
├── App mobile de l'Équipe C échoue en prod
└── Release retardée de 2 semaines pour corrections
AVEC ALIGNEMENT :
├── Dépendances visibles pour toutes les équipes
├── Changements breaking communiqués tôt
├── Tests d'intégration coordonnés
└── Release livrée à temps
Modèles de synchronisation de sprint
OPTIONS DE CADENCE DES ÉQUIPES
══════════════════════════════
OPTION A : SPRINTS SYNCHRONISÉS
─────────────────────────────────────
Toutes les équipes partagent même début/fin :
Semaine 1 Semaine 2 Semaine 3 Semaine 4
│ │ │ │
├─────────────┼─────────────┼─────────────┤
│ Sprint 1 │ Sprint 2 │ Sprint 3 │
│ │ │ │
│ Plateforme ─┼─────────────┼─────────────┤
│ Frontend ───┼─────────────┼─────────────┤
│ Mobile ─────┼─────────────┼─────────────┤
Avantages :
├── Simple à coordonner
├── Dates de livraison claires
├── Rétrospectives ensemble faciles
└── Sessions de planification partagées
Inconvénients :
├── Moins de flexibilité par équipe
├── Dépendances doivent tenir dans le sprint
└── Livraison tout-ou-rien
OPTION B : SPRINTS DÉCALÉS
─────────────────────────────────────
Équipes décalées d'1 semaine :
Semaine 1 Semaine 2 Semaine 3 Semaine 4
│ │ │ │
Plateforme ───┼─────────────┼────────────────
Frontend ─────────────┼────────────
Mobile ─────────────┼─────
Avantages :
├── Plateforme peut livrer en premier
├── Équipes downstream consomment
├── Réduit les blocages
└── Plus de flexibilité
Inconvénients :
├── Plus difficile de coordonner les releases
├── Multiples sessions de planification
└── Fenêtres d'intégration varient
OPTION C : TRAINS DE RELEASE
─────────────────────────────────────
Dates de release fixes, sprints variables :
──────► Temps ──────►
│ │
▼ ▼
Train 1 Train 2
(15 Jan) (15 Fév)
│ │
│ Plateforme ────────│
│ Frontend ──────────│
│ Mobile ────────────│
│ │
Limite : 10 Jan Limite : 10 Fév
Avantages :
├── Releases prévisibles
├── Équipes travaillent à leur rythme
├── Dates limites claires
└── Adapté aux entreprises
Inconvénients :
├── Features peuvent rater le train
├── Nécessite de la discipline
└── Plus de charge de planification
Cartographie des dépendances
SUIVI DES DÉPENDANCES INTER-ÉQUIPES
═══════════════════════════════════
TYPES DE DÉPENDANCES :
─────────────────────────────────────
DÉPENDANCE DURE (Bloquante)
┌──────────────────────────────────────┐
│ Tâche B ne peut pas commencer avant │
│ que Tâche A soit terminée │
│ │
│ [Endpoint API] ──► [Vue Frontend] │
│ Plateforme Frontend │
│ │
│ Si API retardée → Frontend bloqué │
└──────────────────────────────────────┘
DÉPENDANCE SOUPLE (Coordonnée)
┌──────────────────────────────────────┐
│ Les tâches peuvent avancer │
│ indépendamment mais nécessitent │
│ coordination │
│ │
│ [Auth iOS] ◄──► [Auth Android] │
│ Mobile Mobile │
│ │
│ Même spec, implémentations diff. │
└──────────────────────────────────────┘
DÉPENDANCE EXTERNE (Tiers)
┌──────────────────────────────────────┐
│ En attente d'une partie externe │
│ │
│ [Intégration Paiement] ──► [Stripe] │
│ Plateforme Externe │
│ │
│ Peut avoir un délai imprévisible │
└──────────────────────────────────────┘
VISUALISATION DANS GITSCRUM :
─────────────────────────────────────
Sprint 5
┌─────────────────────────────────────┐
│ │
│ Équipe Plateforme │
│ ┌────────────┐ │
│ │ Endpoint │ ──────────┐ │
│ │ API v2 │ │ │
│ └────────────┘ │ Bloque │
│ ▼ │
│ Équipe Frontend │ │
│ ┌────────────┐ ┌──────┴─────┐ │
│ │ Page │ │ Widget │ │
│ │ Paramètres │ │ Dashboard │ │
│ └────────────┘ └────────────┘ │
│ │ Dép. souple │ │
│ ▼ │ │
│ ┌─────────────────────────┴───┐ │
│ │ Fenêtre Tests Intégration │ │
│ │ Jours 8-10 du sprint │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────┘
Implémentation dans GitScrum
CONFIGURER L'ALIGNEMENT INTER-ÉQUIPES
═════════════════════════════════════
ÉTAPE 1 : STRUCTURE DES PROJETS
─────────────────────────────────────
Niveau Organisation :
├── Produit (parapluie)
│ ├── Équipe Plateforme (projet)
│ ├── Équipe Frontend (projet)
│ ├── Équipe Mobile (projet)
│ └── Coordination Release (projet)
Chaque projet d'équipe contient :
├── Tableaux de sprint propres
├── Labels spécifiques à l'équipe
├── Backlog de l'équipe
└── Suivi de la vélocité
ÉTAPE 2 : LABELS INTER-PROJETS
─────────────────────────────────────
Labels partagés entre tous les projets :
Labels de release :
├── 🚀 v2.5-release
├── 🚀 v2.6-release
└── 🚀 v3.0-release
Labels de dépendance :
├── ⛓️ a-dependance
├── ⛓️ bloque-autre
├── 🔴 bloqueur-inter-equipes
└── 🟡 integration-necessaire
Labels de priorité :
├── 🔥 p0-chemin-critique
├── ⚡ p1-important
└── 📋 p2-normal
ÉTAPE 3 : LIAISON DES DÉPENDANCES
─────────────────────────────────────
Tâche → Détails → Tâches Liées
Créer des relations :
├── "Bloqué par" → Dépendance dure
├── "Bloque" → Ce que cela permet
├── "Lié à" → Dépendance souple
└── "Doublon de" → Même travail
Exemple :
┌────────────────────────────────────────┐
│ Tâche : Widget Dashboard │
│ │
│ Tâches Liées : │
│ ├── Bloqué par : Endpoint API (#234) │
│ ├── Bloque : Suite Tests E2E (#567) │
│ └── Lié à : Page Paramètres (#345) │
└────────────────────────────────────────┘
ÉTAPE 4 : SUIVI DES JALONS
─────────────────────────────────────
Créer des jalons de release :
Jalon : Release v2.5
├── Date cible : 15 mars
├── Date limite : 10 mars
├── Équipes : Plateforme, Frontend, Mobile
│
└── Tâches incluses :
├── [Plateforme] Endpoint API v2
├── [Plateforme] Mise à jour Auth
├── [Frontend] Widget Dashboard
├── [Frontend] Page Paramètres
├── [Mobile] Intégration iOS
└── [Mobile] Intégration Android
ÉTAPE 5 : ROUTAGE DES NOTIFICATIONS
─────────────────────────────────────
Intégrations → Slack/Teams
Canaux :
├── #release-v25 → Toutes tâches v2.5
├── #sync-plateforme-frontend → Dépendances
├── #bloqueurs → Bloqueurs inter-équipes
└── #train-release → Rappels de limite
Règles d'automatisation :
├── Label "bloqueur-inter-equipes" → Notifier #bloqueurs
├── Jalon modifié → Notifier #train-release
├── Dépendance débloquée → Notifier propriétaire tâche
└── 3 jours avant limite → Rappel à tous
Flux de coordination de release
PROCESSUS DE TRAIN DE RELEASE
═════════════════════════════
CHRONOLOGIE (CYCLE 4 SEMAINES) :
─────────────────────────────────────
Semaine 1 : PLANIFICATION
─────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ Jour 1 : Réunion de planification de release │
│ ├── Revoir les éléments pour ce train │
│ ├── Identifier les dépendances inter-équipes │
│ ├── Assigner la propriété des points d'intégration │
│ └── Établir les engagements de date limite │
│ │
│ Jours 2-5 : Planification de sprint par équipe │
│ ├── Décomposer en tâches de sprint │
│ ├── Ajouter les liens de dépendance │
│ ├── Étiqueter avec le jalon de release │
│ └── Estimer avec marge pour dépendances │
└─────────────────────────────────────────────────────────────┘
Semaines 2-3 : EXÉCUTION
────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ Quotidien : Standups async │
│ ├── Progression sur éléments du chemin critique │
│ ├── Escalade des bloqueurs │
│ └── Mises à jour de statut des dépendances │
│ │
│ Hebdomadaire : Sync inter-équipes (30 min) │
│ ├── Point sur les dépendances │
│ ├── Identification des risques │
│ ├── Ajustement du périmètre si nécessaire │
│ └── Coordination des tests d'intégration │
└─────────────────────────────────────────────────────────────┘
Semaine 4 : INTÉGRATION & RELEASE
─────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ Jours 1-3 : Gel des fonctionnalités │
│ ├── Code complet pour toutes les équipes │
│ ├── Début des tests d'intégration │
│ └── Corrections de bugs uniquement │
│ │
│ Jours 4-5 : Stabilisation │
│ ├── Corrections de bugs critiques │
│ ├── Tests de performance │
│ └── Finalisation des notes de release │
│ │
│ Jour 5 : Release │
│ ├── Déploiement progressif │
│ ├── Surveillance │
│ └── Plan de rollback prêt │
└─────────────────────────────────────────────────────────────┘
Tableau de bord de visibilité inter-équipes
TABLEAU DE BORD D'ALIGNEMENT DE LIVRAISON
═════════════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ Release v2.5 - Cible : 15 Mars │
│ Limite : 10 Mars (5 jours restants) │
├─────────────────────────────────────────────────────────────┤
│ │
│ PROGRESSION PAR ÉQUIPE │
│ ───────────────────────────────────── │
│ Plateforme : ████████████████████░░░░ 85% 🟢 Dans temps │
│ Frontend : ██████████████████░░░░░░ 75% 🟡 À risque │
│ Mobile : ████████████████████████ 100% ✅ Terminé │
│ │
│ ÉLÉMENTS DU CHEMIN CRITIQUE │
│ ───────────────────────────────────── │
│ ✅ Endpoint API v2 (Plateforme) Terminé │
│ ✅ Mise à jour Auth (Plateforme) Terminé │
│ 🔄 Widget Dashboard (Frontend) En Cours │
│ └── Débloqué il y a 2 jours │
│ ⏳ Migration Paramètres (Frontend) Non Commencé │
│ └── Bloqué par : Widget Dashboard │
│ │
│ BLOQUEURS ACTIFS │
│ ───────────────────────────────────── │
│ 🔴 Migration Paramètres bloquée par Widget Dashboard │
│ └── Propriétaire : @sarah (Frontend) │
│ └── ETA : 8 Mars │
│ │
│ TESTS D'INTÉGRATION │
│ ───────────────────────────────────── │
│ Fenêtre : 11-14 Mars │
│ Propriétaire : Équipe QA │
│ Statut : Planifié │
│ │
└─────────────────────────────────────────────────────────────┘
Bonnes pratiques
- Synchroniser les cadences - Sprints alignés simplifient la coordination
- Dépendances explicites - Lier les tâches bloquantes dans l'outil
- Tableaux de bord visuels - Visibilité inter-équipes réduit les surprises
- Syncs réguliers - Check-ins hebdomadaires détectent les problèmes tôt
- Marges avant limite - Laisser du temps entre limite et release
- Fenêtres d'intégration - Planifier du temps dédié aux tests
- Chemins d'escalade - Processus clair pour résoudre les bloqueurs
- Rétrospectives de release - Apprendre des problèmes de coordination