Bonjour, Nous sommes en train de mettre en place un kanban dans l'équipe et je m'interroge toujours sur la "meilleure" manière de gérer ces développements qui nécessitent de repasser par une étape. Le cas typique est celui d'une story (appelons les ainsi...) qui, supposée terminée, passe de la case "Implémenter" à la case "Vérifier", donc du développeur au QA, puis repasse de "Vérifier" à "Implémenter" parce que la vérification échoue. Et bien sûr, ceci peut arriver plusieurs fois, créant un effet de ping-pong assez pénible. Je ne vois pas bien comment gérer cela en respectant le principe de WIP, sans introduire des files d'attentes supplémentaires matériailisant la transition entre V et I, ni sans bouleverser tout le processus. Si la story redémarre au début de la chaîne, ce n'est pas correct non plus. Ou alors elle vient préempter d'autres stories dans une file d'attente avant "Implémenter", mais alors elle remplace une autre story, qui va oû ?
Evidemment, on pourrait dire que le vrai problème, c'est qu'il y ait ce retravail, et mettre en place les pratiques nécessaires à la réduction de cette catégorie particulière de déchet. Mais en attendant, il faut bien gérer.
Il me semble que Keith Braithwaite ( http://cumulative-hypotheses.org/2011/09/16/iterative-incremental-kan...) suggère une approche intéressante en faisant éclater le cadre rigide de la file linéaire : les limites sont par activité et il n'y a pas de transition formelle de l'une à l'autre.
Arnaud,
On trouve différents modèles de réponse au rework. Peut-être as-tu
déjà parcouru la discussion sur le Kanbandev sur ce sujet?
voici le lien http://finance.groups.yahoo.com/group/kanbandev/message/10147.
Il y a différents points de vue intéressants. Le mien est assez
basique et mécanique (pour un workflow linéaire):
Si tu as posé des limites sur ton état "implémenter", et que les tests
remontent un bug, si ton état "implémenter" a atteint ses limites, ou
mets-tu ta story? A "implémenter"? tu ne respectes plus les limites
alors. Si tu déroges à cette règle, même pour une bonne raison, il y a
des chances que l'équipe déroge pour d'autres (peut être moins bonnes)
raisons. Or il faut être discipliné. Je préfère laisser la story dans
la case "vérifier" avec un post it rouge ou n'importe qui porte
l'activité de correction.
Concernant les indicateurs type cfd, ce postit n'est pas compté car
n'a pas la même granularité que la story, mais son impact est réel sur
le temps de cycle de toute façon.
Concernant la vue non linéaire de nos processus, c'est ce que creuse
depuis quelques temps Karl Scotland avec son Kanban multiverse :vision
en spirale, mind map, story map, ... Pour avoir travaillé en spirale
lorsque j'étais architecte naval, je trouve l'idée séduisante, mais je
n'ai pas pu l'expérimenter encore dans le dev. (et à l'époque, il y a
plus de 15 ans, je ne connaissais pas le kanban).
Laurent
On 22 sep, 09:14, Arnaud Bailly <arnaud.oq...@gmail.com> wrote:
> Bonjour,
> Nous sommes en train de mettre en place un kanban dans l'équipe et je
> m'interroge toujours sur la "meilleure" manière de gérer ces développements
> qui nécessitent de repasser par une étape.
> Le cas typique est celui d'une story (appelons les ainsi...) qui, supposée
> terminée, passe de la case "Implémenter" à la case "Vérifier", donc du
> développeur au QA, puis repasse de "Vérifier" à "Implémenter" parce que la
> vérification échoue.
> Et bien sûr, ceci peut arriver plusieurs fois, créant un effet de ping-pong
> assez pénible. Je ne vois pas bien comment gérer cela en respectant le
> principe de WIP, sans introduire des files d'attentes supplémentaires
> matériailisant la transition entre V et I, ni sans bouleverser tout le
> processus. Si la story redémarre au début de la chaîne, ce n'est pas correct
> non plus. Ou alors elle vient préempter d'autres stories dans une file
> d'attente avant "Implémenter", mais alors elle remplace une autre story, qui
> va oû ?
> Evidemment, on pourrait dire que le vrai problème, c'est qu'il y ait ce
> retravail, et mettre en place les pratiques nécessaires à la réduction de
> cette catégorie particulière de déchet. Mais en attendant, il faut bien
> gérer.
> Il me semble que Keith Braithwaite (http://cumulative-hypotheses.org/2011/09/16/iterative-incremental-kan...)
> suggère une approche intéressante en faisant éclater le cadre rigide de la
> file linéaire : les limites sont par activité et il n'y a pas de transition
> formelle de l'une à l'autre.
Salut Laurent, Merci pour ta réponse. Non , je n'avais pas suivi le fil de discussions sur la ML kanbandev. Je suis assez, voire très d'accord avec le fait de laisser la story là où elle est. C'est ce que je propose dans le workflow que nous sommes en train de mettre en place, avec l'accent mis dans le travail de développement sur la collaboration avec le testeur.
> Arnaud, > On trouve différents modèles de réponse au rework. Peut-être as-tu > déjà parcouru la discussion sur le Kanbandev sur ce sujet? > voici le lien > http://finance.groups.yahoo.com/group/kanbandev/message/10147. > Il y a différents points de vue intéressants. Le mien est assez > basique et mécanique (pour un workflow linéaire): > Si tu as posé des limites sur ton état "implémenter", et que les tests > remontent un bug, si ton état "implémenter" a atteint ses limites, ou > mets-tu ta story? A "implémenter"? tu ne respectes plus les limites > alors. Si tu déroges à cette règle, même pour une bonne raison, il y a > des chances que l'équipe déroge pour d'autres (peut être moins bonnes) > raisons. Or il faut être discipliné. Je préfère laisser la story dans > la case "vérifier" avec un post it rouge ou n'importe qui porte > l'activité de correction.
> Concernant les indicateurs type cfd, ce postit n'est pas compté car > n'a pas la même granularité que la story, mais son impact est réel sur > le temps de cycle de toute façon.
> Concernant la vue non linéaire de nos processus, c'est ce que creuse > depuis quelques temps Karl Scotland avec son Kanban multiverse :vision > en spirale, mind map, story map, ... Pour avoir travaillé en spirale > lorsque j'étais architecte naval, je trouve l'idée séduisante, mais je > n'ai pas pu l'expérimenter encore dans le dev. (et à l'époque, il y a > plus de 15 ans, je ne connaissais pas le kanban).
> Laurent
> On 22 sep, 09:14, Arnaud Bailly <arnaud.oq...@gmail.com> wrote: > > Bonjour, > > Nous sommes en train de mettre en place un kanban dans l'équipe et je > > m'interroge toujours sur la "meilleure" manière de gérer ces > développements > > qui nécessitent de repasser par une étape. > > Le cas typique est celui d'une story (appelons les ainsi...) qui, > supposée > > terminée, passe de la case "Implémenter" à la case "Vérifier", donc du > > développeur au QA, puis repasse de "Vérifier" à "Implémenter" parce que > la > > vérification échoue. > > Et bien sûr, ceci peut arriver plusieurs fois, créant un effet de > ping-pong > > assez pénible. Je ne vois pas bien comment gérer cela en respectant le > > principe de WIP, sans introduire des files d'attentes supplémentaires > > matériailisant la transition entre V et I, ni sans bouleverser tout le > > processus. Si la story redémarre au début de la chaîne, ce n'est pas > correct > > non plus. Ou alors elle vient préempter d'autres stories dans une file > > d'attente avant "Implémenter", mais alors elle remplace une autre story, > qui > > va oû ?
> > Evidemment, on pourrait dire que le vrai problème, c'est qu'il y ait ce > > retravail, et mettre en place les pratiques nécessaires à la réduction de > > cette catégorie particulière de déchet. Mais en attendant, il faut bien > > gérer.
> > Il me semble que Keith Braithwaite ( > http://cumulative-hypotheses.org/2011/09/16/iterative-incremental-kan...) > > suggère une approche intéressante en faisant éclater le cadre rigide de > la > > file linéaire : les limites sont par activité et il n'y a pas de > transition > > formelle de l'une à l'autre.
On 23 sep, 14:23, Arnaud Bailly <arnaud.oq...@gmail.com> wrote:
> Je suis assez, voire très d'accord avec le fait de laisser
> la story là où elle est. C'est ce que je propose dans le workflow que nous
> sommes en train de mettre en place, avec l'accent mis dans le travail de
> développement sur la collaboration avec le testeur.
Bonjour,
Je partage également cette façon de faire: laisser le ticket où il
est, après tout,
c'est lui qui ne peut pas avancer à l'étape suivante, et c'est à toute
l'équipe de
faire en sorte de pouvoir le faire avancer. En gros pour moi, il est
bloqué tant
que la correction n'est pas apportée.
Je ne connais pas les aspect "spirale" et autres non linéaire, je vais
aller regarder
cela, merci pour ces nouvelles perspectives :-)
> Nous sommes en train de mettre en place un kanban dans l'équipe et je > m'interroge toujours sur la "meilleure" manière de gérer ces développements > qui nécessitent de repasser par une étape.
Je sais bien que tu as mis meilleurs entre «» mais rien que le fait de l'écrire me fait tiquer, adapter me semble plus intéressant.
> Et bien sûr, ceci peut arriver plusieurs fois, créant un effet de ping-pong > assez pénible. Je ne vois pas bien comment gérer cela en respectant le > principe de WIP, sans introduire des files d'attentes supplémentaires > matériailisant la transition entre V et I, ni sans bouleverser tout le > processus. Si la story redémarre au début de la chaîne, ce n'est pas correct > non plus. Ou alors elle vient préempter d'autres stories dans une file > d'attente avant "Implémenter", mais alors elle remplace une autre story, qui > va oû ?
2eme cas, cela me semble vraiment bizarre de refaire la moindre nouvelle colonne pour un état qui n'existe pas. En effet, une fiche qui revient en dev est... en dev. Ce que je fais, c'est de modéliser par une barre le nombre de ping pong (nous c'est entre le dev et la revue), métrique simple et diablement efficace pour savoir ce qui se passe, notamment si tu l'associe avec l'entrée dans le système (aka la date du 1er dév). Cela permet ainsi en daily d'identifier rapidement les fiches à problèmes potentiels.
> Evidemment, on pourrait dire que le vrai problème, c'est qu'il y ait ce > retravail, et mettre en place les pratiques nécessaires à la réduction de > cette catégorie particulière de déchet. Mais en attendant, il faut bien > gérer.
La métrique dont je parle te permet deja de voir le niveau de déchet comme tu dis, et savoir si une contre mesure est réellement nécessaire (ou de mesurer son efficacité dans le cas contraire).
> Il me semble que Keith Braithwaite > (http://cumulative-hypotheses.org/2011/09/16/iterative-incremental-kan...) > suggère une approche intéressante en faisant éclater le cadre rigide de la > file linéaire : les limites sont par activité et il n'y a pas de transition > formelle de l'une à l'autre.
Sa visualisation est intéressante, bien que cassant l'effet flux. Je pense qu'il a surtout mal compris ce que l'on pouvait faire avec un Kanban et se focalise sur le coté "démarrer comme d'hab" (équipe spécialisée, etc) et que donc ses critiques tombent à coté de la cible.
L'effet itératif est modélisé chez nous par le fait que :
- une fiche peut revenir en arrière, c'est normal et absoluement pas considéré comme un échec. - une demande peut être vu en plusieurs mmf qui sont une idération de cette demande (mmf 1 : version rustique, mmf2 : 1ere amélioration, mmf3...).
> > Nous sommes en train de mettre en place un kanban dans l'équipe et je > > m'interroge toujours sur la "meilleure" manière de gérer ces > développements > > qui nécessitent de repasser par une étape.
> Je sais bien que tu as mis meilleurs entre «» mais rien que le fait de > l'écrire me fait tiquer, adapter me semble plus intéressant.
Disons : la meilleure pour nous dans l'état actuel des choses.
2eme cas, cela me semble vraiment bizarre de refaire la moindre
> nouvelle colonne pour un état qui n'existe pas. En effet, une fiche > qui revient en dev est... en dev. Ce que je fais, c'est de modéliser > par une barre le nombre de ping pong (nous c'est entre le dev et la > revue), métrique simple et diablement efficace pour savoir ce qui se > passe, notamment si tu l'associe avec l'entrée dans le système (aka la > date du 1er dév). Cela permet ainsi en daily d'identifier rapidement > les fiches à problèmes potentiels.
Oui, j'imaginais un truc dans ce genre. Problème : il faut absolument que cela rentre dans le Jira :-( Je plaisante...
> > Il me semble que Keith Braithwaite > > ( > http://cumulative-hypotheses.org/2011/09/16/iterative-incremental-kan...) > > suggère une approche intéressante en faisant éclater le cadre rigide de > la > > file linéaire : les limites sont par activité et il n'y a pas de > transition > > formelle de l'une à l'autre.
> Sa visualisation est intéressante, bien que cassant l'effet flux. Je > pense qu'il a surtout mal compris ce que l'on pouvait faire avec un > Kanban et se focalise sur le coté "démarrer comme d'hab" (équipe > spécialisée, etc) et que donc ses critiques tombent à coté de la > cible.
> L'effet itératif est modélisé chez nous par le fait que :
> - une fiche peut revenir en arrière, c'est normal et absoluement pas > considéré comme un échec.
Mais alors comment gérer le WIP ? Si une "fiche" doit revenir en arrière alors que la limite de WIP est atteinte dans l'état cible, quid ? On revient encore en arrière ? On met dans un buffer ?
> - une demande peut être vu en plusieurs mmf qui sont une idération de > cette demande (mmf 1 : version rustique, mmf2 : 1ere amélioration, > mmf3...).
Oui, Koen Van Exem parle de "Dimensional Planning", j'aime beaucoup cette idée et j'essaye de la faire passer mais c'est pas facile.
