Qui de quoi, mais je parle de bugs.

L’année dernière, je vous ai parlé du Bagel’s - un événement organisé dans notre entreprise pour nettoyer l’arriéré de bogues. L'événement est bon et utile, mais il résout le problème de bogue une fois. Nous avons déjà organisé six Bagodelen, mais le nombre de participants diminuait progressivement et il est devenu évident que la nécessité de cet événement a commencé à disparaître. La raison principale était l'apparition de Zero Bug Policy. Il n'y a pas beaucoup de sources en russe à ce sujet où vous pouvez lire et trouver une solution pratique pour vous-même. Dans cet article, je parlerai de notre approche du sujet et lirai avec plaisir votre expérience dans les commentaires.

Qu'est-ce que c'est?

Zero Bug Policy (ZBP) est une politique de gestion des erreurs basée sur des règles:

"Lorsqu'une nouvelle erreur apparaît, vous devez immédiatement décider de la corriger dans un proche avenir, ou de la fermer en tant que" Ne sera pas corrigé "."

Dans ce cas, n'allez pas aux extrêmes: ne faites pas d'erreurs du tout ou éditez tout de suite. Il est important de développer vous-même des critères de qualité pour les fonctionnalités que vous êtes prêt à donner aux utilisateurs et de considérer la tâche terminée après avoir corrigé toutes les erreurs importantes.

Avantages de la politique

• Tout le monde sait combien il y a d'erreurs ouvertes et ce nombre est assez limité.
• Moins de temps est nécessaire pour trouver la tâche dans le système de suivi des bogues.
• Il n'y a pas de longues réunions pour trier et redéfinir la priorité du carnet d'erreurs.
• Cela peut devenir psychologiquement plus facile pour vous lorsque vous n'êtes pas soumis à un arriéré gonflé.
• Après correction, il n'est pas nécessaire de rappeler ce qu'il y avait «il y a cent ans», et de replonger dans le contexte.

Sonne bien, mais des effets secondaires sont possibles.

• Diminution de la qualité des produits.
• Dégradation du niveau de l'équipe de test. (Pourquoi perdre du temps à chercher des bugs complexes et complexes s'ils ne sont toujours pas corrigés?).
• Une source utile d'informations (sous la forme d'un backlog ouvert) pour les nouveaux membres de l'équipe est perdue.

Et il y a toujours un facteur de peur.

"Nous allons donc fermer l'erreur, et que se passe-t-il si un avenir radieux arrive quand il est temps de le réparer?"

Il est très peu probable que vous disposiez de temps supplémentaire. C’est comme stocker de vieux déchets sur le balcon: vous ne perdez pas l’espoir d’utiliser l’une de ces choses, mais il est fort probable que cela ne se produira jamais.

Ici, nous fermons l'erreur, et l'utilisateur la voit dans le prod.

Un utilisateur contrarié écrira au support, qui vous informera à son tour. Il sera nécessaire de revoir la priorité de cette erreur et de décider à nouveau de la corriger ou non.

Implémentation

La partie la plus difficile est de commencer. Pour ce faire, vous devez trouver le temps, les ressources, le désir (souligner nécessaire) de ramasser tout l'arriéré des erreurs anciennes et de prendre une décision radicale pour corriger ou fermer.
Ensuite, rassemblez vos forces et corrigez les «survivants» après avoir nettoyé les erreurs.
Et commencez à vivre selon les nouvelles règles.

Commencez à diviser les bogues en deux catégories:

• un bug trouvé lors du test d'une nouvelle fonctionnalité;
• un bug trouvé sur prod / avec régression.

Si vous trouvez un bug lors du test d'une nouvelle fonctionnalité, vous devez immédiatement prendre une décision:

• corrige le bogue avant la fin du développement / test de la fonctionnalité;
• reclassifier un bogue (c'est peut-être en fait une amélioration);
• vous n'aurez peut-être pas du tout besoin d'un bogue si vous ne le modifiez pas.
  Au stade de l'exécution du processus, il est préférable de démarrer et de fermer ces bogues avec la résolution «Won't Fix» décrivant la raison de la fermeture. Sur la base de ces données, vous pourrez analyser les défauts et développer correctement les critères de qualité dans votre équipe.

Et s'il y a un bug sur le prod / avec régression, alors vous devez décider quoi faire.

• Corrigez le bug et respectez la date limite en fonction de la priorité du bug. Le temps de correction va de "maintenant" à deux sprints. Si le bogue n'a pas été corrigé dans deux sprints, il doit être fermé.
• Changez le type de tâche de «Bug» en «Amélioration».
• Fermez le bogue avec la résolution «Won't Fix» avec une description de la raison de la fermeture.

Pour déterminer la priorité du bug, nous utilisons une matrice qui combine la criticité du bug au sein d'une commande spécifique et la fréquence d'occurrence.

Autres détails

Le bénéfice de l'utilisation de cette approche est susceptible d'être insignifiant si vous ne modifiez pas en outre les processus et les approches de développement et de test.

Qu'est-ce qui réduira le nombre de bogues lors du développement d'une nouvelle fonctionnalité?

1. Utilisez un large éventail de pratiques techniques et organisationnelles (par exemple, la mise en œuvre de Quality Gates, l'analyse d'impact, les tests Agile).
2. Éliminez les emplacements générateurs de bogues en refactorisant l'ancien code.
3. Corrigez rapidement les erreurs, ce qui réduira leur impact à l'avenir.
4. Écrivez des autotests pour détecter plus rapidement et
   éviter la répétition des erreurs.

Mesures

Afin de ne pas tirer de conclusions sur nos sentiments, nous suivons les métriques ZBP (j'aime beaucoup Tableau et je l'utilise pour créer des rapports). Cela vous permet de suivre les progrès de la dynamique et de mettre en évidence les problèmes émergents.

Résultats

Quels sont les résultats des travaux sur ZBP avec nous?

Nous vivons dans le monde réel, et dans sa forme la plus pure, il n'était pas possible d'utiliser la politique.
Quelqu'un a rencontré un problème hérité et l'incapacité de corriger certains bogues pendant une durée limitée. Quelqu'un avait accumulé un arriéré au fil des ans, c'était juste effrayant de l'approcher et ils n'étaient pas pressés de commencer ce processus.

Mais en général, de nombreuses équipes ont réussi à analyser leurs arriérés et à fixer une certaine barre sur le nombre de bogues ouverts. Les équipes ont commencé à mieux évaluer les bogues et à prendre des décisions plus rapides sur le besoin de correction.

Conclusions

• Il faut beaucoup d'efforts pour changer votre approche de l'utilisation des bogues.
• Pour que le processus fonctionne, il doit faire partie de la culture d'ingénierie de l'entreprise.
• L'équipe doit trouver un équilibre entre la correction des erreurs et le développement du sprint.

Tous les bons et moins de bugs!