Comment tenir compte d'une itération de correction de bogue?

Nous avons implémenté Scrum avec succès au cours des 5 derniers mois. Cependant, nous sommes à 3 semaines de PROD sans jamais faire de test d'intégration de bout en bout. AIE! J'ai besoin d'aide. Sans s'attaquer aux causes de cela (à ce stade), nous devons maintenant planifier l'itération actuelle, qui consiste en des améliorations mineures et BEAUCOUP de corrections de bugs encore inconnues. Comment expliquez-vous ce scénario? Comment planifiez-vous votre itération pour corriger les bogues encore à trouver?

Scrum ou non, la correction de bugs est fondamentalement impossible à prévoir. Je crois que le mieux que vous puissiez faire est:

• Commencez les tests immédiatement, sans estimation initiale quand cela sera fait.
• Lorsque vous découvrez chaque bogue, faites une analyse initiale au point que vous pouvez l’estimer.
• Estimez le bogue et décidez s'il doit être corrigé et s'il doit l'être pour la relese initiale.
• S'il doit être corrigé, ajoutez-le à l'itération.
• Tracez un graphique de combustion. À un moment donné, il commencera à diminuer, ce qui signifie que vous ne trouverez plus de bogues plus rapidement que vous n'arrivez à les corriger. À ce stade, vous serez en mesure de donner une estimation approximative (et progressivement plus précise) lorsque la libération peut être effectuée.

Vous devez vous assurer que la prochaine fois que vous commencerez à tester tôt et corrigerez les bogues au fur et à mesure. Toutes les méthodologies sensées, agiles ou non, nécessitent de corriger des bugs connus avant de progresser avec de nouvelles fonctionnalités. Vous devez également prendre en compte le temps passé à corriger chaque bogue, afin que vous puissiez améliorer votre estimation pour la mise en œuvre de la fonctionnalité à l'état débogué à l'avenir.

L'estimation et la correction de bogues sont bien couvertes par Joel Spolsky dans Evidence Based Scheduling et Hard-assed Bug Fixin ' . Ce n'est pas lié à Scrum, mais je pense que c'est assez général pour qu'une grande partie s'applique.

Comment tenir compte d'une itération de correction de bogue? Comment planifiez-vous votre itération pour corriger les bogues encore à trouver?

Concernant une "itération de correction de bogue". Les bogues trouvés ne doivent pas être traités différemment des histoires. Travaillez avec l'équipe pour estimer l'effort (points d'histoire) pour corriger chaque bogue et travaillez avec le propriétaire du produit / client pour décider si le bogue doit entrer dans la prochaine itération.

Concernant les "bugs à trouver". De préférence, l'équipe recherche et corrige les problèmes à chaque itération. Si ce n'est pas le cas, discutez-en dans votre prochaine rétrospective. Si la qualité du produit est si faible qu'il n'est pas possible de la publier, déplacez immédiatement vos meilleurs "recherche de bogues " vers la recherche de bogues (pas de correction). Si la qualité est suffisamment élevée pour fournir une version bêta à certains utilisateurs, faites-le. Si vous ne le pouvez pas, fournissez au moins des démonstrations d'utilisateurs en direct sur les points faibles que vous recommandez.

Nous ne prévoyons pas d'itérations de correction de bogues, mais nous planifions des itérations de test du système avant chaque version. Le test du système est l'intégration, la régression et les tests réels sur toutes les parties du produit. Les testeurs testent le produit (un système hérité assez important) et les développeurs corrigent tous les bogues trouvés. Si aucun bogue n'est trouvé, nous commençons soit à étudier les calendriers des fonctionnalités pour le prochain projet, soit à travailler sur des améliorations internes.

Actuellement, nous prévoyons six semaines de tests système après le gel du code (pour un projet de cinq mois, test système inclus), pour nous assurer que tout fonctionne. C'est en plus de tous les tests effectués lors des itérations d'implémentation.

Vous devez définir un ensemble de critères de "libération". Ceux-ci pourraient inclure:

• Temps moyen entre l'échec
• Nombre de défauts trouvés par jour
• Gravité des défauts constatés par jour
• Nombre de défauts non résolus

etc.

Ensuite, à la fin de chaque itération, certaines personnes testent (manuellement ou en écrivant des tests automatisés) et d'autres corrigent le contrôle pour voir si vous avez répondu à vos critères. Si vous avez ensuite relâché, sinon optez pour une autre itération.

Il devrait y avoir la possibilité d'une dérogation à cela, et souvent les chiffres bruts ne présentent pas une image réaliste de l'application. Vous pouvez avoir quelques défauts vraiment graves, mais ils ne se manifestent que dans de rares conditions avec lesquelles vous pouvez vivre à court terme.

Une façon de le faire est d'écrire des histoires pour vos tests d'intégration, au cours desquelles vous écrivez de nouvelles histoires pour tous les bogues que vous trouvez, puis corrigez les histoires de bogues dans l'itération suivante.

Une autre façon de le faire est de simplement faire une histoire qui dit "Correction des bugs trouvés dans les tests d'intégration." À partir des versions précédentes, vous devriez avoir une idée du nombre de problèmes rencontrés et de la difficulté de les résoudre, afin de pouvoir attribuer des points d'histoire en fonction de ces connaissances. Vous pouvez peut-être le diviser en composants si cela le rend plus facile à gérer. Il y a toujours une incertitude inévitable là-dedans. Ajoutez des points d'histoire supplémentaires pour en tenir compte.

Vous avez probablement réalisé tardivement que le meilleur moyen est d'incorporer un petit test d'intégration dans chaque itération si possible. Félicitations d'avoir reconnu cela et d'avoir amélioré un peu votre processus pour votre prochaine version.