Commentaires sur : La vélocité des bugs http://www.agilex.fr/2009/05/la-velocite-des-bugs/ Agile, Lean, Scrum et informations diverses Tue, 07 Feb 2012 11:38:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Par : JM.D http://www.agilex.fr/2009/05/la-velocite-des-bugs/comment-page-1/#comment-857 JM.D Thu, 14 May 2009 09:25:13 +0000 http://www.agilex.fr/?p=594#comment-857 Ce qui ne me plait pas, moi, dans la comptabilisation et la valorisation aussi fine des bugs, c'est que l'on se met en mode "pur correctif". Ce n'est pas de l'amélioration continue mais de l'adaptation au coup par coup. Dans ces conditions, qu'est-ce qui va permettre de valoriser des tâches de refactoring, de mise en application de patterns de codage, de faire du TDD, etc ... ? Haro sur le fonctionnel et on corrigera au fur et à mesure de l'apparition des bugs ?? Trop tard, la dette technique est là, et c'est d'autant plus vrai quand il y a un "passif" !! La question est : s'agit-il d'éliminer les bugs ou de les empêcher de survenir ? Donc : OUI pour les pratiques XP et oui, c'est effectivement intéressant : ne pas valoriser les bugs mais considérer qu'ils vont diminuer la vélocité de l'équipe, une espèce de "punition", de "dette", pour les avoir laissé passé. Le tout avec un plan d'action pour s'améliorer, bien sûr. Ce qui ne me plait pas, moi, dans la comptabilisation et la valorisation aussi fine des bugs, c’est que l’on se met en mode « pur correctif ».
Ce n’est pas de l’amélioration continue mais de l’adaptation au coup par coup.
Dans ces conditions, qu’est-ce qui va permettre de valoriser des tâches de refactoring, de mise en application de patterns de codage, de faire du TDD, etc … ?
Haro sur le fonctionnel et on corrigera au fur et à mesure de l’apparition des bugs ?? Trop tard, la dette technique est là, et c’est d’autant plus vrai quand il y a un « passif » !!

La question est : s’agit-il d’éliminer les bugs ou de les empêcher de survenir ?

Donc : OUI pour les pratiques XP et oui, c’est effectivement intéressant : ne pas valoriser les bugs mais considérer qu’ils vont diminuer la vélocité de l’équipe, une espèce de « punition », de « dette », pour les avoir laissé passé. Le tout avec un plan d’action pour s’améliorer, bien sûr.

]]> Par : Claude Aubry http://www.agilex.fr/2009/05/la-velocite-des-bugs/comment-page-1/#comment-854 Claude Aubry Wed, 13 May 2009 12:18:04 +0000 http://www.agilex.fr/?p=594#comment-854 Non, ce que je dis ne remet pas en question ce comptage binaire de vélocité. Tu m'as mal compris. Mais il y a des bugs qui viennent après qu'on ait accepté une story ou simplement sur des choses qui ont été développées avant d'être agile et de compter les points. Non, ce que je dis ne remet pas en question ce comptage binaire de vélocité. Tu m’as mal compris.
Mais il y a des bugs qui viennent après qu’on ait accepté une story ou simplement sur des choses qui ont été développées avant d’être agile et de compter les points.

]]> Par : Alexandre Boutin http://www.agilex.fr/2009/05/la-velocite-des-bugs/comment-page-1/#comment-852 Alexandre Boutin Wed, 13 May 2009 06:44:30 +0000 http://www.agilex.fr/?p=594#comment-852 Comptabiliser la vélocité des bugs indépendamment me semble acceptable car le dysfonctionnement (beaucoup de bugs) sera visible, mais il y a également le risque de voir l'équipe, ou le management, masquer la réalité en ne regardant que la vélocité globale. Pour ce qui est du fait qu'un bug change la valeur d'une US ... je ne partage pas du tout ton point de vue. La méthode est parfaitement claire sur ce point pour dire que la comptabilisation des points d'un US est binaire (tout ou rien). Ce que tu proposes revient à accepter des % de terminé ... très dangereux ! Comptabiliser la vélocité des bugs indépendamment me semble acceptable car le dysfonctionnement (beaucoup de bugs) sera visible, mais il y a également le risque de voir l’équipe, ou le management, masquer la réalité en ne regardant que la vélocité globale.

Pour ce qui est du fait qu’un bug change la valeur d’une US … je ne partage pas du tout ton point de vue. La méthode est parfaitement claire sur ce point pour dire que la comptabilisation des points d’un US est binaire (tout ou rien). Ce que tu proposes revient à accepter des % de terminé … très dangereux !

]]> Par : Claude Aubry http://www.agilex.fr/2009/05/la-velocite-des-bugs/comment-page-1/#comment-850 Claude Aubry Tue, 12 May 2009 19:55:42 +0000 http://www.agilex.fr/?p=594#comment-850 Bonsoir Alex, Je comprends que tu mets les bugs dans le backlog de produit mais que tu ne les estimes pas (lors du planning poker)comme les autres éléments du backlog : puisque tu ne les fais pas rentrer dans la vélocité pas la peine de les estimer. J'ai une position différente. Les bugs ont un coût donc il me paraît normal de l'estimer comme les autres éléments. L'argument "pas de valeur" ne justifie pas qu'ils n'ont pas de coût. Puisqu'un bug a un coût, je suis partisan de le faire apparaître, en distinguant dans la vélocité la partie bugs. D'autre part, je ne suis pas d'accord, un bug a un rapport avec la valeur : il diminue (ou supprime) la valeur de story sur laquelle il porte. Imaginons une story avec une valeur (pas un coût) de 100, un bug sur cette story fera que sa valeur est peut-être 0 si le bug est critique, 80 si le bug est mineur. Un bug a de la valeur négative. Pour les exigences non fonctionnelles, je pense que certaines ne peuvent pas aller dans le backlog. Par exemple : l'application devra fonctionner les navigateurs 1, 2 et 3. Impossible de le finir en une itération. Cela va plutôt dans la définition de fini. Bonsoir Alex,
Je comprends que tu mets les bugs dans le backlog de produit mais que tu ne les estimes pas (lors du planning poker)comme les autres éléments du backlog : puisque tu ne les fais pas rentrer dans la vélocité pas la peine de les estimer.
J’ai une position différente. Les bugs ont un coût donc il me paraît normal de l’estimer comme les autres éléments. L’argument « pas de valeur » ne justifie pas qu’ils n’ont pas de coût. Puisqu’un bug a un coût, je suis partisan de le faire apparaître, en distinguant dans la vélocité la partie bugs.
D’autre part, je ne suis pas d’accord, un bug a un rapport avec la valeur : il diminue (ou supprime) la valeur de story sur laquelle il porte. Imaginons une story avec une valeur (pas un coût) de 100, un bug sur cette story fera que sa valeur est peut-être 0 si le bug est critique, 80 si le bug est mineur. Un bug a de la valeur négative.
Pour les exigences non fonctionnelles, je pense que certaines ne peuvent pas aller dans le backlog. Par exemple : l’application devra fonctionner les navigateurs 1, 2 et 3. Impossible de le finir en une itération. Cela va plutôt dans la définition de fini.

]]>