7 min lecture • Guide 671 of 877
Implémenter Kanban pour les Équipes de Développement
Kanban fournit un framework flexible pour gérer le travail de développement avec un minimum de surcharge processuelle. Les tableaux Kanban de GitScrum aident les équipes à visualiser leur workflow, identifier les goulots d'étranglement et améliorer continuellement leur processus grâce à l'optimisation du flux.
Fondamentaux Kanban
Principes Fondamentaux
PRINCIPES KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. VISUALISER LE TRAVAIL │
│ Rendre tout le travail visible sur le tableau │
│ Inclure type de travail, statut, blocages │
│ │
│ 2. LIMITER LE TRAVAIL EN COURS (WIP) │
│ Se concentrer sur finir, pas commencer │
│ Les limites WIP créent le flux │
│ │
│ 3. GÉRER LE FLUX │
│ Optimiser pour une livraison fluide et prévisible │
│ Mesurer et améliorer le cycle time │
│ │
│ 4. RENDRE LES POLITIQUES EXPLICITES │
│ Documenter comment le travail traverse les colonnes │
│ Définir "prêt" et "fait" pour chaque étape │
│ │
│ 5. IMPLÉMENTER DES BOUCLES DE FEEDBACK │
│ Revues régulières du travail et du processus │
│ Adapter selon les métriques et l'expérience │
│ │
│ 6. AMÉLIORER COLLABORATIVEMENT │
│ L'équipe possède le processus │
│ Changement continu et évolutif │
└─────────────────────────────────────────────────────────────┘
Kanban vs Scrum
CARACTÉRISTIQUES KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ KANBAN: SCRUM: │
│ • Flux continu • Sprints time-boxés │
│ • Limites WIP • Engagement de sprint │
│ • Basé sur le pull • Push au sprint planning │
│ • Changement à tout moment • Changement entre sprints │
│ • Rôles optionnels • Rôles définis │
│ • Métrique: cycle time • Métrique: vélocité │
│ │
│ CHOISIR KANBAN QUAND: │
│ • Travail imprévisible (support, ops) │
│ • Déploiement continu nécessaire │
│ • Équipe gère des types de travail variés │
│ • Changements de priorité fréquents │
│ • Minimum de surcharge processuelle préféré │
│ │
│ CHOISIR SCRUM QUAND: │
│ • Travail planifiable │
│ • Équipe a besoin de structure │
│ • Stakeholders veulent des engagements prévisibles │
│ • Construction de fonctionnalités complexes itérativement │
└─────────────────────────────────────────────────────────────┘
Configuration du Tableau Kanban
Structure de Base
TABLEAU KANBAN DÉVELOPPEMENT:
┌─────────────────────────────────────────────────────────────────────┐
│ Backlog │ À Faire │ En Dev │ Revue │ Test │ Déployer │ Fait │
│ │ (3) │ (4) │ (2) │ (2) │ (1) │ │
├─────────────────────────────────────────────────────────────────────┤
│ │ │ │ │ │ │ │
│ [Story1] │ [Task1] │ [Task4] │[Task7]│[Task9]│ [Task10] │[Done1]│
│ [Story2] │ [Task2] │ [Task5] │[Task8]│ │ │[Done2]│
│ [Story3] │ [Task3] │ [Task6] │ │ │ │[Done3]│
│ [Story4] │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
└─────────────────────────────────────────────────────────────────────┘
↓ ↓ ↓ ↓ ↓ ↓
Non limité WIP: 3 WIP: 4 WIP: 2 WIP: 2 WIP: 1
Colonnes et Politiques
DÉFINITION DES COLONNES:
═════════════════════════
BACKLOG:
├── Critères d'entrée: User story validée
├── Limites WIP: Non (file illimitée)
└── Qui peut ajouter: Product Owner
À FAIRE:
├── Critères d'entrée: Priorisé pour itération courante
├── Limites WIP: 3 tâches
└── Politique: Prendre la tâche du haut
EN DÉVELOPPEMENT:
├── Critères d'entrée: Développeur assigné
├── Limites WIP: 4 tâches (2 par dev max)
└── Politique: Une tâche à la fois par personne
REVUE DE CODE:
├── Critères d'entrée: Code complet, tests passent
├── Limites WIP: 2 tâches
└── Politique: Review dans les 24h
TEST:
├── Critères d'entrée: Revue approuvée
├── Limites WIP: 2 tâches
└── Politique: Tests automatisés + manuel si besoin
DÉPLOYER:
├── Critères d'entrée: Tests validés
├── Limites WIP: 1 tâche
└── Politique: Déploiement quotidien
FAIT:
├── Critères d'entrée: En production, vérifié
├── Limites WIP: Non
└── Archivage automatique après 7 jours
Limites WIP
Calcul des Limites
DÉTERMINER LES LIMITES WIP:
═══════════════════════════
FORMULE DE BASE:
WIP Limite = Nombre de personnes × 1.5
EXEMPLE (équipe de 4 devs):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Développement: 4 devs × 1.5 = 6 │
│ (arrondi à 4-6) │
│ │
│ Revue: 2 personnes font les revues = 3 │
│ │
│ Test: 1 testeur = 2 │
│ │
└─────────────────────────────────────────────────────────────┘
AJUSTEMENT:
├── Trop d'attente → Réduire la limite
├── Ressources inactives → Augmenter légèrement
├── Multitâche excessif → Réduire
└── Flux fluide → Maintenir
Appliquer les Limites
GESTION DES VIOLATIONS WIP:
═══════════════════════════
SCÉNARIO: Colonne "Revue" limite = 2, déjà 2 tâches
MAUVAISE PRATIQUE:
├── Ignorer la limite
├── Commencer une nouvelle tâche
└── Résultat: Multitâche, flux bloqué
BONNE PRATIQUE:
├── Aider à finir ce qui est en revue
├── Pair review pour accélérer
├── Résoudre les blocages
└── Résultat: Flux maintenu
SIGNAL VISUEL:
┌────────────────────────────────┐
│ Revue [2/2] ← Plein! │
├────────────────────────────────┤
│ ⚠️ Limite atteinte │
│ [Task7] - Alice │
│ [Task8] - Bob │
└────────────────────────────────┘
Métriques de Flux
Mesures Essentielles
MÉTRIQUES KANBAN:
═════════════════
1. CYCLE TIME:
Temps du "À Faire" au "Fait"
Objectif: Réduire et stabiliser
┌─────────────────────────────────────┐
│ Cette semaine: 3.2 jours │
│ Semaine passée: 4.1 jours │
│ Tendance: ↓ Amélioration │
└─────────────────────────────────────┘
2. LEAD TIME:
Temps du "Backlog" au "Fait"
Inclut le temps d'attente
Important pour les promesses clients
3. THROUGHPUT:
Nombre de tâches complétées par période
┌─────────────────────────────────────┐
│ S1: 12 │ S2: 14 │ S3: 11 │ S4: 15 │
│ Moyenne: 13 tâches/semaine │
└─────────────────────────────────────┘
4. WORK IN PROGRESS:
Nombre de tâches actives maintenant
WIP actuel: 8/12 limite totale
Diagramme de Flux Cumulatif
CUMULATIVE FLOW DIAGRAM:
════════════════════════
Tâches
│
40├─────────────────────────────────────
│ ░░░░░░░░░░░░░░░░ Fait
35├─────────────────░░░░░░░░░░░░░░░░░░░
│ ░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ Test
30├───────────░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
│ ░░▓▓▓████████████████████ Revue
25├───────░░▓▓███████████████████████
│ ░░▓▓█████████████████████████ En Dev
20├────░░▓██████████████████████████▌
│ ░▓████████████████████████████▌
15├──░▓█████████████████████████████▌ À Faire
│ ░▓██████████████████████████████▌
10├░▓███████████████████████████████▌
│▓████████████████████████████████▌
5├█████████████████████████████████▌
│█████████████████████████████████▌
└─────────────────────────────────────
J1 J2 J3 J4 J5 J6 J7 Jours
LECTURE:
├── Bandes régulières = Flux stable
├── Bandes qui s'élargissent = Goulot
├── Pente "Fait" = Throughput
└── Écart horizontal = Cycle Time
Amélioration Continue
Cadence de Revue
RÉUNIONS KANBAN:
════════════════
QUOTIDIEN (15 min):
├── Parcourir le board de droite à gauche
├── Focus sur les blocages
├── "Comment finir ce qui est commencé?"
└── Pas de statuts individuels
BI-HEBDOMADAIRE - Service Delivery Review:
├── Analyser les métriques de flux
├── Tendances cycle time
├── Throughput vs objectifs
└── Ajustements de processus
MENSUEL - Strategy Review:
├── Alignement avec objectifs business
├── Évolution des politiques
├── Investissements amélioration
└── Formation équipe
Expériences d'Amélioration
CYCLE KAIZEN:
═════════════
1. OBSERVER:
Cycle time actuel: 5 jours
Goulot identifié: Revue de code
2. HYPOTHÈSE:
"Si on fait des PR plus petites,
le temps de revue diminuera"
3. EXPÉRIMENTER:
Durée: 2 semaines
Règle: PR < 200 lignes
4. MESURER:
Avant: Temps revue 1.8 jours
Après: Temps revue 0.8 jours ✓
5. STANDARDISER:
Nouvelle politique: PR max 200 lignes
Documenter dans le wiki
Configuration GitScrum
Personnalisation du Board
ÉTAPES CONFIGURATION:
═════════════════════
1. CRÉER LES COLONNES:
GitScrum → Projet → Board → Colonnes
└── Ajouter colonnes selon workflow
2. DÉFINIR LES LIMITES WIP:
Pour chaque colonne:
└── Paramètres → WIP Limit → Définir
3. CONFIGURER LES POLITIQUES:
Colonnes → Règles
├── Critères d'entrée (checklist)
├── Assignation automatique
└── Notifications
4. ACTIVER LES MÉTRIQUES:
Rapports → Flux
├── Cycle Time
├── Cumulative Flow
└── Throughput