Aujourd’hui, la partie « excellence technique » de l’agilité apparait de plus en plus. Et la qualité passe aussi par la gestion des bugs qui peuvent vite dégrader considérablement la valeur de notre produit. Le bug, on le corrige ou on le supprime !
Le bug, on le corrige ou on le supprime !
C’est tellement facile et évident de l’écrire mais pas toujours simple à appliquer. Cependant laisser des bugs finit toujours par se payer assez cher :
- ressenti en baisse des utilisateurs
- instabilité grandissante
- qualité en baisse
Certains comme Yassal Sundman estiment qu’il faut clairement insister sur l’importance parfois sous estimée de gérer ces bugs ; il lance d’ailleurs le « A zero bug policy ».
En gros, à l’apparition d’un bug, il n’y a que deux issues possibles : le corriger si c’est faisable et si on s’en laisse le temps ou on le supprime tout simplement.
Le contexte trop souvent un prétexte de l’attente
Il est vrai que le contexte est souvent pris comme excuse du « désolé on peut pas le corriger tout de suite ». Honnêtement, quand les bugs se multiplient sur des applications plutôt anciennes, la mise à l’écart d’un bug revient à accepter de vivre indéfiniment avec lui.
On peut comprendre que les objectifs de certaines entités ou managers prennent rarement en compte les bugs ; pourtant ils existent réellement et même dans les meilleures architectures récentes.
Accepter de vivre avec a des conséquences beaucoup plus importantes qu’on l’imagine.
Des utilisateurs vivant avec des application bugguées ont une satisfaction en baisse ; ce n’est pas anodin car cela peut jouer sur le bien être au travail, peut renforcer un turn-over, peut les rendre moins sympathique lors de travaux sur d’autres produits (voire refontes)… Les impacts sont bien plus importants qu’on l’imagine. L’accumulation de bugs amène en conséquence à aller à l’encontre d’une transformation agile sereine.
Et je parle des utilisateurs mais certains développeurs devant fournir des applications bugguées peuvent en venir à des conclusions similaires : ce n’est pas agréables de fournir des applications de qualité moyenne, on peut rapidement en ressentir une frustration… Et pourquoi pas en conséquence une envie d’ailleurs ?
En effet, si cette vision va un peu loin, la correction de bugs participent en réalité au mindset agile. On améliore l’environnement d’un ensemble de personne grâce à la correction de bugs donc avec une réelle implication dans l’excellence technique.
On est en fait tout simplement dans le cadre de « l’amélioration continue » même si il y a un aspect technique généralement derrière les bugs.
La qualité pas adaptée à la vision court terme
Savoir ou mettre le curseur de la qualité dans les méthodes agiles n’est pas évident. La qualité est souvent vu comme un « coût important » au sein des projets.
Il est clair que la vision à court terme est souvent le premier soucis de cette vision pessimiste. Tout le monde se rend compte que la qualité devient un atout dans le futur, mais peu arrive à accepter un investissement en démarrage de projet… C’est pourtant le moment fondateur d’une excellence technique.
La qualité technique et les bugs doivent être mis en place dès le début ! N’attendez pas, les impacts sont également humain !
Le « A zero bug policy »
Voici le schéma de ce concept simple qui mérite qu’on le suive. On est pas dans une vision révolutionnaire certes mais mettre en place ce type de règles simples méritent d’amener une rigueur très importante pour les développement et l’entreprise.
Conclusion : Le bug, on le corrige ou on le supprime
Pourquoi ne pas adopter le « A zero bug policy », de l’afficher et de s’y tenir ? Ce principe va au delà de la méthode et amène vers mindset de l’excellence technique voire même humain.
Comment gérez-vous vos bugs ?
Question bête : ça veut dire quoi « supprimer » un bug.
Corriger je veux bien, mais « supprimer ».
Ca veut dire enlever la fonctionnalité dans laquelle se produit le bug ?
Hello,
Je vais devoir préciser. Le « supprimer » signifie enlever ce qui peut provoquer ce bug. C’est dur mais en effet ça peut aller sur une partie de fonctionnalité, une fonctionnalité… Mais on peut aussi décider de corriger.
Il y a de nombreux sites ecommerce qui ont vécu avec le bug qui se produit tous les 1/100000… En fait, ça finit par coûter cher car tu perds un client tous les 100000 (si ce n’est pas plus car le bouche à oreille coûte cher aussi)… Je connais des sites qui ont finit par le payer cher au bout de 4/5 ans… Et les résultats de sondages sont clairs, ce bug qui paraissait anodin a fini par se payer cher.