Anatomie d'un tableau Kanban

Un tableau Kanban est souvent traité comme une simple grille : des colonnes pour les étapes, des cartes pour les éléments de travail. Mais les tableaux efficaces ont plus de structure que cela.

Les composantes clés :

1. Colonnes — Étapes que le travail traverse
2. Cartes — Éléments de travail individuels
3. Limites de TEC — Nombre maximum d'éléments autorisés par étape
4. Couloirs — Divisions horizontales pour catégoriser le travail
5. Politiques — Règles sur la façon dont le travail se déplace (souvent écrites sur le tableau)
6. Blocages — Indicateurs visuels pour le travail bloqué
7. Files d'attente vs étapes actives — Distinguer l'attente du travail en cours

Explorons chacune de ces composantes en profondeur.

La première règle : les colonnes doivent refléter la façon dont le travail se déplace réellement, et non la façon dont vous souhaiteriez qu'il se déplace.

Erreurs courantes :

• Utiliser des étapes génériques (À faire, En cours, Terminé) qui cachent la complexité
• Cartographier un processus idéalisé que personne ne suit
• Copier le tableau d'une autre équipe sans comprendre votre contexte

La bonne approche :

1. Rassembler l'équipe (tous ceux qui touchent au travail)
2. Retracer des éléments de travail récents : « Qu'est-il arrivé à ceci après sa création ? »
3. Noter chaque étape, y compris les états d'attente
4. Inclure la vérité difficile — si le travail reste en révision pendant des jours, c'est une étape

Exemple d'évolution :

• Avant : À faire → En cours → Terminé
• Après : Backlog → Prêt → Dév (TEC : 3) → Révision de code (TEC : 2) → AQ → Prêt pour déploiement → Déployé

Le tableau élargi révèle où le travail passe réellement du temps. Vous pourriez découvrir que la révision de code prend plus de temps que le développement.

Toutes les étapes ne sont pas identiques. Certaines représentent du travail actif (quelqu'un fait quelque chose). D'autres représentent des files d'attente (le travail attend).

Cette distinction est importante parce que :

• Le temps d'attente domine souvent le délai d'exécution
• Les files d'attente sont l'endroit où le travail meurt
• Vous gérez les files d'attente et les étapes actives différemment

Visualiser la différence :

Plusieurs équipes divisent les colonnes en deux : une zone « en attente » et une zone « en cours ».

| Ready | Development  | Ready for | Code Review | Ready for | Done |
|       | In Progress  | Review    | In Progress | Deploy    |      |

Ou utilisez des points/indicateurs sur les cartes pour montrer « travail actif » vs « en attente ».

La révélation : Si votre colonne « En cours » est remplie de travail que personne ne touche réellement, vous avez des files d'attente cachées. Rendez-les visibles.

Chaque colonne a besoin d'une Définition de terminé (DoD) claire : qu'est-ce qui doit être vrai pour que le travail quitte cette étape ?

Sans critères clairs :

• Le travail se déplace prématurément (« c'est presque terminé »)
• La qualité varie (« terminé » signifie différentes choses pour différentes personnes)
• Les problèmes apparaissent tard (« Je pensais que quelqu'un d'autre ferait ça »)

Exemple de DoD pour « Développement » :

• Tous les critères d'acceptation respectés
• Tests unitaires écrits et réussis
• Le code compile sans avertissements
• Auto-révisé (aucun problème évident)
• Le message de commit suit la convention

Exemple de DoD pour « Révision de code » :

• Deux approbations reçues
• Tous les commentaires de révision traités
• Pipeline CI réussi
• Aucun conflit de fusion

Écrivez-les sur le tableau ou créez un lien vers eux. Ce n'est pas de la bureaucratie — c'est une compréhension partagée.