Les meilleurs moyens d'intégrer la correction des bogues dans un processus Scrum ?

Question

Ces derniers jours, j'ai étudié et lu des articles sur Scrum, notamment sur la planification des sprints et les tâches. Un problème qui m'est venu à l'esprit est celui de la gestion des bugs dans Scrum. Henrik Kniberg énumère quelques façons de traiter ce problème dans son très beau livre. Scrum et XP sur le terrain :

1. Le propriétaire du produit imprime le plus les éléments Jira les plus prioritaires, les les apporte à la réunion de planification du sprint, et les accroche au mur avec les autres histoires (spécifiant ainsi implicitement la priorité de ces éléments par rapport aux les autres histoires).
2. Le propriétaire du produit crée des histoires qui font référence à Jira de Jira. Par exemple "Corriger le problème le plus bogues les plus critiques du back-office, Jira-124, Jira- 126, et Jira-180".
3. La correction des bogues est considérée comme en dehors du sprint, c'est-à-dire que l'équipe garde un facteur de concentration suffisamment bas (par (par exemple 50%) pour s'assurer qu'elle pour avoir le temps de corriger les bogues. Il est alors simplement supposé que l'équipe passera un certain temps par sprint à sprint à corriger les bogues signalés par Jira
4. Mettre le backlog du produit dans Jira (c'est-à-dire abandonnez Excel). Traitez les bugs comme comme n'importe quelle autre histoire.

Est-ce vraiment quelque chose qui doit être décidé pour chaque projet ou existe-t-il de meilleures solutions ? Je peux penser à des problèmes avec chacune de ces approches. Y a-t-il un hybride issu de ces approches qui fonctionne le mieux ? Comment gérez-vous ce problème dans vos projets ?

Answer 1

C'est une très bonne question et j'ai quelques observations à faire sur les différentes approches de ce problème.

1. Traiter tous les bogues de la même manière que les éléments du carnet de commandes peut sembler une bonne idée en théorie (suivi du travail à un seul endroit) mais ne fonctionne pas bien en pratique. Les bogues sont généralement de bas niveau et plus nombreux, donc si vous créez une histoire d'utilisateur individuelle pour chaque bogue, les "vraies" histoires seront rapidement occultées.
2. Un temps explicite dans chaque sprint réservé aux corrections est bien si cela est fait d'une manière qui est visible pour le propriétaire du produit. Les bugs doivent être mentionnés lors de la mêlée quotidienne et la discussion sur les bugs corrigés doit avoir lieu lors de la revue du sprint. Sinon, le propriétaire du produit ne sera pas au courant de ce qui se passe dans le projet.
3. Le fait de placer l'ensemble du carnet de commandes dans un outil de suivi des bogues entraîne les mêmes problèmes qu'au point 1. De plus, la plupart des outils de suivi des bogues ne sont pas conçus dans l'optique de Scrum et leur utilisation à cette fin peut être pénible.

La solution que nous avons trouvée la plus satisfaisante est de placer une seule histoire d'utilisateur appelée "Tickets" ou "Bugs" dans chaque sprint. Ensuite, une telle histoire peut être divisée soit en tâches de bas niveau décrivant un bogue particulier (s'il est connu lors de la planification), soit en méta-tâches réservant un nombre d'heures donné pour la correction générale des bogues. De cette façon, le propriétaire du produit a une visibilité sur le processus et le tableau d'avancement reflète la progression.

N'oubliez pas de fermer impitoyablement tous les "bogues" qui sont en fait de nouvelles fonctionnalités et de créer de nouveaux éléments du backlog pour eux. Assurez-vous également de corriger tous les bogues signalés pour le sprint en cours avant la fin du sprint afin de considérer le sprint comme terminé.

Answer 2

En fait, je pense que la meilleure réponse est jpeacock de cette question Comptez-vous les heures consacrées à la correction des bugs dans la mêlée ?

Permettez-moi de le citer :

• Si le bogue est facile/rapide à corriger (un seul etc.), il suffit de le corriger.
• Si le bogue n'est pas trivial, et n'est pas un bloquant, alors ajoutez-le au backlog.
• Si le bogue est bloquant, ajoutez alors une tâche (au sprint actuel) pour capturer le travail nécessaire pour le corriger, et commencez à travailler dessus. Ce site nécessite que quelque chose d'autre soit déplacé (du sprint actuel) vers le backlog pour tenir compte des nouvelles heures car le total des heures disponibles n'a pas changé.

Answer 3

La première étape consiste à définir ce qu'est un bug. J'enseigne qu'un bug n'est un bug que s'il s'agit d'une fonctionnalité qui ne fonctionne pas en production comme prévu/conçu. Il s'agit alors de PBIs de type bug qui doivent être priorisés par rapport à un nouveau développement. Une fonctionnalité manquante en production est une fonctionnalité et devient un élément normal du backlog du produit. Tout code défectueux trouvé au cours d'un sprint est considéré comme un travail incomplet et comme on ne passe pas à l'histoire suivante tant que l'histoire en cours n'est pas terminée, il est inutile de suivre ces défauts au cours du sprint car l'équipe travaille toujours sur le code incriminé. Les post-it peuvent être très utiles pour les rappels rapides entre coéquipiers. La correction du code défectueux a toujours la priorité sur l'écriture de nouveau code. Si les défauts sont dus à une mauvaise compréhension de l'histoire, vous devez travailler sur vos conditions d'acceptation avant de commencer l'histoire.

L'inventaire est un gaspillage. Le suivi des bogues est un inventaire. Le suivi des bogues est un gaspillage.

Traiter tous les bogues de la même manière que les éléments du backlog peut sembler une bonne idée en théorie (suivi du travail à un seul endroit), mais ne fonctionne pas bien en pratique. Les bogues sont généralement de bas niveau et plus nombreux, donc si vous créez une histoire d'utilisateur individuelle pour chaque bogue, les "vraies" histoires seront rapidement occultées.

Si vous avez autant de bogues que de fonctionnalités, vous devez travailler sur vos pratiques d'ingénierie. C'est le signe que quelque chose d'autre ne va pas et que le suivi n'est pas la solution. Creusez plus profondément. En fait, les bugs sont toujours malodorants. Ils ne sont pas cool et si vous en avez beaucoup, vous devez trouver la ou les causes profondes, les éliminer et arrêter de vous concentrer sur le suivi des bugs.

Answer 4

Ne suivez pas les défauts sur une liste, trouvez-les et réparez-les -- Mary Poppendieck

En effet, si l'inventaire est un gaspillage, qu'en est-il de l'inventaire des défauts...

C'est pourquoi j'essaie toujours de mettre en place une Stop-the-Line mentalité avec le développement piloté par les tests et l'intégration continue, de sorte que nous trouvions et corrigions la plupart des défauts au lieu de les mettre sur une liste de retouches.

Et lorsque des défauts passent, nous les corrigeons avant d'écrire un nouveau code (les histoires avec des bugs ne sont pas faites de toute façon). Ensuite, nous essayons d'améliorer notre processus pour le rendre plus à l'abri des erreurs et détecter les défauts au moment où ils se produisent.

Answer 5

Il n'existe pas de solution unique et chaque projet est différent. Les bogues peuvent également être classés en deux catégories : ceux qui sont critiques pour la mission et ceux qui ne valent pas la peine d'être corrigés.

À moins qu'ils ne soient critiques pour le fonctionnement du système, je préfère que les bogues deviennent des story cards. Cela rend la priorité du développement des fonctionnalités par rapport à la correction des bogues vraiment explicite. Dans un scénario où la correction des bogues est considérée comme étant "en dehors du sprint", la correction des bogues peut s'orienter vers la correction de bogues vraiment insignifiants alors que des fonctionnalités commerciales vraiment importantes ne sont pas développées.

Nous avons passé en revue un certain nombre de permutations avant d'opter pour l'approche du bug en tant qu'histoire. Essayez différentes choses et rejouez-les lors des réunions rétro de l'équipe.