Agilité: Un peu de Kanban et de Scrum

Dans le monde des Méthodes Agiles, Kanban occupe une place assez importante. Conçue au départ pour l'optimisation des chaînes de production, la méthode est, par sa capacité à améliorer la prise en compte des événements "au fil de l'eau", plutôt adaptée au monde de la maintenance. A ce titre, elle apporte une alternative intéressante à Scrum, à laquelle elle peut même, grâce à son caractère très adaptatif, être associée.

Présentation

En japonais, un kanban est une étiquette, ou une fiche. En développement logiciel, Kanban est une pratique basée sur l'utilisation de kanbans (comme pour le terme scrum, l'usage est d'écrire avec une minuscule (kanban, scrum) l'objet ou la cérémonie, et avec une majuscule (Kanban, Scrum), la méthode) pour matérialiser des informations sur le processus.

Le scrum board, qui matérialise dans Scrum l'état et l'avancement des tâches du sprint en cours, est déjà une utilisation des kanbans.

Dans Kanban, le tableau des tâches est l'élément central de la méthode :

• il matérialise, comme dans Scrum, le workflow et les différents états que peut prendre une tâche ou un élément de la chaîne d'activités ;
• il apporte une contrainte supplémentaire, le nombre maximum d'éléments que peut contenir, à un moment donné, une colonne du tableau. Cette limite n'est pas obligatoire pour toutes les colonnes du tableau ; elle permet d’agir sur les colonnes ou les états qui sont potentiellement des goulots d'étranglement.

Par rapport aux autres méthodes

Kanban est une méthode plus adaptative (peu de prescriptions) que normative.

C'est en quelque sorte le contraire d'une boîte à outils : là où une boîte à outils propose beaucoup de choses et l'utilisateur ne prend que ce dont il a besoin, Kanban ne propose que très peu de choses, mais qui constituent un socle qui permet à l'utilisateur de l’adapter ou d’ajouter des éléments spécifiques à son problème ou à sa méthode (syndrome dit de la "clé à molette" : une clé à molette pour remplacer tout un jeu de clés).

Diminuer le temps de cycle

La représentation et la progression des éléments en temps réel sur le tableau Kanban permet, s'il y a un goulot d'étranglement, de voir rapidement de voir où il est (dans la colonne où les cartons (ou les post-its) s'accumulent).

Pour diminuer le temps de cycle d'un élément, il faut en quelque sorte « fluidifier le trafic » et pour cela le ralentir en amont. Un paradoxe apparent également adopté par les régulateurs de trafic : rouler à 90 km/h pour éviter d’être à l’arrêt plus loin et au final diminuer le temps de parcours. En instaurant une limite sur le nombre de tickets admissibles dans la colonne où se situe le goulet, on va les forcer à rester sur la colonne en amont, permettant ainsi de répartir la charge d'étranglement sur deux colonnes (deux activités) au lieu d'une.

C'est la philosophie de Kanban : s'il y a trop d'activité sur un poste, il est plus efficace de répartir la charge que d’affecter de nouvelles ressources.

La bonne limitation n'est pas facile à trouver du premier coup, évidemment ; elle est souvent le fruit de plusieurs améliorations. L'intérêt de Kanban est de permettre, ajustement après ajustement, de trouver la meilleure répartition de charge entre tous les postes du processus (toutes les colonnes du tableau) et d'employer les ressources au mieux de leurs capacités.

Les différences avec Scrum

Les rôles

Alors que Scrum préconise des acteurs et des rôles bien particuliers (Product Owner, Scrum Master, équipier), Kanban ne prescrit aucun rôle.

Cela ne veut pas dire qu'il ne faut pas définir des rôles ou s'interdire par exemple de prendre un Product Owner. Cela veut simplement dire que l'on n'est pas obligé d'avoir des rôles bien définis. Avec Kanban, on peut ajouter tous les rôles dont il a besoin.

Attention cependant à ne pas créer des rôles (ou plus généralement des artefacts) pour rien : un nouveau rôle doit apporter de la valeur et de l'efficacité au projet ; s'il n'est pas réellement utile, il pourrait même constituer une source de gaspillage.

La durée des itérations

Scrum impose des itérations (sprints) de durée fixe - encore que celle-ci puisse varier en cours de projet si par exemple elle s'avère inadaptée - imposant ainsi un rythme régulier au projet. Des points obligatoires sont prévus à chaque début et fin de sprint, donc à intervalles fixes tout au long du projet. Tous les éléments prévus pour être traités pendant le sprint (le carnet de sprint) doivent être traités pendant la timebox définie par le sprint. Le tableau Scrum est "vidangé" à chaque fin de sprint et réinitialisé à chaque début de sprint.

Kanban n'impose pas d'itérations, et donc encore moins de durée fixe. Des éléments de projet peuvent s'insérer dans le tableau Kanban à tout moment, sans avoir à attendre une réinitialisation du tableau.

Avec Kanban, on n'est pas obligé d'attendre le début ou la fin d'une itération pour faire une planification, une rétrospective ou livrer une version. Ces activités peuvent être faites sur la base d'une activité régulière ("livraison tous les lundis") ou à la demande ("chaque fois qu'une version utile est prête").

Scrum mesure la vélocité, Kanban le temps de cycle

Scrum établit des prévisions sur la base de la vélocité (la quantité totale d'effort que l'équipe peut accomplir pendant un sprint). S'il a par exemple été mesuré une vélocité moyenne de 100 sur les trois derniers sprints, il est logique de s'engager sur la même vélocité pour le prochain sprint ; pour établir le carnet de sprint, il suffit d'additionner les efforts estimés des items ou User Stories en tête de backlog jusqu'à atteindre le total de 100.

L'un des challenges d'un projet Scrum est de trouver la "bonne" vélocité, celle qui permet la production régulière et fréquente de versions apportant une vraie valeur à l'utilisateur, tout en respectant un rythme de travail soutenable.

Kanban s'attache davantage à mesurer (et à faire diminuer) le temps de cycle, c'est-à-dire le temps que met un élément pour parcourir le tableau, depuis la colonne de gauche jusqu'à celle de droite.

Kanban est plus réactif

Avec Scrum, la rétrospective, cérémonie permettant d'initialiser l'amélioration du processus, a lieu à chaque fin d'itération ; la durée moyenne d'attente d'une amélioration du processus est donc égale à la moitié de la durée d'un sprint.

Avec Kanban, on peut réfléchir à améliorer le processus chaque fois qu'un kanban (un post-it) termine son cycle et arrive dans la dernière colonne du tableau. En l'absence de goulots d'étranglement (c'est l'objectif à atteindre), toutes les tâches de même type doivent théoriquement demander le même temps de cycle ; pour ce type de tâche, la durée moyenne d'attente d'une amélioration est de la moitié de son temps de cycle.

Pour plus d'informations

Pour plus d'informations sur Kanban et son utilisation avec Scrum, on pourra lire "Kanban et Scrum - tirer le meilleur des deux" par Henrik Kinberg et Mattias Skarin. L'ouvrage est traduit en français, entre autres, par Claude Aubry.

Agilement vôtre.

(Tiré d'un article écrit par Vincent MARTIN    : http://www.computure.net/fr/methodes/146-un-peu-de-kanban)