What is Kanban?

Kanban est un terme japonais qui signifie enseigne ou panneau d’affichage. Un ingénieur industriel nommé Taiichi Ohno a développé Kanban chez Toyota Motor Corporation pour améliorer l’efficacité de la fabrication.

Bien que Kanban ait été créé pour la fabrication, le développement de logiciels partage plusieurs des mêmes objectifs, tels que l’augmentation du flux et du débit. Les équipes de développement de logiciels peuvent améliorer leur efficacité et offrir plus rapidement de la valeur aux utilisateurs en utilisant les principes directeurs et les méthodes Kanban.

Principes kanban

L’adoption de Kanban nécessite l’adhésion à certaines pratiques fondamentales qui peuvent différer des méthodes précédentes des équipes.

Visualiser le travail

Comprendre l’état de l’équipe de développement et la progression du travail peut être difficile. La progression du travail et l’état actuel sont plus faciles à comprendre lorsqu’elles sont présentées visuellement plutôt que sous la forme d’une liste d’éléments de travail ou d’un document.

La visualisation du travail est un principe clé que Kanban aborde principalement à travers les tableaux Kanban. Ces tableaux utilisent des cartes organisées par progression pour communiquer l’état global. La visualisation du travail sous forme de cartes dans différents états sur un tableau permet de voir facilement la situation globale d'un projet, ainsi que d’identifier les goulots d'étranglement potentiels qui pourraient affecter la productivité.

Utiliser un modèle d’extraction

Historiquement, les parties prenantes demandaient des fonctionnalités en transmettant le travail aux équipes de développement, souvent avec des délais serrés. La qualité en souffrait si les équipes devaient prendre des raccourcis pour livrer les fonctionnalités dans les délais.

Kanban se concentre sur le maintien d’un niveau de qualité convenu qui doit être respecté avant de prendre en compte le travail effectué. Pour prendre en charge ce modèle, les parties prenantes ne travaillent pas sur les équipes qui travaillent déjà au niveau de la capacité. Au lieu de cela, les parties prenantes ajoutent des demandes à un arriéré qu’une équipe intègre dans son flux de travail à mesure que la capacité devient disponible.

Imposer une limite WIP

Les équipes qui essaient de travailler sur trop de choses à la fois peuvent souffrir d’une productivité réduite en raison de changements de contexte fréquents et coûteux. L'équipe est occupée, mais le travail ne se fait pas, ce qui entraîne des délais de livraison inacceptablement élevés. Limiter le nombre d'éléments d'arriéré sur lesquels une équipe peut travailler à un moment permet d'accroître la concentration tout en réduisant les changements de contexte. Les éléments sur lesquels l'équipe travaille actuellement s'appellent travaux en cours (WIP).

Les équipes décident d'une limite WIP, ou d'un nombre maximal d'éléments sur lesquels ils peuvent travailler à un moment. Une équipe bien disciplinée s'assure de ne pas dépasser sa limite WIP. Si les équipes dépassent leurs limites WIP, elles examinent la raison et travaillent pour résoudre la cause racine.

Mesurer l'amélioration continue

Pour pratiquer l'amélioration continue, les équipes de développement ont besoin d’un moyen de mesurer l'efficacité et le débit. Les tableaux Kanban fournissent une vue dynamique des états de travail dans un flux de travail, afin que les équipes puissent expérimenter des processus et évaluer plus facilement l'impact sur les flux de travail. Les équipes qui adoptent Kanban pour l'amélioration continue utilisent des mesures telles que le délai de livraison et le temps de cycle.

Tableaux kanban

Le tableau Kanban est l'un des outils utilisés par les équipes pour mettre en œuvre les pratiques Kanban. Un tableau Kanban peut être un tableau physique ou une application logicielle qui affiche des cartes organisées en colonnes. Les noms de colonnes typiques sont À faire, Faire, et Fait, mais les équipes peuvent personnaliser les noms pour correspondre à leurs états de flux de travail. Par exemple, une équipe peut préférer utiliser Nouveau, Développement, Tester, UAT, et Fait.

Les tableaux Kanban basés sur le développement logiciel affichent des cartes qui correspondent aux éléments d'arriéré de produit. Les cartes incluent des liens vers d'autres éléments, tels que des tâches et des cas de test. Les équipes peuvent personnaliser les cartes pour inclure des informations pertinentes pour leur processus.

Sur un tableau Kanban, la limite WIP s’applique à toutes les colonnes en cours. Les limites WIP ne s’appliquent pas aux premières et dernières colonnes, car ces colonnes représentent le travail qui n’a pas démarré ou n’est pas terminé. Les tableaux Kanban aident les équipes à rester dans les limites WIP en attirant l’attention sur les colonnes qui dépassent les limites. Les équipes peuvent alors déterminer un plan d'action pour supprimer le goulot d'étranglement.

Diagrammes de flux cumulatifs

Un ajout courant aux tableaux Kanban basés sur le développement logiciel est un graphique appelé diagramme de flux cumulatif (CFD). La CFD illustre le nombre d’éléments dans chaque état au fil du temps, généralement sur plusieurs semaines. L'axe horizontal affiche la chronologie, tandis que l'axe vertical affiche le nombre d'éléments d'arriéré de produit. Les zones colorées indiquent les états ou colonnes dans lesquels les cartes sont actuellement présentes.

Le CFD est particulièrement utile pour identifier les tendances au fil du temps, notamment les goulots d'étranglement et d'autres perturbations de la vitesse de progression. Un bon CFD montre une tendance à la hausse constante pendant qu'une équipe travaille sur un projet. Les zones colorées du graphique doivent être à peu près parallèles si l'équipe travaille dans ses limites WIP.

Un gonflement dans une ou plusieurs zones colorées indique généralement un goulot d'étranglement ou un obstacle dans le flux de l'équipe. Dans le CFD suivant, le travail terminé en vert est plat, tandis que l'état de test en bleu augmente, probablement en raison d'un goulot d'étranglement.

Kanban et Scrum dans le développement Agile

Bien que s'inscrivant largement dans le cadre du développement Agile, Scrum et Kanban sont très différents.

• Scrum se concentre sur les sprints de longueur fixe, tandis que Kanban est un modèle de flux continu.
• Scrum a des rôles définis, tandis que Kanban ne définit aucun rôle d’équipe.
• Scrum utilise la vélocité comme métrique clé, tandis que Kanban utilise le temps de cycle.

Les équipes adoptent généralement des aspects de Scrum et Kanban pour les aider à travailler le plus efficacement. Quelles que soient les caractéristiques choisies, les équipes peuvent toujours passer en revue et s’adapter jusqu’à ce qu’elles trouvent le meilleur ajustement. Les équipes doivent commencer simple et ne pas perdre de vue l'importance de fournir de la valeur régulièrement aux utilisateurs.

Kanban avec GitHub

GitHub offre une expérience Kanban via des tableaux de projet (classique). Ces tableaux vous aident à organiser et hiérarchiser le travail pour un développement de fonctionnalités spécifique, des feuilles de route complètes ou des listes de contrôle de mise en production. Vous pouvez automatiser les tableaux de projet (classique) pour synchroniser l'état de la carte avec les problèmes associés et les demandes de tirage.

Kanban avec Azure Boards

Azure Boards fournit une solution Kanban complète pour la planification DevOps. Azure Boards a une intégration approfondie dans Azure DevOps, et peut également faire partie de l’intégration Azure Boards-GitHub.

• Pour plus d'informations, consultez Raisons d'utiliser Azure Boards pour planifier et suivre votre travail.
• Le module Learn Choisir une approche Agile du développement logiciel fournit une expérience Kanban pratique dans Azure Boards.