Voir la source de Kanban, flux et cadence

[[Category: Portail Framework]]
[[Category: Kanban]]
[[Category: Karl Scotland]]
Auteur : Karl Scotland<br/>
Source : [http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/ Kanban, Flow and Cadence]<br/>
Date : 28/10/2008<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 06/03/2011<br/>
----
Traduction :<br/>
<br/>
'''Introduction'''<br/>
<br/>
Il y a récemment eu une augmentation notable de l’intérêt pour Kanban avec, d’une part un certain nombre de personnes réclamant plus d’informations, et d’autre part davantage de personnes écrivant de nouveaux blogs et articles sur le sujet. Je tente ici de décrire plus en détail mon opinion :<br/>
* Kanban... Travail maîtrisé
* Flux... Travail efficace
* Cadence... Travail fiable
<br/>
'''Kanban'''<br/>
<br/>
Un système Kanban est un mécanisme pour maîtriser le travail effectué dans un système de développement logiciel. Le terme Kanban peut être défini comme une "carte visuelle", comme illustré ci-dessous (et gentiment écrit pour moi par Kenji Hiranabe lors de l’événement Agile 2008).<br/>
<br/>
[[Fichier: Kenji-kanban-2.jpg|link=]]<br/>
<br/>
L’origine du Kanban est le Système de Production Toyota. Taiichi Ohno, dans son livre "Toyota Production System", a écrit :<br/>
<br/>
"Les deux piliers du Système de Production Toyota sont le juste-à-temps et l’automatisation avec une touche humaine, ou autonomation. L’outil utilisé pour faire fonctionner le système est le Kanban."<br/>
<br/>
Kanban est ce qui permet à un système tiré de travailler en juste-à-temps.<br/>
<br/>
À quoi ressemble un système Kanban dans le développement logiciel ? Très simplement, il y a une file d’attente de travail, qui passe par un certain nombre de stades de développement jusqu’à ce qu’elle soit finalement traitée. Lorsque le travail est achevé à une étape, il passe dans la file d’attente aval en entrée de l’étape suivante. Lorsque quelqu’un a besoin de travailler, il tire les travaux à réaliser de la file d’attente amont. Ceci peut être illustrée comme suit.<br/>
<br/>
[[Fichier: Basic-kanban.jpg|link=]]<br/>
<br/>
Cela ressemble fort à un tableau de tâches typique en Agile, avec peut-être quelques étapes supplémentaires, bien sûr il ne peut pas y avoir une étape de développement unique. Cependant, il y a un autre élément important qui définit vraiment le système Kanban – les limites. Il y a deux limites de base – les limites des files d’attente et les limites de WIP (WIP = Work In Progress. NdT : traduit en TAF (Travail A Faire) par Claude Aubry dans la traduction de l’ouvrage [ttp://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=glossaire#-1 Kanban et Scrum : tirer le meilleur des deux]).<br/>
<br/>
[[Fichier: Limits-kanban.jpg|link=]]<br/>
<br/>
Les limites de file d’attente sont conçues pour éviter le travail prématuré. C’est de cette façon que le juste-à-temps est atteint. La limite doit être suffisamment grande pour garder l’équipe occupée (autrement dit, il y a toujours quelque chose pour que l’équipe commence à travailler dessus), mais suffisamment petite pour éviter une priorisation prématurée (c’est-à-dire avoir des éléments qui stagnent trop longtemps dans la file d’attente avant d’être traité). Idéalement, la file d’attente doit être gérée en mode FIFO, même si ce n’est qu’une préconisation et non une règle stricte, car parfois ce n’est pas possible en fonction de la disponibilité des compétences ou des autres ressources.<br/>
<br/>
Les limites de WIP sont conçues pour réduire le multi-tâches, maximiser le throughput et améliorer le travail d’équipe.<br/>
<br/>
Réduire le multitâche est bénéfique pour deux raisons principales :<br/>
<br/>
1) 20% du temps est perdu pour passer d’une « tâche » à une autre, donc moins on a de tâches moins on perd de temps (lire Gerald Weinberg dans son livre Quality Software Management: Systems Thinking).<br/>
<br/>
[[Fichier: Context-switching m.jpg|link=]]<br/>
<br/>
2) Exécuter des tâches séquentiellement produit des résultats plus tôt. Comme le montre le diagramme ci-dessous – le multi-tâches A, B et C (en haut), conduit à livrer A (et même C) un peu plus tard – plutôt que de façon séquentielle (en bas).<br/>
<br/>
[[Fichier: Ks-multitasking.jpg|link=]]<br/>
<br/>
Un excellent exercice pour démontrer les effets du multi-tâches a été décrit par [http://www.clarkeching.com/2007/09/multi-tasking-e.html Clarke Ching].<br/>
<br/>
Le throughput est également optimisé en diminuant le WIP. Des exemples simples de cet effet sont les embouteillages, où la vitesse de la circulation se réduit au fur et à mesure que le trafic augmente, ainsi que la charge CPU, où les performances des applications diminuent à mesure qu’augmente la charge CPU. L’effet peut être expliquer avec la Loi de Little sur la Théorie des files d’attente :<br/>
<br/>
"Temps de Cycle Total = Nombre d’éléments en cours / Taux moyen d’achèvement"<br/>
<br/>
Par conséquent, pour améliorer le temps de cycle, il y a deux options ; réduire le nombre d’éléments dans le processus ou améliorer le taux moyen d’achèvement. La réduction du nombre d’éléments en cours est l’option la plus facile, et une fois maîtrisée, les changements les plus difficiles pour améliorer le taux d’achèvement peuvent être appliqués.<br/>
<br/>
Finalement, en ayant moins d’éléments en cours de travail, l’équipe est en mesure de se concentrer davantage sur les objectifs plus larges, et moins sur les tâches individuelles, encourageant ainsi un effet d’essaimage, et l’amélioration du travail d’équipe.<br/>
<br/>
Limiter le WIP de cette manière peut sembler inhabituelle pour les équipes, et il y a souvent une inquiétude que les membres de l’équipe soient inactifs parce qu’il n’y a pas de travail à faire et soient incapables de tirer de nouveaux travaux de la file d’attente. Les directives suivantes peuvent aider l’équipe dans cette situation :<br/>
<br/>
1. Pouvez-vous aider à faire progresser un kanban existant ?  "Travaillez là-dessus alors."<br/>
2. Vous n’avez pas les compétences requises ? "Trouvez le goulot d’étranglement et travaillez pour le lever."<br/>
3. Vous n’avez pas les compétences requises ? "Tirez du travail de la file d’attente."<br/>
4. Impossible de démarrer quoi que ce soit dans la file d’attente ? "Y a-t-il une priorité moindre que vous pouvez commencer à traiter ?"<br/>
5. Il n’y a rien de plus faible priorité ? "Trouvez d’autres travaux intéressants."<br/>
<br/>
Les questions importantes ici sont ce qui constitue un travail à faible priorité ou un autre travail intéressant. Il s’agit essentiellement d’un travail qui ne créera pas de travail en aval, qui permettra d’améliorer le futur throughput et qui pourra être suspendu dès qu’un travail existant dans le kanban est disponible. Les travaux de priorité moindre peuvent être des spikes ou des analyses pour un travail qui va commencer de façon imminente. D’autres travaux intéressants peuvent être le refactoring, l’automatisation des outils, le développement personnel ou l’innovation.<br/>
<br/>
La taille des limites de WIP peut dépendre du type de travail et de la taille de l’équipe et doit être ajustée pour obtenir un flux maximal. Une approche est de commencer petit (par exemple une limite de 1) et de l’augmenter si nécessaire. Une autre est de commencer avec une limite plus grande (par exemple une limite correspondant à la moitié de la taille de l’équipe) et de la réduire jusqu’à ce que la zone optimale soit atteinte.<br/>
<br/>
"Les conséquences de l’utilisation d’un système kanban sont que le Backlog Produit peut être éliminé, parce que la file d’attente immédiate est la seule digne d’intérêt, les itérations de durée fixe (ou sprints) peuvent être éliminées parce que le travail est tiré dès que nécessaire, et l’estimation peut être éliminée parce que le travail n’est pas planifié dans des itérations."<br/>
<br/>
'''Flux'''<br/>
<br/>
Le flux décrit comment le travail dans le système peut livrer un maximum de valeur. Comme [http://www.poppendieck.com/ Mary et Tom Poppendieck] l’ont écrit :<br/>
<br/>
"Dans les entreprises lean, les structures organisationnelles traditionnelles cèdent la place à de nouvelles organisations axées sur des équipes centrées sur le flux de valeur, et non pas sur l’expertise fonctionnelle."<br/>
<br/>
En particulier, le Lean met l’accent sur le "Flux pièce à pièce". Cela signifie de déplacer une pièce à la fois entre les étapes d’un workflow au lieu de passer des lots de travaux entre les différentes étapes dans un workflow. Le "Flux pièce à pièce" dans un système Kanban pour le développement logiciel peut être considéré comme une MMF (Minimal Marketable Feature (NdT : MMF = ensemble de fonctionnalités minimales apportant de la valeur à l’utilisateur) tel que décrit par M Denne & H Cleland-Huang dans Software by Numbers.<br/>
<br/>
"Une MMF est un morceau de fonctionnalité qui satisfait un sous-ensemble des exigences du client, et qui est capable de livrer de la valeur au client lorsqu’elle est livrée en tant qu’entité indépendante".<br/>
<br/>
Les éléments kanbans doivent être minimes, de sorte qu’ils sont aussi petits que possible afin de permettre une livraison incrémentale, de réaliser le produit plus tôt, de réduire l’inflation fonctionnelle et de se concentrer sur les fonctionnalités du noyau qui sont les plus importantes, et de minimiser la complexité car chaque fonctionnalité a un coût pour un utilisateur.<br/>
<br/>
Les éléments kanbans peuvent être commercialisables de différentes manières.<br/>
<br/>
* Les fonctionnalités de base – il s’agit du ticket d’entrée pour être dans le jeu
* Les différenciateurs – qui différencient le produit de la concurrence et ravient l’utilisateur
* Les spoilers – ils annulent le facteur de différenciation des concurrents
* Les réducteurs de coûts – réduisent les coûts et améliorent la marge bénéficiaire
<br/>
Une pratique utile est de dire qu’une MMF est commercialisable si elle peut être écrite sur le blog d’un produit.<br/>
<br/>
Les éléments kanbans doivent être des fonctionnalités qui sont distinctes, livrables et observables. L’acronyme INVEST (Indépendante, Négociable, de grande Valeur, qu’on peut Estimer, Suffisamment petite et Testable) tel que décrit par [http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ Bill Wake], peut également être appliqué aux MMFs.<br/>
<br/>
Le terme Commercialisable (Marketable) des MMFs signifie qu’elles sont probablement plus grandes que les typiques Stories utilisateurs, qui décomposent souvent le travail pour être livrées de façon incrémentale tout en apportant une certaine valeur, même si elles ne sont pas commercialisables en tant que tel. Par conséquent, il est important d’appréhender la chaîne de valeur (Value Stream) des MMFs pour livrer la MMF entièrement le plus rapidement possible. Une chaîne de valeur décrit les étapes, les retards et les informations nécessaires pour livrer un produit, et peut souvent être utilisée pour décider des mesures à prendre dans un système kanban initial. Avec de grosses MMFs, les Stories utilisateurs sont plus le fruit d’une technique d’analyse afin de permettre la livraison incrémentale d’une MMF, sans perdre de vue la globalité de la MMF. Je décris comment un flux continu peut être réalisé avec des MMFs dans [http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/ The Anatomy of an MMF].<br/>
<br/>
Un certain nombre de techniques peuvent aider à gérer les relations entre les MMFs et les Stories utilisateurs afin de tirer bénéfice des deux. L’une d’entre elles est le Story Mapping décrit par [http://agileproductdesign.com/blog/the_new_backlog.html Jeff Patton].<br/>
<br/>
[[Fichier: User-story-mapping.jpg|link=]]<br/>
<br/>
J’ai aussi récemment travaillé dans un environnement réglementé où les buts et sous-buts des cas d’usage ont produit des MMFs, avec des scénarios détaillés pour fournir les détails supplémentaires.<br/>
<br/>
Une autre amélioration consiste à utiliser des Kanbans à deux niveaux, avec un niveau pour les MMFs, et un autre pour les Stories utilisateurs.<br/>
<br/>
[[Fichier: 2-tier-kanban-1 m.jpg|link=]]<br/>
<br/>
[[Fichier: 2-tier-kanban-2.jpg|link=]]<br/>
<br/>
"La conséquence de l’application du concept de Flux, c’est que l’accent est mis sur l’utilisation de MMFs plus grandes et axées sur la valeur, plutôt que de petites Stories livrées de façon incrémentale."<br/>
<br/>
'''Cadence'''<br/>
<br/>
La cadence est l’approche qui consiste à atteindre engagement et efficacité avec un système kanban. Je reçois souvent des questions à ce sujet :<br/>
<br/>
"Si l’équipe n’estime pas ou ne planifie pas au sein de boîtes de temps de durée fixe, comment peut-elle prendre des engagements fiables ?"<br/>
<br/>
Pour citer une fois de plus Mary et Tom Poppendieck :<br/>
<br/>
"Une cadence régulière, ou "battement de cœur", établit la capacité d’une équipe à livrer efficacement un logiciel opérationnel à une vitesse fiable. Une organisation qui livre à une cadence régulière démontre son aptitude au processus et peut facilement mesurer sa capacité."<br/>
<br/>
L’itération de durée fixe est une forme de cadence, qui combine planification, revue et livraison. Un système kanban découple ces événements, leur permet d’avoir des cadences distinctes et également d’en ajouter deux nouveaux. Le throughput est la quantité de production d’un processus dans une période de temps donnée, et le temps de cycle est le temps pris pour terminer un processus. La relation entre les deux est :<br/>
<br/>
Throughput = WIP / Temps de cycle<br/>
<br/>
Le throughput permet de prévoir la capacité future, sans avoir à spécifier ce qui pourra être livré. Le temps de cycle est une forme d’engagement qui peut se matérialiser sous forme de SLA dans l’entreprise (voir [http://availagility.co.uk/2008/04/09/kanban-commitment/ Kanban commitment]). Lorsque la taille du travail varie, de grandes nouvelles fonctionnalités à de petites corrections et de petites demandes de changement, alors une classification des MMFs peut amener une variété de temps de cycle. Le throughput ainsi que le temps de cycle peuvent être tracés et projetés, d’une manière similaire à la vélocité en XP, en tant que moyen pour encourager l’équipe à s’améliorer. Un Diagramme de Flux Cumulé peut également rendre visible la manière dont le travail s’écoule à travers le système et mettre en évidence les goulots d’étranglement.<br/>
<br/>
[[Fichier:Ks-cfd.jpg|link=]]<br/>
<br/>
Pour des prévisions à plus long terme, une planification trimestrielle de la cadence se concentre sur les objectifs trimestriels. Des MMFs peuvent ensuite être priorisées pour atteindre ces objectifs. Une cadence de livraison régulière va renforcer la confiance en l’équipe qui travaillera à pleine capacité et throughput.<br/>
<br/>
D’autres cadences, comme les daily stand-up, les rétrospectives et les revues régulières sont décrites par [http://www.agilemanagement.net/index.php/blog/Sample_Chapter/ David Anderson]. Certaines équipes utilisent un Kanban de Rétrospective pour signaler lorsqu’une rétrospective est nécessaire, et j’ai déjà brièvement blogué sur le sujet : [http://availagility.co.uk/2008/08/28/kanban-and-retrospectives/ Kanban and Retrospectives].<br/>
<br/>
'La conséquence de la Cadence est que l’engagement et la fiabilité sont atteints via la mesure plutôt que par a planification."<br/>
<br/>
'''Résumé'''<br/>
<br/>
Les points clés de Kanban, Flux et Cadence sont :<br/>
<br/>
* Un système Kanban gère le flux de travail d’une manière qui permet d’éliminer la notion de Backlog Produit, Itérations de durée fixe et Estimations.
* Le flux doit permettre de livrer efficacement une valeur maximale en mettant l’accent sur l’optimisation de la chaîne de valeur des MMFs les plus grandes.
* La cadence permet de découpler les entrées et les sorties des itérations et d’atteindre engagement et fiabilité via la mesure plutôt que par la planification.
<br/>
Vous trouverez d’autres articles sur ma page [http://availagility.co.uk/kanban/ Kanban], y compris la plupart des informations qui ont influencé et guidé ma réflexion.