Voir la source de Guide Kanban pour les Equipes Scrum (v1)

[[Category: Portail Framework]]
[[Category: Kanban]]
Auteurs : Steve Porter, Yuval Yeret, Daniel Vacanti &copy; Scrum.org<br />
Source : [https://www.scrum.org/resources/kanban-guide-scrum-teams The Kanban Guide for Scrum Teams]<br />
Date : 01/04/2018<br />
----
Traducteurs : Fabrice Aimetti<br />
Date : 22/08/2019<br />
----
Traduction ''non'' officielle :<br/>
<br/>
[[Fichier:Logo scrumorg.png|200px|link=]]<br/>
<br/>
&copy; 2018 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode.fr and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/deed.fr. 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.<br/>
<br/>
__FORCETOC__
== 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.<br/>
<br/>
''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.<br/>

== 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é.<br/>

== 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.<br/>
<br/>
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.<br/>

== Kanban avec la Théorie Scrum ==
Tout d'abord, une revue rapide d'un principe clé du Guide Scrum :<br/>
 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.<br/>
<br/>
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.<br/>
<br/>
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.<br/>

== 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.
<br/>
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".
<br/>
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.<br/>
<br/>
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.<br/>
<br/>
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.<br/>

== Exigence de Qualité de Service (SLE) ==
Un SLE prévoit le temps qu'il faut pour qu'un élément donné s'écoule du début à la fin de votre flux de travail. Le SLE comporte deux parties : une période de jours écoulés et une probabilité associée à cette période (par ex. "85 % des éléments de travail seront terminés sous huit jours ou moins "). Le SLE est basé sur le temps de cycle historique d'une Equipe Scrum et, une fois calculé, doit être affiché sur le tableau Kanban. S'il n'existe pas de données historiques sur le temps de cycle, l'Equipe Scrum faire sa meilleure hypothèse, puis remplace cette hypothèse une fois qu'il y a suffisamment de données historiques pour faire un calcul approprié du SLE.<br/>
<br/>
'''Quelle que soit la manière dont une Equipe Scrum choisit d'élaborer sa définition du "Flux de travail", cela reste le concept central de ce guide.''' Tous les autres éléments de ce guide dépendent fortement de la manière exacte dont une Equipe Scrum spécifie la définition du "Flux de travail". Elle peut et doit changer au fur et à mesure que l'Equipe Scrum découvre empiriquement de meilleures façons d'organiser et d'écouler le travail. De même, l'utilisation cohérente de la définition de "Flux de travail" est nécessaire lorsqu'elle est utilisée conjointement avec tous les autres éléments du présent guide (par ex., les mesures du flux). La cohérence garantit l'intégrité de l'hyperfocalisation de Kanban sur la transparence.<br/>

== Pratiques Kanban ==
Les Equipes Scrum parviennent à optimiser les flux en utilisant les quatre pratiques suivantes :
* Visualisation du flux de travail
* Limitation des travaux encours
* Gestion dynamique des travaux en cours
* Contrôle et adaptation de la définition du "Flux de travail".<br/>
=== Visualisation du Flux de travail - le Tableau Kanban ===
La visualisation à l'aide du tableau Kanban est la façon dont l'Equipe Scrum rend son flux de travail transparent. La présentation du tableau devrait susciter les bonnes conversations au bon moment et suggérer de façon proactive des possibilités d'amélioration.<br/>

=== Limiter le Travail en cours ===
Les Travaux en cours (WIP) font référence aux éléments de travail que l'équipe Scrum a commencé mais n'a pas encore terminés. Les Equipes Scrum utilisant le Kanban doivent explicitement contrôler ces éléments de travail en cours à partir du moment où ils les considèrent comme "commencés" jusqu'au moment où ils les considèrent "finis". Ce contrôle est généralement représenté par un ou plusieurs chiffres sur un tableau Kanban. Ces chiffres s'appellent "Limites d'encours" (WIP Limits). Une limite d'encours peut inclure des éléments de travail dans une seule colonne, plusieurs colonnes groupées ou un tableau entier. Une fois que l'Equipe Scrum a établi une limite d'encours, elle s'abstient de tirer plus que ce nombre d'éléments de travail dans une partie donnée du flux de travail. L'Equipe Scrum contrôle quelles sont les limites et comment elle les appliquera.<br/>
<br/>
Le principal effet secondaire de la limitation de l'encours est qu'elle crée un "système tiré". C'est ce qu'on appelle un système tiré parce que l'Equipe Scrum commence à travailler sur un élément (donc tiré) uniquement lorsqu'il y a un signal clair qu'il est temps de le faire (notez que ceci est différent d'un système "poussé", qui exige que le travail commence sur un élément chaque fois qu'il est demandé). Lorsque l'encours tombe en dessous d'une limite définie, c'est le signal pour commencer un nouveau travail.<br/>
<br/>
Le Sprint est lui-même une forme de limitation de l'encours. Par définition, un Sprint est un moyen de contrôler la quantité de travail qu'une Equipe de Développement va prendre pendant une période donnée. Le travail n'est uniquement tiré dans le Sprint Backlog que lorsque l'Equipe de Développement choisit de le faire (habituellement, mais pas toujours, pendant la Planification du Sprint). Que cela soit voulu ou non, Scrum a embrassé cette pratique fondamentale du flux depuis le début. La limite d'encours plus fine et explicite de Kanban facilite non seulement le flux de travail, mais peut également améliorer encore davantage la concentration, l'engagement et la collaboration de l'Equipe Scrum.

=== Gestion dynamique des éléments en cours ===
Limiter l'encours est un élément nécessaire à la réalisation du flux, mais cela ne suffit pas à lui seul. La troisième pratique pour établir le flux est la gestion dynamique des travaux en cours. La gestion dynamique peut prendre plusieurs formes, y compris, mais sans s'y limiter, les suivantes :
* Réponse rapide aux éléments de travail bloqués.
* S'assurer que les éléments de travail ne sont tirés dans le flux de travail qu'à peu près au même rythme qu'ils quittent le flux de travail.
* S'assurer que les éléments de travail ne sont pas inutilement laissés à l'abandon et qu'ils sont réalisés conformément à un SLE établi.
* Désengorger les travaux qui s'accumulent dans une ou plusieurs colonnes.
Bien que plusieurs de ces sujets puissent être abordés pendant la Mêlée Quotidienne (voir la section ''Mêlée Quotidienne Basée sur le Flux'' ci-dessous), il est de la responsabilité de l'Equipe Scrum d'assurer la gestion proactive, active et réactive en continu des éléments de travail en cours.<br/>

=== Inspection et Adaptation du Flux de travail ===
Considérez les règles comme les "règles du jeu" pour le "Flux de travail" de l'Equipe Scrum. De petits changements à ces règles peuvent avoir une incidence importante sur le rendement global de l'équipe Scrum. ''Le Guide Scrum'' fournit un ensemble minimum de règles explicites ainsi que des instructions sur la façon de définir certaines règles spécifiques au contexte (par ex., la définition du "Fini" par l'Equipe Scrum). Lors de l'application de Kanban, ''l'Equipe Scrum'' voudra compléter ''Le Guide Scrum'' avec des règles plus explicites pour son processus. Ces règles seront reprises dans la définition du "Flux de travail" d'une Equipe Scrum.<br/>
<br/>
''Explicite'' signifie que ces règles sont écrites ou visualisées d'une manière ou d'une autre et que toute l'Equipe Scrum les comprend. Le tableau Kanban doit afficher toutes les règles pertinentes ou indiquer aux membres de l'Equipe Scrum où les trouver.<br/>
<br/>
Un bon exemple d'une règle qui doit être explicite est la façon dont l'Equipe Scrum définit le moment où les éléments passent de l'état non démarré à l'état démarré et de l'état en cours à l'état fini. Nul doute que l'Equipe Scrum ajoutera d'autres règles en plus de celles spécifiques préconisées par ce guide.<br/>

== Mesure et Analyse du Flux ==
L'application de Kanban dans un contexte Scrum nécessite la collecte et l'analyse d'un ensemble minimum de mesures du flux. Ces mesures sont nécessaires à la pratique de la gestion dynamique des travaux en cours. Elles rendent également le flux transparent et permettent une inspection et une adaptation orientées flux. Ces mesures reflètent la santé et la performance actuelles de l'approche de l'Equipe Scrum. Elles indiqueront également les interventions qui peuvent améliorer le fonctionnement de l'Equipe Scrum et la valeur qu'elle apporte.

=== Les Mesures de Base du Flux ===
Les quatre mesures de base du flux que les Equipes Scrum utilisant le Kanban devront suivre sont les suivantes :
* Encours (WIP) : le nombre d'éléments de travail commencés mais non finis (selon la définition du "Flux de travail" de l'Equipe Scrum).
* Temps de cycle : le temps écoulé entre le moment où un élément de travail "commence" et le moment où il "finit".
* Âge de l'élément de travail : le temps écoulé entre le moment où un élément de travail "a commencé" et l'heure actuelle.
* Débit : le nombre d'éléments de travail "finis" par unité de temps. Notez que la mesure du débit est le nombre exact d'éléments de travail.
Pour calculer les temps de cycle et l'âge des éléments de travail, l'équipe Scrum doit (au minimum) suivre la date de début et la date de fin de chaque élément.<br/>
<br/>
Ces mesures devraient être surveillés tout au long du Sprint - en particulier lors des Evénements Scrum (voir la section ''Événements Basés sur le Flux'' ci-dessous). Comme toujours, il y a d'autres mesures de flux que l'Equipe Scrum peut vouloir examiner, mais c'est le minimum requis.

== Evénements Basés sur le Flux ==
Kanban dans un contexte Scrum ne nécessite pas d'événements supplémentaires à ceux décrits dans ''Le Guide Scrum''. Cependant, l'utilisation d'une perspective basée sur le flux peut améliorer les événements Scrum.
=== Le Sprint ===
Un Sprint est une cadence ou un "battement de coeur" régulier pour l'inspection et l'adaptation. Le cycle régulier et les éléments du Sprint sont naturellement adaptés à la gestion du flux. Un Sprint contient la Planification de Sprint, les Mêlées Quotidiennes, le travail de développement, la Revue de Sprint et la Rétrospective de Sprint. Les événements d'un Sprint peuvent servir de boucles de feedback pour l'inspection des mesures de flux Kanban, et l'approche Kanban peut également servir de boucle de feedback pour l'inspection de l'implémentation Scrum.

=== La Planification du Sprint Basé sur le Flux ===
Une réunion de Planification du Sprint basée sur le flux utilise des mesures de flux comme aide pour développer le Backlog de Sprint. Par exemple, en utilisant l'historique du Débit pour comprendre la capacité de l'Equipe Scrum pour le prochain Sprint. Le SLE d'une Equipe Scrum peut influencer le travail prévu pour les premiers jours du Sprint.<br/>

=== Les Mêlées Quotidiennes Basées sur le Flux ===
Une Mêlée Quotidienne basée sur le flux vise à s'assurer que l'Equipe Scrum fait tout ce qu'elle peut pour maintenir l'écoulement du flux chaque jour. Bien que l'objectif de la Mêlée Quotidienne reste le même que dans ''Le Guide Scrum'', la réunion elle-même a lieu autour du tableau Kanban et se concentre sur les points faibles du flux et sur les actions que l'équipe Scrum peut entreprendre pour que le travail s'écoule à nouveau.<br/>
<br/>
Voici d'autres éléments à prendre en compte lors d'une Mêlée Quotidienne basée sur le flux :
* Quels éléments de travail sont bloqués et que peut faire l'Equipe Scrum pour les débloquer ?
* Quel est l'âge de chaque élément de travail en cours ? Quels éléments de travail ont violé ou sont sur le point de violer leur SLE et que peut faire l'équipe Scrum pour finir ce travail ?
* Y a-t-il des choses qui pourraient avoir un impact sur la capacité de l'Equipe Scrum à finir son travail aujourd'hui et qui ne sont pas représentées sur le tableau ?

=== La Revue de Sprint Basée sur le Flux ===
''Le Guide Scrum'' fournit un aperçu détaillé du processus de Revue de Sprint. En plus de ces activités, l'inspection des mesures de flux Kanban dans le cadre de la Revue de Sprint crée de nouvelles opportunités pour de nouvelles conversations sur le suivi de l'état d'avancement vers un objectif. L'examen du débit peut fournir des informations supplémentaires lorsque le Product Owner discute des dates cibles et des dates de livraison probables. L'examen du SLE d'une Equipe Scrum peut amener le Product Owner à modifier le Backlog Produit.

=== Les Rétrospectives de Sprint Basées sur le Flux ===
Une Retrospective de Sprint basée sur le flux ajoute l'inspection des mesures de flux et des analyses pour aider à déterminer quelles améliorations l'Equipe Scrum peut apporter à ses processus, y compris la Rétrospective de Sprint elle-même. L'Equipe Scrum utilisant Kanban inspecte et adapte également la définition du "Flux de travail" pour optimiser le flux dans le prochain Sprint. L'utilisation d'un diagramme de flux cumulé pour visualiser le l'Encours d'une Equipe Scrum, le Temps de Cycle approximatif moyen et le Débit moyen peuvent être utiles.<br/>
<br/>
''Le Guide Scrum'' stipule que la Rétrospective de Sprint doit avoir lieu après la Revue de Sprint et avant la prochaine Planification de Sprint. Ceci ne change pas lorsque vous utilisez Kanban. Toutefois, il n'est pas nécessaire que les opportunités de rétrospective basée sur le flux correspondent aux limites d'un Sprint. Elles peuvent se produire "juste à temps". En conséquence, des changements à la définition du "Flux de travail" d'une équipe peuvent survenir à tout moment, cependant, comme ces changements auront un impact concret sur les performances de l'Equipe Scrum, les changements apportés pendant la cadence régulière fournie par l'événement de Rétrospective de Sprint réduiront la complexité et amélioreront la transparence.<br/>

== Notes de fin de texte ==
Scrum n'est pas un processus ou une technique. Il s'agit d'un cadre dans lequel les gens peuvent s'attaquer à des problèmes d'adaptation complexes, tout en fournissant de façon productive et créative des produits de la plus grande valeur possible. Comme l'indique ''Le Guide Scrum'', il fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques.<br/>
<br/>
Les pratiques d'optimisation des flux de Kanban offrent aux Equipes Scrum des opportunités supplémentaires d'inspecter la bonne chose, au bon moment, puis, sur la base de cette inspection, de s'adapter si nécessaire. L'hyperfocalisation de Kanban sur la transparence, la visualisation et le flux maximise le feedback, l'empirisme et, en fin de compte, la création de valeur pour le client.<br/>

== Historique et Remerciements ==
L'ensemble des pratiques communément appelées Kanban a principalement pris naissance au sein d'une équipe de Corbis en 2006. Ces pratiques se sont rapidement répandues pour englober une communauté internationale nombreuse et diversifiée qui, au fil des ans, a continué à améliorer et à faire évoluer l'approche.<br/>
<br/>
Ce guide a été développé en collaboration avec Scrum.org, notre Communauté de Formateurs Professionnels, Steve Porter, Yuval Yeret, et Daniel Vacanti.<br/>
<br/>
Un remerciement spécial à Louis-Philippe Carignan et Charles Bradley pour leur contribution à cet effort. Nous devons une reconnaissance éternelle envers tous les praticiens qui ont, par le passé, contribué à faire de Kanban une stratégie agile et lean viable et efficace.<br/>
<br/>
&copy; 2018 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode.fr and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/deed.fr. 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.<br/>