Gérer les Dépendances Entre Équipes de Développement

Les projets multi-équipes échouent quand les dépendances ne sont pas gérées correctement. Une équipe attend pendant qu'une autre termine, les deadlines glissent et la frustration monte. GitScrum fournit le suivi des dépendances, la visibilité cross-équipe et les outils de coordination qui aident à identifier les bloqueurs tôt, planifier les séquences de travail intelligemment et maintenir la vélocité même avec des relations inter-équipes complexes.

Le Problème de Dépendances Cross-Équipe

Les dépendances non gérées causent:

• Travail bloqué — Équipes inactives attendant d'autres équipes
• Goulots d'étranglement cachés — Dépendances découvertes trop tard
• Retards en cascade — Un glissement affecte plusieurs équipes
• Effort dupliqué — Équipes construisent solutions similaires indépendamment
• Cauchemars d'intégration — Implémentations incompatibles
• Jeu de blâme — Pointer du doigt quand les choses vont mal

Gestion des Dépendances GitScrum

Outils pour coordination cross-équipe:

Fonctionnalités de Dépendances

Types de Dépendances et Cartographie

Comprendre les Types de Dépendances

Classifications de Dépendances:

1. FINISH-TO-START (FS) - Plus Courant
   ────────────────────────────────────
   Équipe A doit TERMINER avant que Équipe B puisse DÉMARRER
   
   Exemple:
   [Équipe API: Construire Endpoints Auth] ──FS──→ [Frontend: Implémenter Login]
   
   Frontend ne peut pas commencer login tant que endpoints API n'existent pas

2. START-TO-START (SS)
   ─────────────────────
   Équipe B peut DÉMARRER quand Équipe A DÉMARRE
   
   Exemple:
   [Backend: Démarrer Schéma BD] ──SS──→ [Frontend: Démarrer Maquettes]
   
   Les deux peuvent commencer en parallèle une fois exigences claires

3. FINISH-TO-FINISH (FF)
   ──────────────────────
   Équipe B doit TERMINER quand Équipe A TERMINE
   
   Exemple:
   [Feature Dev: Compléter Features] ──FF──→ [QA: Compléter Testing]
   
   Testing termine quand toutes features testées

4. START-TO-FINISH (SF) - Rare
   ────────────────────────────
   Équipe B ne peut pas TERMINER tant que Équipe A n'a pas DÉMARRÉ
   
   Exemple:
   [Nouveau Système: Go Live] ──SF──→ [Ancien Système: Démanteler]
   
   Ne peut pas démanteler ancien tant que nouveau n'a pas démarré

Matrice de Dépendances

Créer une Matrice de Dépendances:

Dépendances Équipe pour Release Q4:
───────────────────────────────────

          │ Platform │ API    │ Frontend │ Mobile  │ QA
──────────┼──────────┼────────┼──────────┼─────────┼────────
Platform  │    -     │ FS(2)  │ SS(1)    │ SS(1)   │ FF(0)
API       │    -     │   -    │ FS(3)    │ FS(3)   │ FS(1)
Frontend  │    -     │   -    │    -     │ SS(0)   │ FS(2)
Mobile    │    -     │   -    │    -     │    -    │ FS(2)
QA        │    -     │   -    │    -     │    -    │   -

Légende:
├── FS(n) = Finish-to-Start, n jours de décalage
├── SS(n) = Start-to-Start, n jours de décalage
├── FF(n) = Finish-to-Finish, n jours de décalage
└── - = Pas de dépendance

Lecture: Ligne dépend de Colonne
Exemple: Ligne API, Colonne Platform = FS(2)
         API dépend de Platform qui termine, 2 jours décalage

Dépendances Critiques (surveiller de près):
├── Platform → API (2 jours décalage)
├── API → Frontend (3 jours décalage)
├── API → Mobile (3 jours décalage)
└── Frontend → QA (2 jours décalage)

Visibilité Cross-Équipe

Dashboard Multi-Projet

Dashboard Dépendances Cross-Équipe:

Aperçu Statut Sprint 15:
────────────────────────

Équipe Platform        Équipe API             Équipe Frontend
─────────────────      ──────────────         ─────────────────
[■■■■■■■■░░] 80%       [■■■■■■░░░░] 60%       [■■■■░░░░░░] 40%
                              │                      │
                              ├──────────────────────┘
                              ↓
                       En attente API-234 ⚠️

Travail Bloqué:
┌────────────────────────────────────────────────────────────┐
│ BLOQUEURS (3 items affectant 2 équipes)                    │
├────────────────────────────────────────────────────────────┤
│ 🔴 API-234: Auth token refresh                             │
│    └── Bloque: FE-156, FE-157, MOB-089                     │
│    └── Owner: @alice (Équipe API)                          │
│    └── Jours bloqué: 3                                     │
│                                                            │
│ 🟡 PLAT-156: Migration base de données                     │
│    └── Bloque: API-240, API-241                            │
│    └── Owner: @bob (Équipe Platform)                       │
│    └── Jours bloqué: 1                                     │
└────────────────────────────────────────────────────────────┘

Dépendances Prochaines (5 prochains jours):
├── Jour 1: PLAT-160 nécessaire pour API-245
├── Jour 2: API-238 nécessaire pour FE-165
├── Jour 3: API-239 nécessaire pour MOB-092
├── Jour 4: FE-168 nécessaire pour QA-200
└── Jour 5: Specs design nécessaires pour FE-170

Gestion des Bloqueurs

Workflow Bloqueurs

Cycle de Vie du Bloqueur:

1. IDENTIFICATION
   ───────────────
   Développeur découvre dépendance pas prête:
   ├── Marquer tâche comme "Bloquée"
   ├── Lier à la tâche bloquante
   ├── Ajouter label bloqueur
   ├── Notifier équipe bloquante
   └── Documenter dans notes de tâche
   
   Auto-Actions GitScrum:
   ├── Carte tâche devient rouge/orange
   ├── Bloqueur ajouté à vue cross-équipe
   └── Notification Slack à équipe bloquante

2. ESCALADE (si non résolu >24h)
   ─────────────────────────────
   ├── Auto-escalader aux leads équipe
   ├── Ajouter à agenda standup quotidien
   ├── Déclencher workflow d'escalade
   └── Créer réunion résolution dépendances si nécessaire

3. RÉSOLUTION
   ───────────
   Équipe bloquante complète travail:
   ├── Marquer tâche bloquante comme complète
   ├── GitScrum auto-notifie tâches bloquées
   ├── Équipe bloquée tire tâche du backlog
   └── Métriques suivent temps résolution

4. REVUE
   ──────
   Revue hebdomadaire dépendances:
   ├── Analyser bloqueurs résolus
   ├── Identifier patterns
   ├── Améliorer processus
   └── Mettre à jour cartes dépendances

Patterns de Coordination

Protocoles de Transfert

Processus Transfert Équipe-à-Équipe:

CHECKLIST TRANSFERT
───────────────────

Équipe qui Fournit (ex., Équipe API):
├── □ Travail complété et testé
├── □ Documentation mise à jour
│   ├── Documentation API
│   ├── Exemples d'utilisation
│   └── Limitations connues
├── □ Environnement prêt
│   ├── Déployé en staging
│   ├── Feature flags configurés
│   └── Données test disponibles
├── □ Communication
│   ├── Notifier équipe réceptrice
│   ├── Planifier sync si nécessaire
│   └── Mettre à jour statut tâche dans GitScrum
└── □ Engagement support
    ├── Disponible pour questions
    ├── Temps réponse rapide convenu
    └── Chemin escalade documenté

Équipe qui Reçoit (ex., Équipe Frontend):
├── □ Vérifier transfert complet
├── □ Tester intégration
│   ├── Smoke test endpoints API
│   ├── Vérifier formats données
│   └── Vérifier gestion erreurs
├── □ Commencer travail dépendant
├── □ Fournir feedback
│   ├── Issues trouvés
│   ├── Items manquants
│   └── Suggestions
└── □ Mettre à jour liens tâches dans GitScrum

Synchronisation Jalons

Jalons Alignés

Planification Jalons Cross-Équipe:

Carte Jalons Release Q1:
────────────────────────

Semaine 1 (Jan 1-5)
├── Platform: Schéma BD finalisé
├── Design: Toutes maquettes livrées
└── Dépendances: Aucune (démarrage parallèle)

Semaine 2 (Jan 8-12)
├── API: Endpoints core prêts
├── Platform: Infrastructure complète
└── Dépendances: Platform → API

Semaine 3 (Jan 15-19)
├── Frontend: Composants UI core
├── Mobile: Écrans core
└── Dépendances: API → Frontend, API → Mobile

Semaine 4 (Jan 22-26)
├── Frontend: Intégration complète
├── Mobile: Intégration complète
└── Dépendances: Frontend ∥ Mobile (parallèle)

Semaine 5 (Jan 29 - Fév 2)
├── QA: Testing complet
├── Tous: Correction bugs
└── Dépendances: Frontend → QA, Mobile → QA

Semaine 6 (Fév 5-9)
├── Tous: Prep release
└── Date release: Fév 9

Workflows Communication

Standup Cross-Équipe

Format Standup Multi-Équipe:

Quand: Mardi/Jeudi, 15 minutes
Qui: Un représentant de chaque équipe
But: Faire surface dépendances et bloqueurs cross-équipe

Format:
───────

1. Tour de Table (8 min)
   Chaque rep répond:
   ├── "Nous fournissons [X] à [Équipe] pour [date]"
   ├── "Nous attendons [Y] de [Équipe]"
   └── "Nous avons [bloqueurs/pas bloqueurs] à rapporter"

2. Deep-Dive Bloqueurs (5 min)
   ├── Top 2-3 bloqueurs par impact
   ├── Owner s'engage sur date résolution
   └── Escalade si nécessaire

3. Regard Avant (2 min)
   ├── Dépendances dues dans 3 prochains jours
   └── Avertissement besoins prochains

Meilleures Pratiques

Pour Contributeurs Individuels

1. Lier tôt — Ajouter dépendances en créant tâches
2. Communiquer proactivement — Alerter bloqueurs avant qu'ils deviennent critiques
3. Documenter transferts — Rendre transitions fluides
4. Assister au sync cross-équipe — Rester informé
5. Mettre à jour statut quotidiennement — Garder info dépendances à jour

Pour Leads Équipe

1. Cartographier dépendances hebdomadairement — Maintenir vue actuelle
2. Buffer pour incertitude — Planifier marge dans calendriers
3. Escalader tôt — Ne pas laisser bloqueurs pourrir
4. Construire relations — Confiance cross-équipe accélère résolution
5. Revoir patterns — Identifier issues dépendances récurrents

Pour Program Managers

1. Créer culture dépendances — Rendre suivi normal
2. Fournir outils — S'assurer GitScrum configuré correctement
3. Exécuter cérémonies cross-équipe — Faciliter coordination
4. Suivre métriques — Mesurer santé dépendances
5. Supprimer bloqueurs systémiques — Adresser issues organisationnels

Solutions Connexes

• Configurer visibilité cross-projet dans GitScrum
• Gérer dépendances jalons
• Coordonner équipes développement frontend et backend