Qu’est-ce que Kanban ?

Kanban est un terme japonais qui signifie panneau 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 fournir de la valeur aux utilisateurs plus rapidement à l’aide des principes et méthodes guidant Kanban.

Principes kanban

L’adoption de Kanban nécessite l’adhésion à certaines pratiques fondamentales susceptibles de varier selon les 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 traite principalement par le biais de tableaux Kanban. Ces tableaux utilisent des cartes organisées par progression pour communiquer l’état global. La visualisation du travail en tant que cartes dans différents états d’un tableau permet de voir facilement l’image globale de l’emplacement d’un projet, ainsi que d’identifier les goulots d’étranglement potentiels susceptibles d’affecter la productivité.

Utiliser un modèle d’extraction

Historiquement, les parties prenantes ont demandé des fonctionnalités en transmettant le travail aux équipes de développement, souvent avec des délais serrés. La qualité a souffert si les équipes devaient prendre des raccourcis pour fournir les fonctionnalités dans le délai imparti.

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 soutenir ce modèle, les parties prenantes n'assignent pas de travail supplémentaire aux équipes qui sont déjà à pleine capacité. Au lieu de cela, les parties prenantes ajoutent des demandes à un backlog qu’une équipe extrait 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 d’un changement de contexte fréquent et coûteux. L’équipe est occupée, mais le travail n’est pas fait, ce qui entraîne des délais d’exécution inacceptables. Limiter le nombre d'éléments de backlog sur lesquels une équipe peut travailler à la fois aide à augmenter la concentration tout en réduisant les changements de contexte. Les éléments que l’équipe travaille actuellement sont appelés travaux en cours (WIP).

Les équipes décident d’une limite WIP ou d’un nombre maximal d’éléments qu’ils peuvent utiliser à la fois. Une équipe bien disciplinée veille à ne pas dépasser sa limite de 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 temps de réalisation et le temps de cycle.

Tableaux Kanban

Le tableau Kanban est l’un des outils utilisés par les équipes pour implémenter des 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 classiques sont To-do, Doing et Done, mais les équipes peuvent personnaliser les noms pour qu’ils correspondent à leurs états de flux de travail. Par exemple, une équipe peut préférer utiliser New, Development, Testing, UAT et Done.

Les tableaux Kanban basés sur le développement logiciel affichent des fiches qui correspondent aux éléments du backlog de produit. Les cartes incluent des liens vers d’autres éléments, tels que les tâches et les cas de test. Teams peut 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 les dépassent. Les équipes peuvent ensuite déterminer un plan d’action pour éliminer 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 cumulé (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 de backlog de produit. Les zones colorées indiquent les états ou colonnes dans lesquels les cartes sont actuellement présentes.

La 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 la CFD suivante, le travail terminé, représenté en vert, est stable, alors que la phase de test, représentée en bleu, augmente, probablement en raison d’un goulot d’étranglement.

Kanban et Scrum dans le développement Agile

Bien qu’ils soient largement adaptés au 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 défini des rôles, 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 simplement et ne doivent pas perdre de vue l'importance d'apporter de la valeur régulièrement aux utilisateurs.

Kanban avec GitHub

GitHub offre une expérience Kanban via des tableaux de projet (classiques). 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 des cartes avec les problèmes associés et les pull requests.

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 d’Azure Boards-GitHub.

• Pour plus d’informations, consultez Les raisons d’utiliser Azure Boards pour planifier et suivre votre travail.
• Le module Learn Choisit une approche agile du développement logiciel fournit une expérience Kanban pratique dans Azure Boards.