« Appliquer Kanban aux processus informatiques (4) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (2 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 3 : | Ligne 3 : | ||
[[Category: Eli Weinstock-Herman]] | [[Category: Eli Weinstock-Herman]] | ||
Auteur : Eli Weinstock-Herman<br/> | Auteur : Eli Weinstock-Herman<br/> | ||
Source : [ | Source : [https://blogs.lessthandot.com/index.php/itprofessionals/projectmanagement/applying-kanban-to-it-processes-part-4/ Applying Kanban to IT Processes (Part 4)]<br/> | ||
Date : 22/12/2009<br/> | Date : 22/12/2009<br/> | ||
---- | ---- | ||
| Ligne 35 : | Ligne 35 : | ||
Suite à plusieurs longues réunions, l’équipe a élaboré son processus comme une série d’étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.<br/> | Suite à plusieurs longues réunions, l’équipe a élaboré son processus comme une série d’étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Pt 4 Sashimi.png]]<br/> | [[Fichier:Pt 4 Sashimi.png|border|link=]]<br/> | ||
<br/> | <br/> | ||
Processus en cascade itératif (Sashimi)<br/> | Processus en cascade itératif (Sashimi)<br/> | ||
| Ligne 57 : | Ligne 57 : | ||
A des fins de visualisation et de suivi, l’équipe découpe plusieurs étapes en sous-étapes. Les étapes d’exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape « prêt » qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape « en cours » et une étape « terminé ». Les éléments de la sous-étape « terminé » » sont mis à disposition pour être sélectionnés et testés par la QA.<br/> | A des fins de visualisation et de suivi, l’équipe découpe plusieurs étapes en sous-étapes. Les étapes d’exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape « prêt » qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape « en cours » et une étape « terminé ». Les éléments de la sous-étape « terminé » » sont mis à disposition pour être sélectionnés et testés par la QA.<br/> | ||
<br/> | <br/> | ||
[[Fichier:KanbanPt4 VisBoard 4a.png]]<br/> | [[Fichier:KanbanPt4 VisBoard 4a.png|border|link=]]<br/> | ||
Le premier tableau visuel<br/> | Le premier tableau visuel<br/> | ||
<br/> | <br/> | ||
L’équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d’utiliser des couloirs pour visualiser les travaux en cours, l’équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l’équipe. Par exemple, lorsque l’architecte de l’équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d’animaux colorés aux membres de l’équipe pour estampiller les tâches qu’ils terminent, permettant au reste de l’équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d’origine sans faire appel à des mécanismes complexes de traçabilité.<br/> | L’équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d’utiliser des couloirs pour visualiser les travaux en cours, l’équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l’équipe. Par exemple, lorsque l’architecte de l’équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d’animaux colorés aux membres de l’équipe pour estampiller les tâches qu’ils terminent, permettant au reste de l’équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d’origine sans faire appel à des mécanismes complexes de traçabilité.<br/> | ||
<br/> | <br/> | ||
[[Fichier:KanbanPt4 VisBoard 4b.png]]<br/> | [[Fichier:KanbanPt4 VisBoard 4b.png|border|link=]]<br/> | ||
Limites Kanban<br/> | Limites Kanban<br/> | ||
<br/> | <br/> | ||
| Ligne 73 : | Ligne 73 : | ||
Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d’attente, parfois en impliquant l’architecte pour s’assurer que les exigences de conception sont prises en compte. L’architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d’exigences et de conception atteignent la limite Kanban, l’architecte passe à l’étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu’il finira lui-même. Les développeurs sélectionnent des tâches de l’étape d’architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape « fini » et soit aident l’un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l’étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d’anomalies ainsi que pour vérifier l’alignement avec les exigences clients et la conception interne.<br/> | Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d’attente, parfois en impliquant l’architecte pour s’assurer que les exigences de conception sont prises en compte. L’architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d’exigences et de conception atteignent la limite Kanban, l’architecte passe à l’étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu’il finira lui-même. Les développeurs sélectionnent des tâches de l’étape d’architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape « fini » et soit aident l’un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l’étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d’anomalies ainsi que pour vérifier l’alignement avec les exigences clients et la conception interne.<br/> | ||
<br/> | <br/> | ||
[[Fichier:KanbanPt4 VisBoard 4b QA.png]]<br/> | [[Fichier:KanbanPt4 VisBoard 4b QA.png|border|link=]]<br/> | ||
<br/> | <br/> | ||
Les tâches de QA retournent au développement ou passent à la suite<br/> | Les tâches de QA retournent au développement ou passent à la suite<br/> | ||
| Ligne 93 : | Ligne 93 : | ||
Initialement l’équipe croit que la plus grande limitation pour accomplir des tâches est la main-d’œuvre et qu’augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu’ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l’ajout de développeurs offrirait peu ou pas d’avantages parce que la contrainte actuelle sur leur processus est le goulot d’étranglement sur la QA. S’ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.<br/> | Initialement l’équipe croit que la plus grande limitation pour accomplir des tâches est la main-d’œuvre et qu’augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu’ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l’ajout de développeurs offrirait peu ou pas d’avantages parce que la contrainte actuelle sur leur processus est le goulot d’étranglement sur la QA. S’ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.<br/> | ||
<br/> | <br/> | ||
L’équipe a pris en compte plusieurs idées pour accroître la main-d’œuvre à l’étape de test, y compris l’embauche d’une personne supplémentaire pour la QA et même utiliser l’architecte à temps partiel sur la QA au lieu de le faire développer. Après avoir discuté de plusieurs options, un membre de l’équipe a suggéré d’utiliser l’architecte et tout développeur disponible pour construire des tests automatisés. La théorie est que l’automatisation de certains des tests ne réduira pas seulement la quantité de travail pour la personne QA, mais réduira aussi le nombre de tâches qui sont renvoyées par la QA au développement pour débogage et correction. L’équipe a décidé d’essayer cette idée parce qu’elle ne nécessite pas de dépenses supplémentaires et qu’il y a peu d’impact négatif d’avoir l’architecte travaillant sur les tests unitaires au lieu d’aider à terminer les travaux de développement en respectant la limite Kanban.<br/> | |||
<br/> | <br/> | ||
[[Fichier:KanbanPt4 VisBoard 4c.png]]<br/> | [[Fichier:KanbanPt4 VisBoard 4c.png|border|link=]]<br/> | ||
<br/> | <br/> | ||
Tableau Kanban révisé avec des étapes supplémentaires<br/> | Tableau Kanban révisé avec des étapes supplémentaires<br/> | ||
