Kanban

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

What is 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 le statut de chaque tâche à tout moment.

Kanban articles

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

Kanban pour les équipes de développement

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

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 modifications 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étholodogie 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 seule source fiable concernant le travail de l'équipe.

Agile Kanban Board | Atlassian agile coach

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.

The benefits of 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

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Des compétences qui se chevauchent entraînent une réduction des temps 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 du code et l'aide surveillée pour diffuser les connaissances. Les compétences partagées signifient que les membres de l'équipe peuvent effectuer un travail hétérogène, qui permettra d'optimiser le temps 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.

In a kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process.

Réduction des goulots d'étranglement

Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenant of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

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.

A control chart shows the cycle time for each issue as well as a rolling average for the team.

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

Un diagramme de flux cumulatif montre le nombre de tickets pour chaque état. L'équipe peut facilement repérer les blocages en consultant l'augmentation du nombre de tickets dans un état donné. Les tickets qui se trouvent dans un état intermédiaire, comme « en cours » ou « en révision », ne sont pas livrés aux clients, et tout blocage dans 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

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
Cadence

Regular fixed length sprints (ie, 2 weeks)

 Continuous flow
Release methodology At the end of each sprint if approved by the product owner Continuous delivery or at the team's discretion
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time

 

Some teams blend the ideals of kanban and scrum into "scrumban." They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on. 

Dan Radigan
Dan Radigan

Agile a eu un impact considérable sur moi, à la fois personnellement et professionnellement. J'ai appris que les meilleures expériences étaient Agile, dans le code comme dans la vie. Vous me trouverez souvent au carrefour entre la technologie, la photographie et la moto. Suivez-moi sur Twitter ! @danradigan

Up Next
Tableaux