Les meilleurs moyens d'intégrer la correction de bogues dans un processus Scrum? [fermé]

J'ai étudié et lu sur Scrum ces derniers jours et j'ai lu sur la planification et les tâches de Sprint. Un problème qui m'est venu à l'esprit est de savoir comment gérer les bugs dans Scrum. Henrik Kniberg énumère quelques façons de traiter ce problème dans son très beau livre Scrum and XP from the Trenches :

1. Le propriétaire du produit imprime les éléments Jira les plus prioritaires, les apporte à la réunion de planification du sprint et les affiche sur le mur avec les autres histoires (spécifiant ainsi implicitement la priorité de ces éléments par rapport aux autres histoires).
2. 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 de back-office les plus critiques, Jira-124, Jira-126 et Jira-180».
3. La correction des bogues est considérée comme étant en dehors du sprint, c'est-à-dire que l'équipe garde un facteur de concentration suffisamment bas (par exemple 50%) pour s'assurer qu'elle a le temps de corriger les bogues. On suppose alors simplement que l'équipe passera un certain temps à chaque sprint à corriger les bogues rapportés par Jira
4. Mettez le backlog de produit dans Jira (c.-à-d. Fossé Excel). Traitez les bugs comme n'importe quelle autre histoire.

Est-ce vraiment quelque chose qui doit être décidé par projet ou existe-t-il de meilleures solutions? Je peux penser aux problèmes de chacune de ces approches. Y a-t-il un hybride issu 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 observations 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 backlog peut sembler une bonne idée en théorie (travail suivi à 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 user story individuelle pour chaque bogue, alors les "vraies" histoires seront bientôt obscurcies.
2. L'heure explicite dans chaque sprint réservée aux correctifs est correcte si elle est effectuée d'une manière visible pour le propriétaire du produit. Les bogues devraient être mentionnés pendant la mêlée quotidienne et une discussion sur les bogues corrigés devrait avoir lieu pendant la revue du sprint. Sinon, le propriétaire du produit ne sera pas au courant de ce qui se passe dans le projet.
3. Mettre tout le backlog dans l'outil de suivi de bogues conduit au même ensemble de problèmes que dans 1. De plus, la plupart des traqueurs de bogues ne sont pas conçus avec Scrum à l'esprit et les utiliser à cette fin peut être douloureux.

La solution que nous avons trouvée la plus satisfaisante a été de mettre une seule user story appelée "Tickets" ou "Bugs" à chaque sprint. Ensuite, une telle histoire peut être divisée soit en tâches de bas niveau décrivant un bogue particulier (si connu pendant 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 graphique de combustion reflète la progression.

N'oubliez pas de fermer sans pitié tous les «bogues» qui sont en fait de nouvelles fonctionnalités et de créer de nouveaux éléments de backlog pour eux. Assurez-vous également de corriger tous les bogues signalés par rapport au sprint actuel 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 à cette question. Comptez -vous les heures passées sur les corrections de bugs vers la mêlée?

Laissez-moi le citer:

• Si le bogue est facile / rapide à corriger (une doublure, etc.), corrigez-le simplement.
• Si le bogue n'est ni trivial, ni bloquant, ajoutez-le au backlog.
• Si le bogue est un bloqueur, ajoutez une tâche (au sprint actuel) pour capturer le travail requis pour le corriger, et commencez à travailler dessus. Cela nécessite que quelque chose d'autre soit déplacé (du sprint actuel) vers le backlog pour tenir compte des 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 si c'est une fonctionnalité qui ne fonctionne pas en production comme il était prévu / conçu. Ceux-ci deviennent des PBI de type bogue à prioriser par rapport aux nouveaux développements. La fonctionnalité manquante en production est une fonctionnalité et devient un élément normal du backlog de produit. Tout code défectueux trouvé pendant un sprint est considéré comme un travail incomplet et puisque vous ne passez pas à l'histoire suivante tant que celle en cours n'est pas terminée; il est inutile de suivre ces défauts dans le sprint car l'équipe travaille toujours sur le code incriminé. Les post-its 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 d'un nouveau code.

L'inventaire est un gaspillage. Le suivi des bogues est un inventaire. Le suivi des bogues est du 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 (travail suivi à 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 user story individuelle pour chaque bogue, alors les "vraies" histoires seront bientôt obscurcies.

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

Ne pas suivre les défauts sur une liste, les trouver et les corriger - Mary Poppendieck

En effet, si l'inventaire est un gaspillage, que dire d'un inventaire des défauts ...

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

Et quand les 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 de corriger notre processus pour le rendre plus résistant aux erreurs et détecter les défauts au moment où ils se produisent.

Il n'y a pas de solution unique et chaque projet est différent. Les bogues peuvent également être classés de la mission critique à à peine la peine d'être corrigée.

À 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 bogues vraiment explicite. Dans un scénario où les corrections de bogues sont considérées comme «en dehors du sprint», la correction des bogues pourrait aller vers la correction de bogues vraiment insignifiants alors que des fonctionnalités commerciales vraiment importantes ne sont pas développées.

Nous avons parcouru un certain nombre de permutations avant de définir le bogue comme une approche narrative. Essayez différentes choses et rejouez-les lors de réunions d'équipe rétro.

Dans notre cas (développement greenfield, 2-3 devs) les bogues trouvés sont notés, clairement marqués comme un bogue et en fonction de leur gravité, ils sont affectés à l'itération suivante ou laissés dans le backlog. 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 corriger des bugs est compliqué avec des règles. Scrum a très peu de règles, tu te souviens? Chaque fonctionnalité, support, recommandation ou défaut est un problème de backlog dans Scrum, il n'y a pas de différenciation. 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, le Daily Scrum aide les gens à discuter des «obstacles» en cours de route.

Pourquoi?

Donc, vous discutez et pensez rationnellement en équipe si vous voulez que le problème du retard, c'est-à-dire du backlog, entre dans PBI ou reste dans ce Sprint et le livre ...

La meilleure question est de savoir comment arrêter de créer des bogues en phase de développement? voir -> http://bit.ly/UoTa4n

Si vous identifiez et documentez des bogues, vous devrez les trier et les corriger ultérieurement. Cela conduit à des "sprints de stabilisation" c'est-à-dire un sprint entier juste pour corriger les bogues. Ou vous pouvez les rajouter au backlog et les hiérarchiser dans le cadre d'un futur sprint. Cela signifie également que vous fournissez et que vous vous attendez à obtenir un logiciel approuvé et publié avec des bogues connus (P3 & P4 aka cosmétiques et mineurs).

Ce n'est pas vraiment agile?

J'ai déposé l'idée dans notre projet d'introduire un sprint de correction de bogue tous les trois sprint. Nos sprints actuels durent trois semaines.

L'idée est que cela permettra à tous les développeurs de se concentrer ensemble sur la résolution de bogues, de se concentrer uniquement sur de nouvelles histoires dans les sprints réguliers et de se concentrer régulièrement sur la réduction de la dette technologique.

Les corrections de bogues seront regroupées dans des 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 à dimensionner les corrections de bogues sans rester coincés pour comprendre la nature du défaut.

Quelqu'un a-t-il essayé cela ou a-t-il des commentaires sur la façon dont cela pourrait fonctionner?

Bravo, Kevin.