Close

Kanban

Comment la méthodologie Kanban s'applique au développement logiciel

Parcourir les rubriques

Qu'est-ce que Kanban ?

Kanban est un framework populaire pour implémenter le développement logiciel Agile. 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

[SUITE]

Jouissant d'une belle renommée auprès des équipes de développement Agile d'aujourd'hui, 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. Ceux-ci stockent juste assez de produits pour répondre à la demande des clients – une pratique qui optimise le flux entre le supermarché et le consommateur. 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, elles 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.

Tableau Kanban | Atlassian – Le coach Agile

Si les principes fondamentaux du framework sont intemporels et s'appliquent à la plupart des secteurs, les pratiques Agile sont très appréciées des équipes de développement. 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 Agile, non seulement en raison de leur traçabilité, mais aussi parce qu'ils simplifient la collaboration et sont accessibles depuis plusieurs sites.

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, ainsi que la résolution des bloqueurs et des dépendances dans les plus brefs délais. Un tableau Kanban de base comprend 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 donnée.

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.

Tableau Kanban Agile | Atlassian – Le coach Agile

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 membres de l'équipe de suivre l'avancement 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, ainsi qu'une identification rapide des bloqueurs et des dépendances.

Les avantages de kanban

Kanban est l'une des méthodologies de développement 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

Une équipe Kanban se concentre uniquement sur le travail en cours. Une fois que l'équipe termine une tâche, elle récupère la tâche suivante en tête du backlog. Le Product Owner est libre de réorganiser 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 pas d'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 est certaine de rapporter une valeur ajoutée maximale au business. Les itérations à durée fixe telles qu'elles apparaissent dans Scrum ne sont donc pas nécessaires ici.

Conseil de pro :

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.

Des compétences qui se chevauchent entraînent une réduction des durées de cycle. Si une personne est seule à détenir un ensemble de compétences, elle représente un goulot d'étranglement pour le workflow. Les équipes suivent de bonnes pratiques élémentaires comme la revue de code et l'aide surveillée pour diffuser les connaissances. Grâce aux compétences partagées, les membres de l'équipe peuvent effectuer un travail hétérogène, qui permettra d'optimiser la durée de cycle. Cela signifie également que le travail est sous haute protection : toute l'équipe peut agir pour que le processus reprenne son cours normal. Par exemple, les tests ne sont pas uniquement effectués par des ingénieurs QA. Les développeurs mettent eux aussi la main à la pâte.

Dans un framework Kanban, l'avancement fluide des tâches tout au long du processus relève de la responsabilité de l'équipe entière.

Réduction des goulots d'étranglement

La polyvalence est l'ennemie de l'efficacité. Plus le nombre de tâches en cours à un moment donné est élevé, plus vous devez changer de contexte, ce qui crée des obstacles à l'achèvement. C'est pourquoi l'un des principes clés de Kanban consiste à 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 en raison d'un manque d'orientation, de ressources humaines 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 du travail en cours à 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 « en révision » 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 cumulés.

Un graphique de contrôle indique la durée de cycle pour chaque ticket, ainsi qu'une moyenne glissante pour l'équipe.

Conseil de pro :

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. 

Graphique de contrôle Agile | Atlassian – Le coach Agile

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. 

Diagramme de flux cumulatif

Livraison continue

Comme nous le savons, l'intégration continue, une pratique qui préconise les builds automatisés et les tests incrémentiels du code tout au long de la journée, est essentielle au maintien de la qualité. À présent, le moment est venu de vous familiariser avec la livraison continue (CD). Cette pratique consiste à livrer du travail aux clients à intervalles réguliers, parfois même une fois par jour, voire par heure. 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 véritablement 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, à durée fixe (c'est-à-dire 2 semaines)

 Flux continu
Méthodologie de livraison À l'issue de chaque sprint, si approuvé par le Product Owner Livraison continue ou à la discrétion de l'équipe
Rôles Product Owner, Scrum Master, équipe de développement Aucun rôle existant. Certaines équipes sollicitent l'aide d'un coach Agile.
Métriques clés Vélocité Durée de cycle
Philosophie du changement Les équipes devraient s'efforcer de ne pas apporter de changements à la prévision du sprint durant celui-ci. Ce faisant, elles compromettraient les enseignements tirés de l'estimation. Le changement peut avoir lieu à 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 Scrum, et les associent à l'accent placé par Kanban sur les limites du volume de travail en cours et la durée de cycle. 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. 

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. 

suivant
Boards