Guide Kanban pour les Equipes Scrum (v1)

De Wiki Agile du @GroupeCESI
Révision datée du 22 août 2019 à 12:52 par Fabrice Aimetti (discussion | contributions) (Définition du Flux de travail)
Aller à : navigation, rechercher

Auteurs : Steve Porter, Yuval Yeret, Daniel Vacanti © Scrum.org
Source : The Kanban Guide for Scrum Teams
Date : 01/04/2018


Traducteurs : Fabrice Aimetti
Date : 22/08/2019


Traduction non officielle :

Logo scrumorg.png

Objectif

L'angle d'approche basé sur le flux par Kanban peut améliorer et compléter le cadre Scrum et sa mise en œuvre. Les équipes peuvent appliquer le Kanban qu'elles commencent tout juste à utiliser Scrum ou qu'elles l'utilisent depuis le début.

Le Guide Kanban pour les Equipes Scrum est le fruit d'une collaboration entre les membres de la communauté Scrum.org et les leaders de la communauté Kanban. Ensemble, ils soutiennent Le Guide Kanban pour les Equipes Scrum. Ils partagent la conviction que les professionnels du logiciel peuvent bénéficier de l'application du Kanban avec Scrum.

Par rapport au Guide Scrum

Ce guide n'a pas pour but de remplacer ou d'écarter / de réduire une partie quelconque du Guide Scrum. Il est conçu pour améliorer et étendre les pratiques du cadre Scrum. Ce guide suppose que le lecteur gère un processus utilisant le framework Scrum. Par conséquent, Le Guide Scrum s'applique dans son intégralité.

Définition de Kanban

Kanban (n) : stratégie visant à optimiser le flux de la valeur pour les parties prenantes par le biais d'un processus qui utilise un système visuel, un système tiré qui limite l'encours.

Le concept de "flux" est au coeur de la définition du Kanban. Le flux est le mouvement de la valeur client à travers le système de développement de produits. Kanban optimise le flux en améliorant l'efficience, l'efficacité et la prédictibilité globales d'un processus.

Kanban avec la Théorie Scrum

Tout d'abord, une revue rapide d'un principe clé du Guide Scrum :

Scrum est fondée sur la théorie empirique du contrôle des processus, ou empirisme. L'empirisme affirme que la connaissance vient de l'expérience et de la prise de décisions basées sur ce qui est connu. Trois piliers soutiennent chaque mise en oeuvre du contrôle empirique des processus : la transparence, l'inspection et l'adaptation.

Scrum exige que le Backlog de Sprint soit transparent, mais il fournit peu d'indications sur la façon d'y parvenir. Il ne définit pas non plus comment parvenir à une transparence explicite du flux de travail dans le Backlog Produit, du Backlog Produit dans le Backlog de Sprint, et quoi qu'il advienne, du travail après qu'il ait résulté en un Incrément "Fini". C'est là que le Kanban peut vous aider. En visualisant le travail de nouvelles manières, une Equipe Scrum peut appliquer l'ensemble des pratiques décrites dans ce guide afin d'optimiser plus efficacement la création de valeur. Ces pratiques s'inspirent et s'appuient sur les principes de la pensée lean, du flux de développement de produits et de la théorie des files d'attente.

Un effet secondaire bénéfique de l'optimisation de la livraison de valeur est qu'elle offre beaucoup plus d'occasions d'inspecter et d'adapter les processus et les produits. Raccourcir la boucle de feedback des clients avec le Kanban est une stratégie éprouvée pour améliorer empiriquement un processus.

L'hyperfocalisation du Kanban sur la transparence, la visualisation et le flux, combinée au framework Scrum, forme une base solide sur laquelle concevoir un processus pour offrir une valeur client optimale.

Définition du Flux de travail

L'optimisation du flux nécessite de définir ce que le flux signifie dans un contexte Scrum. Chaque Equipe Scrum doit créer sa définition de "Flux de travail" contenant les éléments suivants :

  • Définir les endroits pour lesquels l'équipe Scrum considère que le travail a commencé et est terminé.
  • Une définition des unités individuelles de valeur client qui s'écoulent dans le système de l'Equipe Scrum (très probablement les Eléments du Backlog Produit(PBI)).
  • Une définition des états du Flux de travail énonce que les PBIs s'écoulent du début vers la fin (et il doit y avoir au moins un état actif).
  • Des règles explicites sur la façon dont le travail s'écoule à travers chaque état (ce qui peut inclure des éléments de la définition du "Fini" d'une Equipe Scrum et des règles de transition tirée entre les étapes).
  • Une définition de la façon dont les Travaux en Cours (WIP) seront limités.
  • Un ensemble d'Exigences de Qualité de Service (SLE) établie qui communique une prévision du temps qu'il faudra pour terminer les éléments de travail.


Bien qu'il appartienne à l'Equipe Scrum de définir son flux de travail, il y a quelques éléments qu'elle doit inclure :

  • Identifier les éléments de travail qui ne sont pas encore dans un état actif comme étant "non démarrés".
  • Identifier les éléments de travail qui entrent dans l'état actif ("commencé") comme étant le Travail en Cours (WIP).
  • Identifier les éléments de travail qui sont passés par tous les états actifs prévus pour cet éléments comme étant "finis".


En résumé, la définition de "Flux de travail" inclut une compréhension commune au sein de l'Equipe Scrum de la façon dont le travail est défini (les éléments de travail), l'état de départ du processus, les états actifs des éléments de travail, et l'état fini du processus.

Notez que les états de la définition du "Flux de travail" peuvent ne pas coïncider avec les états définis par un Backlog de Sprint. Par exemple, la définition d'une Equipe Scrum du "Flux de travail" peut inclure des états qui sont en amont, en aval, à l'intérieur ou à l'extérieur du Backlog de Sprint. De même, les éléments de travail qui se déplacent dans le flux de travail peuvent ne pas correspondre aux Eléments du Backlog Produit ou à d'autres parties du Backlog de Sprint ou de Scrum. Enfin, un élément de travail particulier peut ne pas passer par tous les états actifs et un élément de travail peut même ne pas passer successivement par les états actifs.

La création et l'adaptation de la définition du "Flux de travail" peuvent avoir un impact ou être impactées par des artefacts existants. Les responsabilités du Product Owner et de l'Equipe de Développement à l'égard de ces artefacts demeurent les mêmes que celles décrites dans le Guide Scrum.

Exigence de Qualité de Service

Pratiques Kanban

Visualisation du Flux de travail - le Tableau Kanban

Limiter le Travail en cours

Gestion dynamique des éléments en cours

Inspection et Adaptation du Flux de travail

Mesure et Analyse du Flux

Les Indicateurs de Base du Flux

Evénements Basés sur le Flux

Le Sprint

La Planification du Sprint Basé sur le Flux

Les Mêlées Quotidiennes Basées sur le Flux

La Revue de Sprint Basée sur le Flux

Les Rétrospectives de Sprint Basées sur le Flux

Notes de fin de texte

Historique et Remerciements


© 2018 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.