« Kanban, flux et cadence » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 32 : | Ligne 32 : | ||
À 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 46 : | ||
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/> | ||
| Ligne 103 : | Ligne 103 : | ||
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 109 : | ||
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/> | ||
| Ligne 131 : | Ligne 131 : | ||
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/> | 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/> | <br/> | ||
[[Fichier:Ks-cfd.jpg]]<br/> | [[Fichier:Ks-cfd.jpg|link=]]<br/> | ||
<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/> | 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/> | ||