Guide Kanban pour les Equipes Scrum (v1)

De Wiki Agile du @GroupeCESI
Révision datée du 22 août 2019 à 12:38 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 des Niveaux 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'équipe Scrum de définir son flux de travail, il y a quelques éléments qu'elle doit inclure :

  • Identifier les work items qui ne sont pas encore dans un état actif comme étant "non démarrés".
  • Identifier les work items qui entrent dans l'état actif (" commencé ") comme étant en cours d'exécution (encours de fabrication).
  • Identifier les work items qui sont passés par tous les états actifs prévus pour cet item comme étant " terminés ".


En résumé, la définition de "Workflow" inclut une compréhension commune au sein de l'équipe Scrum de la façon dont le travail est défini (work items), l'état de départ du processus, les états actifs des work items, et l'état fini du processus. Notez que les états de la définition de "Workflow" peuvent ne pas coïncider avec les états définis par un carnet de commandes Sprint. Par exemple, la définition d'une équipe Scrum de "Workflow" peut inclure des états qui sont en amont, en aval, à l'intérieur ou à l'extérieur du Sprint Backlog. De même, les éléments de travail qui se déplacent dans le flux de travail peuvent ne pas correspondre aux éléments de l'arriéré de produits ou à d'autres parties de l'arriéré de Sprint ou de Scrum. Enfin, un work item particulier peut ne pas passer par tous les états actifs et un work item peut même ne pas passer successivement par les états actifs.
La création et l'adaptation de la définition de "Workflow" peuvent avoir un impact ou être influencées par des artefacts existants. Les responsabilités du propriétaire du produit et de l'équipe 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.