Kanban
Comment la méthodologie kanban s'applique au développement logiciel
Parcourir les rubriques
Lancez-vous gratuitement avec le modèle Kanban de Jira
Maximisez l'efficacité en suivant et en faisant avancer le travail qui compte le plus.
Qu'est-ce que Kanban ?
Kanban est un framework populaire pour implémenter le développement logiciel Agile et DevOps. Il repose sur un travail effectué en toute transparence et une communication en temps réel de la capacité. Les tâches sont représentées visuellement sur un tableau Kanban. Ainsi, les membres de l'équipe peuvent voir l'état de chaque tâche à tout moment.
Articles sur Kanban
Découvrir Kanban grâce à Jira Software
Instructions détaillées pour mener un projet Kanban, prioriser vos tâches, visualiser votre workflow et réduire le nombre de tâches en cours avec Jira Software
Essayer ce tutorielPasser de « À faire » à « Terminé » grâce aux tableaux Kanban dans Jira
Le tableau Kanban de Jira Software est conçu pour aider continuellement les équipes à raccourcir la durée de cycle tout en accroissant l'efficacité.
Télécharger gratuitementJouissant d'une belle renommée auprès des équipes de développement Agile et DevOps actuelles, la méthodologie de travail Kanban remonte pourtant à plus de 50 ans. À la fin des années 1940, Toyota a commencé à optimiser ses processus d'ingénierie en se basant sur le modèle de gestion des inventaires utilisé par 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 son stock correspond aux schémas de consommation, le supermarché réalise d'importants gains d'efficacité dans la gestion de son inventaire en réduisant les stocks en excès qu'il doit maintenir à tout moment. Parallèlement, il veille toujours à conserver un produit donné en stock pour répondre aux besoins du consommateur.
Lorsque Toyota a appliqué ce système dans ses usines, son but était de mieux adapter ses importants niveaux de stock à la consommation réelle de matériaux. Pour communiquer les niveaux de capacité en temps réel au sein de l'usine (et aux fournisseurs), les employés se transmettaient une carte, ou « Kanban », d'une équipe à l'autre. Lorsqu'un conteneur de matériau utilisé dans la chaîne de production était vide, une carte Kanban indiquant le matériau nécessaire, la quantité exacte de matériau, etc., était transmise à l'entrepôt. Les employés de l'entrepôt disposaient d'un nouveau conteneur en attente, qu'ils envoyaient à l'usine, avant de transmettre à leur tour une carte Kanban au fournisseur. Celui-ci disposait également d'un conteneur de ce matériau spécifique en attente, qu'il livrait à l'entrepôt. Bien que ces techniques de signalement aient évolué depuis les années 1940, ce processus de fabrication « juste à temps » (ou JAT) est toujours au cœur de la méthode.
Kanban pour les équipes de développement
Les équipes de développement Agile d'aujourd'hui peuvent exploiter ces mêmes principes JAT en adaptant la quantité de travail en cours à leur capacité. Ainsi, les équipes disposent d'options de planification plus flexibles, la production s'accélère, les objectifs sont plus clairs et la transparence est renforcée tout au long du cycle de développement.

Si les principes fondamentaux du framework sont intemporels et s'appliquent à presque tous les secteurs, les pratiques Agile sont très appréciées des équipes de développement logiciel. Cela est en partie dû au fait que les équipes de développement peuvent adopter ces pratiques à moindres frais une fois qu'elles ont assimilé les principes de base. Contrairement à la mise en œuvre de Kanban dans une usine, qui impliquait d'apporter des changements aux processus physiques et d'ajouter des quantités importantes de matériaux, les seuls éléments physiques dont les équipes de développement ont besoin sont un tableau et des cartes, et même ceux-ci peuvent être virtuels.
Tableaux Kanban
Le travail de toute équipe kanban s'articule autour d'un tableau kanban, un outil utilisé pour visualiser le travail et optimiser le workflow au sein de l'équipe. Si les tableaux physiques sont appréciés de certaines équipes, les tableaux virtuels constituent un élément essentiel au sein de tout outil de développement de logiciel Agile, non seulement en raison de leur traçabilité, mais aussi parce qu'ils simplifient la collaboration et sont accessibles depuis plusieurs emplacements.
Que le tableau soit physique ou numérique, sa fonction est de permettre la visualisation du travail, la standardisation du workflow, mais aussi l'identification et la résolution des bloqueurs et des dépendances dans les plus brefs délais. Un tableau kanban classique comporte un workflow en trois étapes : « à faire », « en cours » et « terminé ». Cependant, selon la taille, la structure et les objectifs de l'équipe, le workflow peut être cartographié en fonction du processus spécifique d'une équipe en particulier.
La méthodologie Kanban repose sur un travail effectué en toute transparence et une communication en temps réel de la capacité ; c'est la raison pour laquelle le tableau Kanban doit être perçu comme la source de référence unique concernant le travail de l'équipe.

Les cartes Kanban
En japonais, kanban signifie littéralement « signal visuel ». Pour les équipes kanban, chaque tâche est représentée sous la forme d'une carte distincte sur le tableau.
La représentation du travail sous la forme d'une carte affichée sur le tableau kanban vise principalement à permettre aux équipes de suivre la progression du travail au sein du workflow d'une manière très visuelle. Les cartes kanban comportent des informations essentielles sur une tâche en particulier ; ainsi, toute l'équipe identifie clairement qui s'occupe de la tâche, en quoi elle consiste, le temps approximatif nécessaire à sa réalisation, etc. Les cartes affichées sur les tableaux kanban virtuels incluent souvent des captures d'écran des fonctionnalités et d'autres détails techniques utiles au responsable. Permettre aux membres de l'équipe de connaître l'état de chaque tâche à un moment donné, mais aussi de tous les détails associés, assure une concentration accrue sur les objectifs, une traçabilité complète et une identification rapide des bloqueurs et des dépendances.
Les avantages de kanban
Kanban est l'une des méthodologies de développement logiciel les plus populaires parmi les équipes Agile d'aujourd'hui. Elle présente plusieurs avantages par rapport à la planification de tâches et au débit pour des équipes de toute taille.
Planification flexible
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 Product Owner a donc tout le loisir de hiérarchiser à nouveau les tâches du backlog sans perturber l'équipe. En effet, les changements apportés aux tâches qui ne sont pas en cours n'ont aucun impact sur l'équipe. Tant que le Product Owner 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.
S'il est efficace, le Product Owner implique l'équipe de développement avant d'apporter des changements au 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 changements auprès de l'équipe d'ingénierie afin d'éviter toute surprise.
Durées de cycle raccourcies
La durée de cycle est une métrique clé pour les équipes Kanban. Elle représente le laps de temps nécessaire à une unité de travail pour parcourir le workflow de l'équipe, à partir du moment où le travail est amorcé jusqu'à la livraison. En optimisant la durée de cycle, l'équipe peut prévoir ses futures livraisons en toute confiance.
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 de cycle. Cela signifie également qu'en cas de goulot d'étranglement du travail, toute l'équipe peut agir 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 mettent eux aussi la main à la pâte.
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.
Réduction des goulots d'étranglement
Le multitasking met à mal 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 et les ratés dans le processus de l'équipe, qu'ils soient dus à un manque de concentration, de personnel ou de compétences.
Par exemple, une équipe de développement classique peut utiliser quatre états de workflow : « à faire », « en cours », « revue de code » et « terminé ». Elle peut décider de fixer une limite WIP à 2 pour l'état « revue de code ». Si cette limite peut sembler basse, il y a une bonne raison à cela : beaucoup de développeurs préfèrent écrire du code nouveau plutôt que de perdre leur temps à réviser le travail de leurs collègues. Une limite faible encourage l'équipe à accorder une attention toute particulière aux tickets de l'état « revue en cours » et à réviser le travail des autres avant d'entamer la revue de leur propre code. Au final, cela réduit la durée de cycle générale.
Métriques visuelles
L'une des valeurs fondamentales consiste à améliorer l'efficacité des équipes de manière continue à chaque itération de travail. Les diagrammes constituent un mécanisme visuel qui permet aux équipes de s'assurer qu'elles continuent de s'améliorer. Lorsque l'équipe peut voir les données, il est plus facile de détecter les goulots d'étranglement au sein du processus (et de les supprimer). Deux rapports souvent utilisés par les équipes kanban sont les graphiques de contrôle et les diagrammes de flux cumulatif.
Le tableau de contrôle montre la durée de cycle de chaque ticket, ainsi que la moyenne mobile de l'équipe.
L'objectif de l'équipe est de réduire le temps nécessaire à un ticket pour parcourir l'intégralité du processus. La réduction de la durée de cycle moyenne dans le graphique de contrôle est un indicateur de succès.
Un diagramme de flux cumulé montre le nombre de tickets pour chaque état. L'équipe peut facilement repérer les blocages en consultant l'augmentation du nombre de tickets à un état donné. Les tickets qui se trouvent à un état intermédiaire, comme « en cours » ou « en révision », ne sont pas livrés aux clients, et tout blocage à ces états peut accroître le risque de conflit d'intégration massif lorsque le travail est mergé en amont.
Livraison continue
La livraison continue (CD) consiste à livrer des tâches aux clients à intervalles réguliers. L'intégration continue (CI) est une pratique qui préconise les builds automatisés et les tests incrémentiels du code tout au long de la journée. Ensemble, ils forment un pipeline de CI/CD essentiel aux équipes de développement (notamment les équipes DevOps) pour livrer des logiciels plus rapidement en assurant une qualité élevée.
Kanban et la livraison continue se complètent à la perfection, car ces deux techniques sont axées sur la création de valeur « juste à temps » (et échelonnée). Plus vite une équipe est en mesure de procurer des innovations à ses clients, plus son produit sera compétitif sur le marché. Les équipes Kanban se concentrent précisément sur l'optimisation des livraisons aux clients.
Scrum ou Kanban ?
Kanban et Scrum ont plusieurs concepts en commun, mais avec des approches très différentes. Il ne faut en aucun cas les confondre.
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. |
Métriques 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 de 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.
Lancez-vous gratuitement avec le modèle Kanban pour Jira
Maximisez l'efficacité en suivant et en faisant avancer le travail qui compte le plus.
Prêt à vous lancer ?
Instructions détaillées pour mener un projet Kanban, prioriser vos tâches, visualiser votre workflow et réduire le nombre de tâches en cours avec Jira Software.
Lire ce tutorielConception Agile : processus et recommandations pour la conception collaborative
La conception collaborative travaille par itérations sur une conception de produit. Elle cherche pour cela à obtenir le point de vue des clients et des développeurs au début d'un projet. En savoir plus.
Lire cet article