Les meilleurs moyens d’intégrer la correction des bogues dans un processus Scrum?
J'ai étudié et lu sur Scrum ces derniers jours et sur la planification et les tâches de Sprint. Un problème qui m’est venu à l’esprit était de savoir comment traiter les bugs dans Scrum. Henrik Kniberg énumère quelques solutions à ce problème dans son très beau livre Scrum et XP from the Trenches :
- Le propriétaire du produit imprime les articles Jira les plus prioritaires De haute priorité, les apporte à la réunion de planification du sprint, Et les place au mur Avec les autres récits (Spécifiant ainsi implicitement la priorité de ces éléments par rapport à les autres histoires).
- Le propriétaire du produit crée des histoires qui font référence aux éléments Jira Par exemple, «Corrigez les bogues de rapport les plus critiques pour le back office, Jira-124, Jira-126 et Jira-180».
- La correction des bogues est considérée comme étant En dehors du sprint, c’est-à-dire que l’équipe Conserve un facteur de mise au point suffisamment bas (par exemple, 50%) pour s’assurer qu’ils ont le temps de corriger les bogues. Il est alors simplement supposé que l’équipe passera un certain temps chaque
- Mettez le carnet de produit dans Jira (C.-à-d. Fossé Excel). Traitez les bogues juste comme tout autre récit.
Est-ce vraiment quelque chose qui doit être décidé par projet ou existe-t-il de meilleures solutions? Je peux penser à des problèmes avec chacune de ces approches. Y at-il un hybride provenant de ces approches qui fonctionne le mieux? Comment gérez-vous cela dans vos projets?
C’est une très bonne question et j’ai quelques remarques à faire sur les différentes approches de ce problème.
- Traiter tous les bogues de la même manière avec les éléments en retard peut sembler une bonne idée en théorie (le travail suivi dans un seul endroit) mais ne fonctionne pas bien dans la pratique. Les bogues sont généralement de bas niveau et plus nombreux. Par conséquent, si vous créez une histoire d'utilisateur individuelle pour chaque bogue, les "vraies" histoires seront bientôt masquées.
- Le temps explicite dans chaque sprint réservé aux correctifs est correct s'il est effectué de manière visible pour le propriétaire du produit. Les bogues doivent être mentionnés lors de la mêlée quotidienne et une discussion sur les bogues corrigés doit avoir lieu lors de la révision du sprint. Sinon, le propriétaire du produit ne sera pas au courant de ce qui se passe dans le projet.
- Mettre tout l'arriéré dans l'outil de suivi des bogues conduit au même ensemble de problèmes qu'en 1. De plus, la plupart des systèmes de suivi des bogues ne sont pas conçus avec Scrum à l'esprit et leur utilisation à cette fin peut s'avérer pénible.
La solution que nous avons trouvée la plus satisfaisante a été de mettre une histoire d’utilisateur unique appelée "Tickets" ou "Bugs" à chaque sprint. Ensuite, une telle histoire peut être divisée en tâches de bas niveau décrivant un bogue particulier (si elles sont connues lors de la planification) ou en méta-tâches réservant un nombre d'heures donné pour la résolution de bugs généraux. Ainsi, le propriétaire du produit a une visibilité sur le processus et le graphique de réduction de charge reflète les progrès.
N'oubliez pas de fermer sans merci tous les "bugs" qui sont en fait de nouvelles fonctionnalités et de créer de nouveaux éléments de leur carnet de commandes. Assurez-vous également de corriger tous les bugs signalés dans le sprint en cours avant la fin du sprint afin de considérer le sprint comme terminé.
En fait, je pense que le mieux est de répondre par jpeacock à partir de cette question Comptez-vous les heures consacrées aux corrections de bugs vers la mêlée?
Laissez-moi le citer:
- Si le bogue est facile/rapide à corriger (un Liner, etc.), alors corrigez-le.
- Si le bogue n’est pas trivial et qu’il n’est pas un bloqueur , Ajoutez-le à l’arriéré.
- Si le bogue est un bloqueur, ajoutez une tâche (Au sprint en cours) pour capturer le travail requis pour le corriger, Et commencer à travailler dessus. Cela nécessite que quelque chose d’autre soit déplacé .__ (du sprint en cours) vers le carnet de commandes Afin de prendre en compte les nouvelles heures .__, car le nombre total d’heures disponibles N’a pas changé.
La première étape consiste à définir ce qu'est un bogue. J'enseigne qu'un bogue n'est un bogue que s'il s'agit d'une fonctionnalité qui ne fonctionne pas en production comme prévu/conçu. Ceux-ci deviennent des PBI de type bogues à hiérarchiser par rapport aux nouveaux développements. Une fonctionnalité manquante en production est une fonctionnalité et devient un élément de backlog de produit normal. Tout code défectueux trouvé lors d'un sprint est considéré comme un travail incomplet et vous ne passez pas à l'histoire suivante tant que celle-ci n'est pas terminée. il n'est pas nécessaire de suivre ces défauts dans le sprint car l'équipe travaille toujours sur le code incriminé. Les post-it peuvent être très utiles ici pour des rappels rapides entre coéquipiers. La correction du code cassé a toujours la priorité sur l'écriture de nouveau code. Si les défauts sont dus à une incompréhension de l'histoire, vous devez travailler sur vos conditions d'acceptation avant de commencer l'histoire.
L'inventaire est un déchet. Le suivi des bogues est un inventaire. Le suivi des bogues est un gaspillage.
Traiter tous les bogues de la même manière avec les éléments en retard peut sembler une bonne idée en théorie (le travail suivi dans un seul endroit) mais ne fonctionne pas bien dans la pratique. Les bogues sont généralement de bas niveau et plus nombreux. Par conséquent, si vous créez une histoire d'utilisateur individuelle pour chaque bogue, les "vraies" histoires seront bientôt masquées.
Si vous avez autant de bogues que de fonctionnalités, vous devez travailler sur vos pratiques d'ingénierie. Ceci est une odeur que quelque chose ne va pas et le suivi n'est pas la réponse. Creusez plus profond. En fait, les insectes sentent toujours mauvais. Ils ne sont pas cool et si vous en avez beaucoup, vous devez trouver les causes fondamentales, les éliminer et cesser de vous concentrer sur le suivi des bogues.
Ne tracez pas les défauts sur une liste, trouvez-les et corrigez-les - Mary Poppendieck
En effet, si l'inventaire est un déchet, qu'en est-il de l'inventaire des défauts ...
C'est pourquoi j'essaie toujours d'implémenter une mentalité Stop-the-Line avec développement basé sur des tests et intégration continue, afin que nous puissions trouver et corriger les défauts au lieu de les inscrire sur une liste de reprises.
Et quand les défauts passent, nous les corrigeons avant d'écrire du nouveau code (les histoires avec des bugs ne sont pas terminées de toute façon). Ensuite, nous essayons de corriger notre processus afin de le rendre plus sûr et de détecter les défauts dès qu’ils se produisent.
Il n'y a pas de solution unique et chaque projet est différent. Les bugs peuvent également être classés de la mission critique à difficilement réparable.
À moins que cela ne soit critique pour le fonctionnement du système, je préfère que les bogues deviennent des cartes d’histoire. Cela rend la priorité du développement de fonctionnalités par rapport à la correction de bugs vraiment explicite. Dans un scénario où les corrections de bogues sont considérées comme "en dehors du sprint", la correction des bogues peut tendre à la résolution de bugs vraiment triviaux alors que des fonctionnalités métier vraiment importantes ne sont pas développées.
Nous avons traversé un certain nombre de permutations avant de considérer le bogue comme une approche narrative. Essayez différentes choses et rejouez-les lors de réunions rétro.
Dans notre cas (greenfield development, 2-3 développeurs), les bogues trouvés sont écrits, clairement identifiés comme bogues et, en fonction de leur gravité, ils sont affectés à la prochaine itération ou laissés dans l'arriéré. En cas de bogues critiques et urgents, ils sont ajoutés à l'itération en cours.
Je ne sais pas pourquoi quelque chose d'aussi simple que de réparer des bogues est compliqué par des règles. Scrum a très peu de règles, souvenez-vous? Ainsi, comme le dit le guide Scrum: les tâches d'un sprint ne se limitent jamais à ce que vous décidez lors de la réunion de planification Daily Scrum aide les gens à discuter des "obstacles" tout au long de leur parcours.
Pourquoi?
Donc, vous discutez et réfléchissez de manière rationnelle en équipe si vous voulez que le problème, c’est-à-dire le problème de l’arriéré, entre dans PBI ou reste dans ce sprint et le livre ...
La meilleure question est comment puis-je arrêter de créer des bugs en phase de développement? voir -> http://bit.ly/UoTa4n
Si vous identifiez et documentez des bogues, vous devrez trier et corriger puis, à un moment ultérieur ..... Ceci conduit à des "sprints de stabilisation", c’est-à-dire un sprint entier juste pour corriger les bugs. Ou vous pouvez les rajouter à l'arriéré et les classer par ordre de priorité dans le cadre d'un prochain sprint ... Cela signifie également que vous fournissez un logiciel contenant des bogues connus et que vous vous attendez à l'avoir publié. et mineur).
Ce n'est pas vraiment agile?
Dans notre projet, j'ai proposé d'introduire un sprint de correction de bugs tous les trois sprints. Nos sprints actuels sont trois semaines.
L'idée est de permettre à tous les développeurs de se concentrer sur la correction des bogues, de se concentrer uniquement sur les nouvelles histoires lors des sprints réguliers et de se concentrer régulièrement sur la réduction de la dette technologique.
Les corrections de bugs seront regroupées en histoires pertinentes et classées par ordre de priorité. L'accent n'est pas mis sur le dimensionnement avant le sprint, car les développeurs ont du mal à résoudre les bugs sans se coincer pour comprendre la nature du défaut.
Quelqu'un a-t-il essayé cette technique ou a-t-il des réactions sur la manière dont cela pourrait fonctionner?
À la vôtre, Kevin.