Une question que l’on me pose régulièrement en ce moment : met-on de la complexité sur les bugs ? Je pourrais répondre par oui ou par non… Mais la réponse est nettement plus complexe que je vais en écrire un petit article complet.
Deux types de bugs différents
En Scrum en général, on considère deux type des bugs différents. La distinction est importante car on ne les traite pas du tout de la même façon.
Le bug en cours de test : c’est un bug que notre Product Owner ou notre testeur découvre lors de la validation de la user-story (ou autre type de tâche). Ils vont alors refuser de passer la user-story de TEST à DONE et vont rajouter une sous-tâche technique bug (en rouge sur l’image ci-dessous).
Ce type de bugs ne verra jamais le jour en production car on va le traiter de la même façon que l’ensemble des sous-tâches techniques.
Le bug en production : il arrive parfois (dans certains cas souvent) de découvrir un bug en production. Il est impératif de le traiter selon le niveau de criticité de celui-ci ; certains pensent même qu’un bug découvert est la priorité absolu (je vous laisse seul juge).
On traitera ce bug comme une tâche (user-story, tâche technique…) et non comme une sous-tâche. La question de cet article est de savoir d’ailleurs si nous allons mettre ou non de la complexité à notre bug.
Le bug n’apporte pas de valeur business
Il y a une chose qui est sûre, c’est qu’on a aucune valeur business sur un bug.
Mais pourtant si on corrige un bug, c’est pour que l’utilisateur final ne soit plus impacté par quelque chose ? En fait si on corrige un bug c’est pour corriger quelque chose qui devrait déjà être en ligne donc on considère que le correctif n’apporte rien mais qu’on aurait préféré ne pas à avoir à le faire.
Donc je confirme : un bug a 0 valeur business.
Il existe deux philosophies dans le monde du Scrum d’où le fait de traiter cette réponse en un article complet.
Non, je ne mets pas de complexité
Dans un agile simplifié (à ne pas lire négativement), on a tendance à dire que les bugs ne doivent pas avoir de complexité afin que la vélocité reflète en partie la valeur délivrée.
Dans ce cas, la courbe de la vélocité (sur le temps) peut montrer les phases où les développeurs ont bien répondu aux demandes métiers et les phases où ce n’est pas le cas.
En général, si vous n’avez pas d’intégration continue ou devops, votre vélocité fini par baisser car le legacy grandissant impose de corriger de plus en plus de bugs.
Oui je mets de la complexité
Dans un agile plus complexe (toujours à ne pas lire négativement), on a tendance à mettre de la complexité sur l’ensemble des tâches (user-story, tâches techniques, bugs…). Ca simplifie la prédictibilité et la vélocité est un indicateur qui ne mélange pas deux notions : la charge et la valeur cliente.
On ajoute en fait un deuxième indicateur que l’on appelle la « Business Value » qui sera là pour suivre la valeur qui sera délivrée au client (ou utilisateurs clés). Du coup, il n’est plus utile de jouer cet aspect client sur les tâches à traiter et on décide alors de mettre de la complexité sur l’ensemble des tâches (excepté les spikes qui sont eux timeboxé).
Article : Prioriser avec les Business Value
Mon conseil sur la complexité sur les bugs ?
Je conseille sur la complexité sur les bugs, de laisser l’équipe choisir la philosophie dans laquelle l’équipe se sent le mieux. Si je suis moi même plus partisan de la deuxième méthode, en tant que coach agile, je préfère que l’équipe (PO inclus) choisisse vraiment celle avec laquelle elle se sent le plus à l’aise.
Cependant dans certains cas de Scrum à grande échelle, ce choix peut avoir un impact sur les indicateurs et le suivi des projets. Même si je suis partisan de laisser toujours l’équipe choisir les solutions qui lui convient le mieux, ce n’est pas toujours facile à comprendre pour les entreprises (et surtout les grands groupes) qui sont à la poursuite d’indicateurs.
Conclusion
Vous savez à présent comment gérer la complexité sur vos bugs. Voici un article que j’avais écrit il y a quelques temps qui vous explique comment gérer vos bugs :
Article : Comment gérer les bugs en scrum ?
N’hésitez pas vous aussi à partager vos astuces car il en existent sûrement d’autres très intéressantes sur ce sujet parfois difficile à aborder par les équipes qui font du Scrum.
bonsoir judicael,
la premiere chose est de banir le terme de complexité, en langue français, nous confondons compliqué et complexe. Complexe sous entend un ensemble de liens dont certains sont inconnus. ce qui induit que nous ne pouvons utiliser l’utiliser comme element d’estimation. il serait plus judicieux d’utiliser le terme compliqué, sachant que pour une estimation, cela n’a aucun sens, c’est plutot un critère de criticité. Je recommanderais d’utiliser le terme d’effort qui est plus adapté dans le contexte d’une estimation.
Revenons au scrumers sur les anomalies, il y a deux écoles de pensée : la premiere recommande l’absence d’estimation pour les anomalies pour réduire ainsi la vélocité et mettre en avant par ce résultat un probleme de qualité dans le développement.
la deuxième approche est de categoriser une anomalie avec un indicateur de difficulté. tels que simple ou complexe. le premier indique une résolution compréhensible de l’anomalie, il pourra alors être estimé. le deuxième critère implique une etude pour comprendre l’anomalie, il ne sera estimé avant la fin la compréhension de la cause racine de l’anomalie, qui peut x anomalies.
toutefois reste le probleme de l’utilisation de l’aterfact burndow, qui permet de suivre l’avancé de la quantité de travail vs le temps restant. Comment résoudre ce sujet, si une anomalie n’est pas estimé. La solution, la plus simple est d’utilise un indicateur de WIP et de débit avec un cumulative flow en lieu et place du burndow.
c’était mon petit retour 😀
Salut mon Yannick 🙂
En effet, je l’utilise sur ce blog car c’est le terme qui s’est popularisé mais je préfère le terme de point d’effort.
Alors pour la deuxième méthode, je ne le fais pas comme ça mais en effet la philosophie est assez proche. Je ne suis pas rentré dans ce niveau de détail mais quand la résolution exige de l’approfondissement, je propose un « spike » timeboxé pour commencer par creuser les inconnus. Estimer l’inestimable est peu intéressant surtout si ces indicateurs servent de prédictibilité à la suite. J’applique cette idée également pour d’éventuels autres types de besoins comme l’exploration de données (projets big data). L’idée est très proche je pense.
Le burndown pour ma part ne prend en compte que l’estimé dans la première méthode et dans la deuxième le problème se pose moins. Après je pense qu’il n’y a pas de méthode géniale, je laisse les équipes choisir (en espérant que cela ne lancera pas une guerre des chiffres côté management :p)