« Kanban, flux et cadence » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (4 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Portail Framework]] | [[Category: Portail Framework]] | ||
[[Category: Kanban]] | [[Category: Kanban]] | ||
[[Category: INVEST]] | |||
[[Category: Karl Scotland]] | [[Category: Karl Scotland]] | ||
Auteur : Karl Scotland<br/> | Auteur : Karl Scotland<br/> | ||
| Ligne 22 : | Ligne 23 : | ||
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/> | 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/> | <br/> | ||
[[Fichier: Kenji-kanban-2.jpg]]<br/> | [[Fichier: Kenji-kanban-2.jpg|link=]]<br/> | ||
<br/> | <br/> | ||
L’origine du Kanban est le Système de Production Toyota. Taiichi Ohno, dans son livre "Toyota Production System", a écrit :<br/> | L’origine du Kanban est le Système de Production Toyota. Taiichi Ohno, dans son livre "Toyota Production System", a écrit :<br/> | ||
| Ligne 32 : | Ligne 33 : | ||
À 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/> | À 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/> | <br/> | ||
[[Fichier: Basic-kanban.jpg]]<br/> | [[Fichier: Basic-kanban.jpg|link=]]<br/> | ||
<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/> | 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/> | <br/> | ||
[[Fichier: Limits-kanban.jpg]]<br/> | [[Fichier: Limits-kanban.jpg|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 46 : | Ligne 47 : | ||
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/> | 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/> | <br/> | ||
[[Fichier: Context-switching m.jpg]]<br/> | [[Fichier: Context-switching m.jpg|link=]]<br/> | ||
<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/> | 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/> | <br/> | ||
[[Fichier: Ks-multitasking.jpg]]<br/> | [[Fichier: Ks-multitasking.jpg|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 103 : | Ligne 104 : | ||
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/> | 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/> | <br/> | ||
[[Fichier: User-story-mapping.jpg]]<br/> | [[Fichier: User-story-mapping.jpg|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 109 : | Ligne 110 : | ||
Une autre amélioration consiste à utiliser des Kanbans à deux niveaux, avec un niveau pour les MMFs, et un autre pour les Stories utilisateurs.<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/> | <br/> | ||
[[Fichier: 2-tier-kanban-1 m.jpg]]<br/> | [[Fichier: 2-tier-kanban-1 m.jpg|link=]]<br/> | ||
<br/> | <br/> | ||
[[Fichier: 2-tier-kanban-2.jpg]]<br/> | [[Fichier: 2-tier-kanban-2.jpg|link=]]<br/> | ||
<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/> | "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/> | <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. | |||
