What is Le Problème des Interruptions?

Les urgences non gérées détruisent la productivité: - Échec du sprint — Impossible de compléter le travail planifié - Changement de contexte — Les développeurs perdent leur flux constamment - Effondrement des estimations — Les plans perdent leur sens - Épuisement de l'équipe — La lutte constante contre les incendies épuise

What is Fonctionnalités Clés?

Gérez les demandes urgentes et le travail non planifié dans GitScrum sans perturber les engagements de sprint en utilisant une capacité tampon, des voies d'interruption et des politiques d'escalade claires.

What is Planification de Capacité Tampon?

Gérez les demandes urgentes et le travail non planifié dans GitScrum sans perturber les engagements de sprint en utilisant une capacité tampon, des voies d'interruption et des politiques d'escalade claires.

Gérer les Demandes Urgentes Sans Faire Dérailler les Sprints

Chaque sprint fait face à des demandes urgentes inattendues qui menacent le travail planifié. GitScrum fournit des mécanismes de gestion des interruptions incluant la planification de capacité tampon, des voies d'interruption dédiées et des workflows d'escalade.

Le Problème des Interruptions

Les urgences non gérées détruisent la productivité:

Échec du sprint — Impossible de compléter le travail planifié
Changement de contexte — Les développeurs perdent leur flux constamment
Effondrement des estimations — Les plans perdent leur sens
Épuisement de l'équipe — La lutte constante contre les incendies épuise
Fausses urgences — Tout devient "urgent"
Pas de prévisibilité — Les stakeholders perdent confiance dans la livraison

Solution de Gestion des Interruptions GitScrum

Construisez des systèmes qui absorbent le travail inattendu:

Fonctionnalités Clés

Fonctionnalité	Usage Interruption
Capacité tampon	Réserver capacité sprint pour les inconnues
Voies d'interruption	Colonnes dédiées du board pour travail urgent
Limites WIP	Prévenir surcharge pendant interruptions
Labels/priorités	Classification claire d'urgence
Automatisations	Router travail urgent de façon appropriée

Planification de Capacité Tampon

Structure de Capacité du Sprint

Planification de Capacité du Sprint:

Capacité Totale Disponible: 100 story points

Allocation:
├── Travail Engagé du Sprint: 75 pts (75%)
│   └── Features et améliorations planifiées
├── Tampon pour Interruptions: 15 pts (15%)
│   └── Demandes urgentes attendues, bugs, support
└── Slack/Apprentissage: 10 pts (10%)
    └── Dette technique, exploration, formation

Guide de Planification du Sprint:
"Ne pas engager plus de 75 points. 
Réserver 15 points pour interruptions attendues.
Si les interruptions dépassent le tampon, abandonner 
les items engagés de plus basse priorité."

Dimensionnement du Tampon par Historique d'Équipe

Analyse des Interruptions: 6 Derniers Sprints

Sprint    │ Interruptions │ Points │ % de Capacité
──────────┼───────────────┼────────┼──────────────
Sprint 18 │ 4 items       │ 12 pts │ 12%
Sprint 17 │ 7 items       │ 18 pts │ 18%  ← Incident majeur
Sprint 16 │ 3 items       │ 8 pts  │ 8%
Sprint 15 │ 5 items       │ 14 pts │ 14%
Sprint 14 │ 4 items       │ 11 pts │ 11%
Sprint 13 │ 3 items       │ 9 pts  │ 9%

Moyenne: 12 pts par sprint (12%)
Tampon recommandé: 15 pts (fournit une marge)

Ajuster si:
├── Sprint à hautes interruptions → Augmenter tampon
├── Sprint à basses interruptions → Garder tampon, utiliser pour dette
└── Pattern consistant → Considérer allocation permanente

Voie d'Interruption sur le Board

Configuration du Board

Kanban Board avec Voie d'Interruption:

┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│ Backlog     │ INTERRUPTION│ En Cours    │ Review      │ Terminé     │
│             │ 🔴          │             │             │             │
├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤
│ Travail     │ URGENT: Fix │ Feature A   │ Feature B   │ Feature C   │
│ sprint      │ bug paiement│ (planifiée) │ (planifiée) │ (planifiée) │
│ planifié    │             │             │             │             │
│ Feature D   │             │ INTERRUPTION│             │ INTERRUPTION│
│ Feature E   │             │ Patch       │             │ Hotfix      │
│             │             │ sécurité    │             │ déployé     │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

Limite WIP: 2 (colonne Interruption)
Règle: Travail d'interruption obtient développeur dédié
Visualisation: Couleur/label différent

Classification des Interruptions

Système de Classification d'Urgence:

🔴 P0 - Critique (< 1 heure de réponse)
├── Production en panne
├── Brèche de sécurité active
├── Perte de données en cours
├── Système de paiement cassé
└── Action: Tout le monde, tout lâcher

🟠 P1 - Haut (< 4 heures de réponse)
├── Feature majeure cassée pour beaucoup d'utilisateurs
├── Impact significatif sur les revenus
├── Escalade client importante
└── Action: Gestionnaire d'interruptions désigné

🟡 P2 - Moyen (dans le sprint)
├── Feature cassée pour certains utilisateurs
├── Contournement existe
├── Demande client avec deadline
└── Action: Ajouter au sprint si tampon permet

🟢 P3 - Bas (prochain sprint)
├── Issues mineurs
├── Demandes nice-to-have
├── Améliorations générales
└── Action: Backlog pour priorisation

Rôle du Gestionnaire d'Interruptions

Rotation du Devoir d'Interruptions

Rotation Hebdomadaire d'Interruptions:

Semaine 1: @alice (principal), @bob (backup)
Semaine 2: @bob (principal), @carol (backup)  
Semaine 3: @carol (principal), @dave (backup)
Semaine 4: @dave (principal), @alice (backup)

Responsabilités du Gestionnaire d'Interruptions:
├── Surveiller canal #support-engineering
├── Triage des demandes urgentes entrantes
├── Gérer P0/P1 immédiatement
├── Protéger reste de l'équipe des interruptions
├── Documenter patterns d'interruption
└── Capacité sprint: 50% (travail planifié)

Avantages:
├── Une personne change de contexte (pas toute l'équipe)
├── Rotation équitable de la charge d'interruptions
├── Temps protégé pour travail concentré
└── Propriété claire des issues urgents

Allocation Sprint du Gestionnaire

Semaine du Gestionnaire d'Interruptions:

@alice Allocation Sprint 19:
├── Travail engagé du sprint: 0 pts
│   └── Pas assigné au travail planifié
├── Capacité d'interruption: 50% (~20 hrs)
│   └── Gérer toutes les demandes urgentes
├── Support/documentation: 30% (~12 hrs)
│   └── Écrire runbooks, améliorer docs
└── Flexible: 20% (~8 hrs)
    └── Dette technique, apprentissage, aider l'équipe

Si pas d'interruptions:
├── Travailler sur backlog dette technique
├── Améliorer monitoring/alertes
├── Écrire documentation
└── Pair programming avec l'équipe sur travail complexe

Politiques d'Escalade

Chemin d'Escalade Clair

Matrice d'Escalade:

Issue arrive via:
├── Slack #support → Trié par équipe support
├── PagerDuty → Va à l'ingénieur d'astreinte
├── Email client → Account manager évalue
└── Demande interne → Demandeur crée ticket

Flux d'Escalade:
1. Support crée ticket avec évaluation urgence
2. Gestionnaire d'interruptions revoit dans le SLA:
   ├── P0: Immédiatement (< 15 min)
   ├── P1: < 1 heure
   ├── P2: < 4 heures
   └── P3: Jour ouvrable suivant
3. Gestionnaire confirme ou ajuste priorité
4. Gestionnaire assigne ou ajoute au sprint
5. Résolution suivie dans le ticket

Règles d'Auto-Escalade:
├── P0 non acquitté > 15 min → Pager backup
├── P1 non acquitté > 1 hr → Pager backup + manager
└── Tout issue ouvert > SLA → Notifier manager

Communication avec Stakeholders

Template de Demande d'Interruption:

Lors de demande de travail urgent:

Sujet: [URGENT P1] Paiements échouent pour comptes enterprise

Ce qui se passe:
Clients enterprise voient erreurs paiement depuis 14h

Impact:
- ~50 clients affectés
- $20K revenus potentiels à risque
- 3 plaintes clients reçues

Contournement:
Traitement manuel paiement disponible (lent)

Action demandée:
Corriger intégration paiement dans 4 heures

Demandé par: @sarah (Account Manager)
Manager approbateur: @mike (VP Ventes)

---

Réponse de l'Engineering:

Acquitté: 14:15 par @alice
Statut actuel: Investigation
ETA: Diagnostic dans 30 min, correction dans 2 hrs
Mises à jour: Toutes les 30 minutes dans #incident-payment

Gérer l'Impact sur le Sprint

Quand le Tampon Est Dépassé

Protocole Tampon Dépassé:

Situation: 20 pts d'interruptions, 15 pts de tampon

Options:
1. Étendre travail du sprint → Risque burnout, problèmes qualité
2. Abandonner items basse priorité → Maintenir durabilité
3. Demander aide supplémentaire → Si disponible
4. Négocier scope → Réduire scope interruption si possible

Cadre de Décision:
├── Peut-on réduire le scope d'interruption? → Essayer d'abord
├── Les heures sup sont-elles durables (rare)? → Court terme seulement
├── Que peut-on abandonner? → Discuter avec PO
└── A-t-on besoin d'aide? → Escalader au management

Communication aux Stakeholders:
"Nous avons reçu 33% plus de demandes urgentes que prévu.
Pour maintenir la qualité, nous reportons Feature E au 
prochain sprint. Tous les items urgents seront résolus."

Ajustements du Sprint

Réunion d'Ajustement Mi-Sprint:

Quand: Tampon dépassé de 50%+
Qui: Scrum Master, Product Owner, Team Lead

Agenda:
1. Revoir volume et impact des interruptions
2. Évaluer capacité restante du sprint
3. Décider quoi reporter
4. Communiquer aux stakeholders
5. Documenter pour rétrospective

Exemple de Décision:
Correction Mi-Parcours Sprint 19:
├── Engagement original: 75 pts
├── Interruptions reçues: 22 pts (au-dessus de 15 pts tampon)
├── Capacité ajustée: 75 - 7 = 68 pts
├── Reporté: Feature E (8 pts) → Sprint 20
└── Nouvel engagement: 67 pts (atteignable)

Notification stakeholders envoyée ✓

Prévenir les Fausses Urgences

Validation d'Urgence

Avant d'Accepter P0/P1:

Checklist de Validation:
□ La production est-elle vraiment impactée?
□ Combien d'utilisateurs affectés?
□ Quel est l'impact business ($$)?
□ Y a-t-il un contournement?
□ Peut-il attendre demain?
□ Qui a approuvé la priorité?

Drapeaux Rouges (probablement pas urgent):
├── "Le client est mécontent" (sans impact production)
├── "Nous avions promis cette feature" (pas urgent, mauvaise planification)
├── "C'est cassé depuis des semaines" (pas soudainement urgent)
├── "J'en ai besoin pour une démo" (urgence personnelle, pas business)
└── Pas d'approbation manager sur la priorité

Réponse:
"Je comprends que c'est important. Basé sur nos 
critères, c'est un P2 (Moyen). Il sera traité dans 
ce sprint. Si vous pensez que c'est vraiment P0/P1, 
merci d'obtenir l'approbation du VP."

Suivre les Patterns d'Urgence

Rapport Mensuel d'Interruptions:

Total Interruptions: 24
Par Priorité:
├── P0 Critique: 2 (8%)
├── P1 Haut: 6 (25%)
├── P2 Moyen: 10 (42%)
└── P3 Bas: 6 (25%) ← Ne devraient pas être des interruptions

Par Source:
├── Rapports clients: 10 (42%)
├── Demandes internes: 8 (33%)
├── Alertes monitoring: 4 (17%)
└── Escalades ventes: 2 (8%)

Par Catégorie:
├── Bugs: 12 (50%)
├── Demandes features: 6 (25%)
├── Questions support: 4 (17%)
└── Sécurité: 2 (8%)

Insights:
├── 25% des demandes "urgentes" n'étaient pas urgentes
├── 50% sont des bugs → Besoin meilleur QA
├── Même système a causé 4 incidents → Besoin refactor

Actions:
├── Resserrer critères acceptation P3
├── Investir dans stabilité système paiement
└── Ajouter monitoring pour top catégories incidents

Intégration Standup d'Équipe

Statut Interruptions dans Standup

Standup Quotidien avec Interruptions:

@alice (Gestionnaire d'Interruptions):
"Gère: 2 interruptions actives
- P1 Bug paiement: 60% fait, ETA 14h
- P2 Issue export: En file, commence après P1
Tampon utilisé: 8/15 points
Statut tampon: Sain ✓"

@bob:
"Feature A: Sur la bonne voie, pas de blocage
Ne prend pas d'interruptions cette semaine"

@carol:
"Feature B: En review
Heads up: Pourrait avoir besoin d'aide si plus de P1s arrivent"

Scrum Master note:
├── Tampon sain, sprint sur la bonne voie
├── Surveiller progression bug paiement
└── Carol marquée comme backup si nécessaire

Rétrospective Interruptions

Rétrospective Sprint: Analyse Interruptions

Ce Qui S'Est Passé:
├── 4 interruptions P1 (au-dessus de la moyenne)
├── 1 incident P0 (panne production)
├── Tampon dépassé de 5 points
├── 1 feature reportée au prochain sprint

Ce Qui a Bien Marché:
├── Rôle gestionnaire interruptions a protégé l'équipe
├── P0 résolu en 45 minutes
├── Escalade claire a fonctionné
└── Stakeholders ont compris le report

À Améliorer:
├── 2 P1s étaient en fait P2 (sur-escaladés)
├── Pas de runbook pour issues paiement → En créer un
├── Monitoring n'a pas détecté issue tôt → Améliorer
└── Tampon était trop petit → Augmenter à 18 pts

Items d'Action:
├── [ ] Créer runbook système paiement
├── [ ] Ajouter monitoring pour gateway paiement
├── [ ] Revoir critères urgence avec ventes
└── [ ] Augmenter tampon à 18 pts prochain sprint

Meilleures Pratiques

Pour les Équipes

Protéger le tampon — Ne pas sur-engager travail planifié
Rotation équitable — Partager charge d'interruptions
Documenter interruptions — Les patterns informent améliorations
Dire non de façon appropriée — Pas tout n'est urgent
Améliorer systèmes — Réduire interruptions futures