Kanban

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.

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.

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.

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.

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.

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.

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.

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.

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.

Kanban et Scrum ont plusieurs concepts en commun, mais avec des approches très différentes. Il ne faut en aucun cas les confondre.

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.