Le Kanban Board est une représentation visuelle d’une gestion de flux. Il permet de représenter l’état d’avancement de tâches de façon très simplifiée.
Bien qu’on soit une équipe scrum ou qu’on soit une équipe kanban, ces tableaux sont devenus indispensables ; souvent représentés sur des murs, ceux-ci sont parfois numérisés pour les équipes agiles distribuées.
Si cet article est dédié au management visuel, le kanban est un concept de gestion de flux de travail. Si vous ne connaissez pas ce concept, voici un article qui parle des bases du Kanban :
article : Mieux comprendre le Kanban
D’ailleurs, vous pouvez regarder notre vidéo sur le sujet :
Le tableau de base
Avant de réaliser des boards kanban complexes, il faut juste comprendre les bases ; cependant, rassurez-vous c’est très simple.
Nous commençons par représenter visuellement des colonnes pour chacune des étapes indispensables de travail pour chacune des tâches que l’équipe a.
Prenons une équipe de développement scrum. Celle-ci aura :
- des tâches en attente de développement (todo)
- des tâches en cours de développement (in progress)
- et des tâches terminées (done)
Voilà ce que cela représente sous forme d’un kanban board. En réalité c’est la représentation la plus simple de ce type de tableau.
Kanban board : Faire des sous-colonnes
Le Kanban permet de faire des sous-colonnes de vos colonnes qui permet de faire des séparations visuellement plus simple. Dans ce format, vous pourriez en effet faire deux colonnes ; cependant il est plus simple de visualiser cela avec une sous-colonne.
Voici le résultat d’un board qui propose deux sous-états de l’état « Dev » :
« Dev in progress » et « Dev done »
Nous réalisons souvent ce type de « sous » colonne afin de mieux représenter deux états différents des étapes :
- les tâches prises en charges
- les tâche en attente de prise en charge
Cela simplifie la compréhension globale du board. Sans cette sous-colonne « Dev done », l’équipe devrait mettre la tâche en fin de développement dans « test ». Cependant, comment savoir si cette tâche est en cours de test ou en attente de test ? Avec la sous-colonne « dev done », ce type de question ne se pose plus et tout est plus clair pour ceux qui regarde ce tableau.
Limiter le nombre de demandes par étape
Parfois les équipes se retrouvent vite par avoir des tâches massivement au sein de certaines colonnes. C’est ce qu’on appelle avoir un goulot d’étranglement. Cela est souvent le cas quand les équipes n’ont aucune règle de régulation de flux.
Ainsi les équipes utiliseront le concept de « limit wip » et de « limit wip basse » pour mieux réguler le flux de travail de l’ensemble des tâches. En gros cela signifie :
- qu’on limitera le nombre de tâche au sein d’une étape
- qu’on imposera un minimum de tâches au sein d’une étape
Les équipes utilisent beaucoup plus fréquemment les limit WIP ; on représente celles-ci de façon simplifiée en affichant un numéro de limitation en haut de la colonne concernée.
Plus rarement utilisé et pourtant parfois très efficace, en général nous représentons une limit wip basse par un numéro « vert » et une flèche montante. Cela a pour objectif surtout d’avoir une représentation différente de la limit wip classique.
Kanban board : Séparation de colonnes en ligne
Les tableaux Kanban peuvent vite se complexifier donc attention à ne faire ce type de board uniquement si vous en avez vraiment le besoin. Il est possible de diviser une colonne en plusieurs lignes pour définir différentes sous-étapes réalisables indispensables au sein d’une même étape mère.
En effet, ses sous-étapes ne seront dans ce cas pas toute obligatoires pour l’ensemble des tâches d’où ce type de représentation.
Si il est possible d’avoir deux tâches réalisées en même temps (par deux personnes différentes), on va diviser le tickets en deux et on le rassemblera ensuite.
Cependant ce concept de séparation par ligne dans un kanban board apporte une complexité de gestion indéniable. Il faut vraiment mettre ceci en place qu’en ca de réelle nécessité. En effet, il est inutile de complexifier un kanban board inutilement.
Si on ne peut traiter qu’une tâche à la fois mais dans n’importe quel ordre, il est possible de faire des petites lettres à barrer selon ce qui est terminé dans un coin de la carte comme ceci :
Plusieurs types de demandes
Si nous avons plusieurs types de demandes comme par exemple : projet, bug, refactoring, Nous pourrons alors créer plusieurs lignes complètes sur le board pour bien séparer chaque type de demande.
D’ailleurs, nous pourrons également limiter le nombre de demande pour chaque type de demande comme on l’a fait pour chaque étape. C’est ainsi que nous pourrons représenter une limit wip horizontalement en mettant le numéro de limitation à côté du nom de la ligne.
Voici le type de board Kanban qui peut être mis en place :
Des états différents selon le type de demande
Les tableaux Kanban peuvent permettre de faire des états différents selon le type de demandes. Cela ne simplifie pas visuellement le board mais peut vous permettre d’avoir une solution à certains de vos problèmes.
Ici par exemple, on considère qu’un bug doit être géré en urgence et que le dev est son propre testeur afin d’accélérer le correctif. Du coup l’étape Test n’a pas beaucoup de sens en tant qu’état.
Comme vous pouvez le voir, nous commençons vraiment à avoir un kanban board complet.
Icônes pour créer des règles
Dans un kanban board, il est possible également d’utiliser des icône pour représenter des règles complémentaires intéressantes. Nous avions par exemple proposé dans le passé, l’utilisation de panneau de signalisation pour annoncer quelques règles supplémentaires.
Pour cela, nous créerons des petites icônes en papier qui pourront se déplacer indépendamment des tâches. En effet si un ticket doit suivre une règle à un moment, cela ne veut pas dire que la règle s’appliquera tout au long de la vie du ticket. C’est pour cela que nous dessinerons pas les icônes directement sur le ticket.
Item prioritaire
Dans certains cas, le demandeur aimerait qu’une tâche soit réalisé en priorité par rapport aux autres tâches. Cela peut alors se représenter avec une icône « prioritaire » prise directement du code de la route.
Voici un exemple de représentation :
Item bloqué
Parfois pour différentes raisons, il est nécessaire de bloquer une tâche sur un kanban board. Le demandeur ou ceux qui réalisent peuvent ainsi s’apercevoir qu’il est nécessaire d’avoir des éléments complémentaires avant de continuer à travailler sur une tâche en particulier.
Pour cela, l’équipe utilisera l’image du sens interdit qui est assez concret dans sa compréhension :
Item en alerte
Parfois, un membre de l’équipe a une alerte concernant un ticket en particulier. Afin de ne pas oublier d’en parler avec le reste de l’équipe (pourquoi pas en daily), il mettra dessus une icône alerte.
Voici la représentation de cette icône :
Conclusion Kanban board
Pour faire vos boards quelle que soit la méthodologie utilisée, ce type de board Kanban peuvent vous simplifier le travail. Il est préférable de faire de bons boards qui répondent bien au besoin que de se forcer à changer le comportement des cartes (post’it) selon le type de demande.
5 Rétroliens / Pings