Guide Scrum | 33. Scrumban et tableaux Kanban dans Scrum

Scrum et Kanban sont des méthodes de travail en équipe qui partagent de nombreuses similitudes. Cependant, il existe également des différences que nous aimerions discuter aujourd’hui. Les tableaux Kanban sont également souvent adoptés par les équipes Scrum. Cela est dû au fait qu’ils sont très pratiques pour visualiser le travail d’équipe et son avancement. En combinant le meilleur des deux méthodologies, une technique appelée Scrumban est apparue. Elle est populaire dans les projets qui combinent le développement de produits avec la livraison de services, où de longs Sprints et des réunions Scrum relativement formalisées ne sont pas toujours adaptés.

Scrumban et tableaux Kanban dans Scrum – table des matières :

1. Introduction
2. Kanban vs Scrum
3. Tableaux Kanban dans Scrum
4. Scrumban
5. Résumé

Introduction

Kanban est une méthode pionnière au Japon. Elle a vu le jour dans les années 1950 et était principalement un outil de gestion de la production continue de manière à ne pas créer d’inventaires et de surplus, mais à traiter les ressources de manière continue. Au début du 21e siècle, Kanban a été adapté aux besoins du développement logiciel par David J. Anderson.

Kanban vs Scrum

La manière générale de travailler dans Kanban diffère de Scrum principalement par l’adoption d’une approche moins formelle. Dans Kanban, il n’y a pas de directives aussi détaillées sur, par exemple, le travail en Sprints, les rôles de Product Owner, Scrum Master et Équipe de développement. Cela est possible car Kanban se concentre sur la continuité des tâches telles que la fourniture d’un type de service spécifique, qui sont plus répétables et ne nécessitent pas une planification aussi complexe.

Cependant, l’objectif et les méthodes de travail sont similaires. L’objectif de Kanban est de livrer le produit de la plus haute qualité au client dans les délais. Les principes concernant les méthodes de travail communs aux deux méthodes peuvent être formulés comme suit :

1. Le travail doit être fluide et sans temps d’arrêt – dans Scrum, cela est réalisé par la succession continue des Sprints, tandis que dans Kanban, le travail est continu grâce au flux fluide des tâches. Elles forment une file d’attente, à partir de laquelle les développeurs choisissent (tirent) quelques tâches à accomplir.
2. L’équipe doit se concentrer uniquement sur les tâches sélectionnées – en utilisant la terminologie Kanban, l’équipe doit “réduire le travail en cours”. Dans Scrum, l’équivalent de cela est les User Stories choisies dans le Product Backlog à mettre dans le Sprint Backlog.
3. Le progrès des tâches doit être visible pour toutes les personnes impliquées – dans Kanban, elles sont visualisées par des tableaux, qui sont également souvent présents dans les équipes Scrum.

Tableaux Kanban dans Scrum

Un tableau Kanban est un outil largement utilisé pour visualiser le travail d’équipe. C’est un tableau avec plusieurs colonnes. Dans chacune d’elles, il y a des tâches avec un certain statut. La catégorisation des tâches est basée sur une règle simple : une carte avec une description de la tâche – ou son équivalent virtuel – est placée dans l’une des colonnes. La version minimale des tableaux Kanban contient trois colonnes :

• À faire
• En cours
• Terminé – dans la dernière colonne vont les tâches qui répondent à la Définition de Terminaison, dont nous avons parlé ici.

Vous pouvez trouver ci-dessous un exemple de tableau kanban d’un système de gestion de projet tout-en-un – Firmbee.com

En général, il y a plus de colonnes. S’il y a plus de tâches à accomplir, il y a généralement une colonne supplémentaire intitulée “sélectionnées pour achèvement” entre les colonnes “à compléter” et “en cours”. Alors que la colonne “à faire” sert de Product Backlog, dont nous avons parlé ici, la colonne “sélectionnées pour achèvement” sert de Sprint Backlog, que nous décrivons en détail dans cet article.

Le deuxième ajout courant est une colonne “en révision” ou “pour approbation”. Elle est généralement insérée entre les colonnes contenant les tâches “en cours” et celles “terminées”. Elle contient des tâches complétées par l’équipe de développement qui attendent l’approbation du Product Owner. La tâche du Product Owner est de vérifier leur conformité avec les critères d’acceptation et d’obtenir leur approbation finale du client. Dans cette situation, seules les tâches finalement acceptées sont déplacées vers la dernière colonne.

Scrumban

En raison de la grande popularité de Scrum et Kanban, leur hybride est apparu, combinant le meilleur des deux méthodes de travail. Scrumban fonctionne le mieux dans les organisations qui relient la création de produits à la fourniture de services, impliquant souvent la mise en œuvre du produit chez le client. En raison de la réduction des réunions et de la communication, l’équipe peut être plus grande.

Scrumban accorde moins d’importance aux métriques couramment utilisées dans Scrum, telles que le Burndown Chart. Cependant, il utilise les piliers de Scrum concernant la nécessité d’amélioration continue du processus de travail et de leur adaptation aux conditions et besoins du client.

Cependant, lors du travail en Scrumban, le travail n’est pas divisé en Sprints. Les réunions Scrum ont lieu tous les 3, 6 ou 12 mois.

La planification du travail suit le principe “À la demande”, c’est-à-dire au fur et à mesure qu’il se produit. Les User Stories sont placées directement dans la première colonne du tableau Kanban contenant les tâches “à faire”. Ainsi, elle sert de Sprint Backlog, dont nous avons parlé plus en détail dans cet article. Comme dans le Sprint Backlog, les tâches les plus urgentes sont placées en haut de la liste des tâches à faire. Cependant, pour des projets plus complexes, le chef de projet peut maintenir une liste de tâches distincte correspondant au Product Backlog, à partir de laquelle il ou elle sélectionne les tâches à placer dans la première colonne.

Lors du déplacement des tâches de la première à la deuxième colonne, la règle “Pull” s’applique. Cela signifie que les tâches ne sont pas déléguées à un développeur particulier. Chaque personne choisit une tâche dans la file d’attente et l’exécute de manière indépendante.

Le nombre de tâches placées dans la colonne du milieu, “à compléter”, est généralement limité en fonction de la taille de l’équipe, afin que, si possible, chacun ne s’occupe que d’une seule tâche à la fois.

Résumé

Scrum et Kanban, bien qu’utilisés à des fins similaires, sont des méthodes de travail différentes. Scrum fonctionne le mieux dans des projets créatifs et innovants réalisés par de petites équipes Scrum. Kanban, en revanche, a été créé pour fonctionner dans un environnement continu et sans temps d’arrêt afin de fournir des services similaires. Scrum utilise souvent des tableaux Kanban comme méthode pour visualiser le travail en cours. La combinaison des deux a donné naissance à Scrumban, qui fonctionne le mieux comme un cadre pour les organisations qui vendent leurs produits et fournissent des services basés sur ceux-ci au client.

Si vous aimez notre contenu, rejoignez notre communauté de petites abeilles sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.