Retour à la liste

Brève introduction à Kanban

Créé : 19.01.2016, 14:16:24  -  Modifié : 26.05.2018, 14:33:37

Kanban est un autre cadre de travail utilisé pour la mise en œuvre d'Agile. Dans les années 1940, Toyota optimisa son processus d'ingénierie en le modélisant d'après le mode d'approvisionnement des rayons dans les supermarchés. Les supermarchés stockent juste ce qu'il faut de produits afin de répondre à la demande des consommateurs. Cette pratique optimise le flux entre le supermarché et le client. Comme l'inventaire correspond aux schémas de consommation, le supermarché améliore considérablement son efficacité en termes de gestion des stocks et d'optimisation pour le client. Lorsque Toyota importa cette idée dans ses usines, une équipe (par exemple, celle qui fixe les portières au cadre du véhicule) devait transmettre une fiche, ou « Kanban », à une autre équipe (par exemple, celle qui assemble les portières) afin de signaler qu'en raison de capacités excédentaires, elle était prête à recevoir davantage de matériaux. Certes, la technologie de signalisation a évolué depuis. Mais ce système reste aujourd'hui le fondement de la production à flux tendus.

Kanban apporte les mêmes avantages aux équipes de développement de logiciels. En adaptant le volume du travail en cours aux capacités de l'équipe, Kanban apporte aux équipes des options de planification plus flexibles, des résultats plus rapides, des priorités claires et une transparence tout au long du cycle de développement. 

Flexibilité dans la planification

L'équipe Kanban se concentre uniquement sur le travail activement en cours. Une fois qu'elle termine une tâche, elle récupère la tâche suivante en tête du backlog. Le responsable produit a donc tout le loisir de rehiérarchiser les tâches du backlog sans perturber l'équipe. En effet, les modifications apportées aux tâches qui ne sont pas en cours n'ont aucun impact sur l'équipe. Tant que le responsable produit conserve les tâches les plus importantes en tête du backlog, l'équipe de développement a l'assurance de rapporter à l'entreprise une valeur ajoutée maximale. Les itérations à durée fixe telles qu'elles apparaissent dans Scrum ne sont donc pas nécessaires ici. 

Astuce : le responsable produit, s'il est efficace, implique l'équipe de développement avant de modifier le backlog. Par exemple, si celui-ci contient les user stories 1 à 6, l'estimation de la user story 6 dépendra peut-être de l'achèvement des user stories 1 à 5. Il est toujours recommandé de valider les modifications auprès de l'équipe d'ingénierie afin d'éviter toute surprise. 

Minimiser la durée du cycle

La durée du cycle est un indicateur clé pour les équipes Kanban. La durée du cycle est le temps nécessaire à une unité de travail pour parcourir le workflow de l'équipe, depuis le début du travail jusqu'à sa livraison. En optimisant la durée du cycle, l'équipe peut prévoir, de façon fiable, la livraison des tâches ultérieures.

Le chevauchement des compétences permet de réduire la durée des cycles. Lorsqu'une seule personne détient une compétence en particulier, elle devient le goulot d'étranglement du workflow. Les équipes appliquent donc les bonnes pratiques de base, telles que la revue de code ou le mentorat, pour favoriser la diffusion des connaissances. En partageant les compétences, les membres de l'équipe peuvent assumer des tâches hétérogènes, ce qui optimise encore davantage la durée du cycle. Cela signifie également que si les compétences sont partagées, l'équipe entière peut se pencher sur le travail à réaliser pour que le processus reprenne son cours normal. Par exemple, les tests ne sont pas le domaine exclusif des ingénieurs en assurance qualité. Les développeurs s'y attellent également !

Dans un cadre de travail Kanban, la fluidité de la progression des tâches tout au long du processus relève de la responsabilité de l'équipe entière. 

L'efficacité par la concentration

Le multitasking tue l'efficacité. Plus il y a de tâches en cours à un moment donné, plus le contexte change, ce qui freine leur achèvement. C'est pourquoi l'un des piliers de Kanban est de limiter le volume de travail en cours. Les limites du volume de travail en cours mettent en évidence les goulots d'étranglement dans le processus de l'équipe, qu'ils soient dus à une insuffisance de concentration, de personnel ou de compétences.

Par exemple, une équipe type de développement de logiciels peut appliquer quatre états de workflow : à faire, en cours, revue de code et terminé. Elle peut décider de fixer une limite du volume de travail en cours à 2 pour la revue de code. Cette limite peut sembler basse, mais il y a une bonne raison à cela : le code qui n'a pas été revu non seulement n'a pas été livré, mais il peut nécessiter une reprise significative du travail avant d'être prêt à être livré. Il est donc important d'agir rapidement sur les revues de code. La définition d'une limite du volume de travail en cours permet de responsabiliser l'équipe en ce sens. Elle l'oblige à éliminer ces revues avant de prendre de nouvelles tâches. 

L'un des facteurs clés dans la méthode Kanban de développement de logiciels est la limite du volume de travail en cours.

Des indicateurs visuels

L'une des valeurs fondamentales de Kanban est l'amélioration continue. Mais comment les équipes s'assurent-elles qu'elles continuent de s'améliorer ? En un mot : visuellement. Lorsque l'équipe peut visualiser les données, elle peut plus facilement localiser les goulots d'étranglement dans le processus (et les éliminer !). Les tableaux de contrôle et les diagrammes cumulatifs sont deux des rapports fréquemment utilisés par les équipes Kanban.

Le tableau de contrôle montre la durée de cycle de chaque ticket, ainsi que la moyenne mobile de l'équipe. 

Astuce : l'objectif de l'équipe est de réduire le temps nécessaire à un ticket pour parcourir l'intégralité du processus. La baisse de la durée de cycle moyenne dans le tableau de contrôle est un indicateur de succès. 

Le tableau de contrôle montre la durée de cycle de chaque ticket dans le développement agile avec Kanban.

Le diagamme cumulatif montre le nombre de tickets présents dans chaque état. L'équipe peut facilement localiser les blocages en voyant le nombre de tickets augmenter dans un état donné. Dans le tableau ci-dessous, nous constatons une hausse significative de la quantité de code en attente de merge (en rouge) au fil du temps. Cela crée un goulot d'étranglement qui empêche le client d'accéder aux fonctionnalités et correctifs déjà développés et augmente la probabilité de conflits massifs d'intégration au moment de procéder au merge du travail réalisé en amont. 

Le diagramme cumulatif montre le nombre de tickets présents dans chaque état dans le développement agile avec Kanban.

Dans l'exemple ci-dessus, l'équipe réalise la sauvegarde juste avant le 1er septembre et s'efforce de ramener rapidement la quantité de code non mergé à un niveau acceptable. 

Évoluer vers la livraison continue

Nous savons que l'intégration continue, à savoir la pratique qui consiste à développer et à valider le code de façon incrémentielle tout au long de la journée, est essentielle au maintien de la qualité. Découvrons à présent la cousine de l'intégration continue, plus âgée et plus sophistiquée : la livraison continue. Cette pratique consiste à livrer fréquemment du travail aux clients, chaque jour ou même chaque heure. Kanban et la livraison continue se complètent formidablement bien. En effet, les deux techniques se concentrent sur la fourniture de valeur ajoutée en flux tendus (et de type une à la fois).

Plus vite l'équipe pourra commercialiser une innovation, plus son produit sera compétitif sur le marché. Or, les équipes Kanban se focalisent précisément sur ce point : optimiser le flux de travail dans l'optique de la livraison aux clients. 

Scrum ou Kanban ?

Kanban et Scrum ont plusieurs concepts en commun, mais avec des approches très différentes. Les deux techniques ne doivent pas être confondues. 

  Scrum Kanban
Cadence Sprints réguliers et à durée déterminée (à savoir, 2 semaines) Flux continu
Méthodologie de livraison À la fin de chaque sprint si approbation par le responsable produit Livraison continue ou lorsque l'équipe le décide
Rôles Product Owner, Scrum Master, équipe de développement Pas de rôles prédéfinis. Certaines équipes demandent l'aide d'un coach Agile.
Indicateurs clés Vélocité Durée du cycle
Philosophie en matière de changement Les équipes doivent s'efforcer de ne pas modifier la prévision du sprint pendant ce dernier. Cela entraverait l'apprentissage concernant les estimations. Des modifications peuvent être apportées à tout moment

Certaines équipes marient les idéaux de Kanban et de Scrum en une technique intitulée « Scrumban ». Elles prennent les sprints à durée déterminée et les rôles de Scrum, et les associent à la concentration sur les limites du volume de travail en cours et à la durée du cycle de Kanban. Cependant, aux équipes qui débutent avec Agile, nous recommandons vivement de choisir l'une des deux méthodologies et de l'expérimenter pendant un moment. Vous pourrez toujours vous amuser plus tard.


Rendu :0.3658 | Mémoire :2.9MB

Accueil | Informations | Top