Guide de mêlée | 33. Tableaux Scrumban et 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 dont nous aimerions discuter aujourd'hui. Les tableaux Kanban sont également souvent adoptés par les équipes Scrum. En effet, ils sont très pratiques pour visualiser le travail d'équipe et ses progrès. En combinant le meilleur des deux méthodologies, est apparue une technique appelée Scrumban. Il est populaire dans les projets qui combinent le développement de produits avec la prestation de services, où les longs Sprints et les réunions Scrum relativement formalisées ne conviennent pas toujours.

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

1. Introduction
2. Kanban contre Scrum
3. Tableaux Kanban dans Scrum
4. Scrumban
5. Sommaire

Introduction

Kanban est une méthode pionnière au Japon. Il est né dans les années 1950 et était avant tout un outil de gestion de la production continue de manière à ne pas créer de stocks 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 contre Scrum

La manière générale de travailler dans Kanban diffère de Scrum principalement en apportant une approche moins formelle. Dans Kanban, il n'y a pas de directives aussi détaillées sur, par exemple, le travail dans les Sprints, les rôles de Product Owner, Scrum Master et Development Team. 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 reproductibles et ne nécessitent pas une planification aussi complexe.

Cependant, le but 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 modes de fonctionnement communs aux deux méthodes peuvent être formulés comme suit :

1. Le travail doit être fluide et sans aucun temps d'arrêt - dans Scrum, cela est réalisé par la succession continue de Sprints, tandis que dans Kanban, le travail est continu en raison du bon déroulement des tâches. Ils forment une file d'attente, à partir de laquelle les développeurs choisissent (extraient) quelques tâches à accomplir.
2. L'équipe doit se concentrer uniquement sur des tâches sélectionnées - en utilisant la terminologie Kanban, l'équipe doit "réduire le travail en cours". Dans Scrum, l'équivalent de ceci est User Stories choisi dans le Product Backlog pour être mis dans le Sprint Backlog
3. La progression 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ésentés 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 à plusieurs colonnes. Dans chacun d'eux, il y a des tâches avec un certain statut. La catégorisation des tâches repose 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é - à la dernière colonne vont les tâches qui répondent à la définition de l'achèvement, dont nous avons parlé ici.

Vous trouverez ci-dessous un exemple de tableau kanban d'un système de gestion de projet tout-en-un - Firmbee.com

Généralement, 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é pour achèvement" entre les colonnes "à accomplir" et "en cours" . Alors que la colonne "à faire" sert de backlog de produit, dont nous avons parlé ici, la colonne "sélectionné pour l'achèvement" sert de backlog de sprint, que nous décrivons en détail dans cet article.

Le deuxième ajout courant est une colonne "en cours d'examen" ou "pour approbation". Il est généralement inséré entre les colonnes contenant les tâches "en cours" et celles "terminées". Il contient les tâches effectué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é aux 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 l'énorme popularité de Scrum et Kanban, leur hybride est apparu, combinant le meilleur des deux façons de travailler. Scrumban fonctionne mieux dans les organisations qui associent 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 met moins l'accent sur les métriques couramment utilisées dans Scrum, telles que le Burndown Chart. Cependant, il utilise les piliers Scrum de la nécessité d'améliorer continuellement le processus de travail et de les adapter aux conditions et aux besoins du client.

Lorsque vous travaillez dans Scrumban, cependant, le travail n'est pas divisé en Sprints. Les réunions Scrum ont lieu tous les 3, 6 ou 12 mois.

L'ordonnancement des travaux suit le principe « On-Demand », c'est-à-dire au fur et à mesure. Les User Stories sont placées directement dans la première colonne du tableau Kanban contenant les tâches « à faire ». Ainsi, il 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. Cependant, pour les 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 de 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 indépendamment.

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 traite qu'une seule tâche à la fois.

Sommaire

Scrum et Kanban, bien qu'utilisés à des fins similaires, sont des méthodes de travail différentes. Scrum fonctionne mieux dans des projets créatifs et innovants réalisés par de petites équipes Scrum. Kanban, d'autre part, 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 abouti à Scrumban, qui fonctionne mieux comme cadre pour les organisations qui vendent leurs produits et fournissent des services basés sur eux au client.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit