Kanban Équipes Développement | GitScrum
Implémentez Kanban avec GitScrum. Visualisez travail, limitez WIP et optimisez flux pour livraison continue et efficace.
7 min de lecture
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