Gérer le backlog de bugs : les 9 cercles de l’enfer

Temps de lecture : 4 minutes

Ah la la, les bugs.

Tout product owner avec un minimum de bouteille pourra vous le dire : Gérer les bugs du backlog, c’est comme pénétrer dans les 9 cercles de l’enfer. Pour la visite guidée, c’est par ici.

Enfer 1 – Ils sont nombreux

Dès que votre application chérie commence à avoir un peu de vécu, les bugs rappliquent. Et il faut croire qu’ils se reproduisent entre eux dans le backlog tellement ça monte vite.
Et si vous avez la malchance de récupérer un backlog légué par votre prédécesseur, il n’est pas rare qu’il vous ait laissé quelques centaines de bugs car il ne savait pas quoi en faire.
C’est d’ailleurs peut-être pour ça qu’il s’est barré de la boîte tiens. Trop de bugs, ras le bol je me casse.

Enfer 2 – Ils arrivent de partout, mais vraiment de partout

Les tickets JIRA de bug sont créés par un peu tout le monde (QA, devs, clients, support, équipes sécurité, vous-même…) et atterrissent sauvagement dans votre backlog.
Il vous suffit d’aller sur JIRA, de cliquer sur le bouton refresh pour en voir des nouveaux débouler. Franchement c’est l’angoisse.
Si vous avez de la chance, certains sont bien qualifiés (souvent ceux rédigés par la QA) et pour d’autres, ça laisse franchement à désirer. Pas de logs ? même pas un petit screenshot ? Non c’est vraiment l’enfer je vous dit.
On a clairement envie de le dégager ce ticket là mais non, on va être pro, on va prendre quelques minutes pour recontacter la personne qui l’a créé et cette même personne vous répondra, légèrement irritée : « bah c’est pourtant clair non ? ».

Enfer 3 – ils ne sont jamais rédigés pareil

C’est un effet de bord de l’enfer 2. Comme ces bugs ne sont jamais rédigés par les mêmes personnes, et bien ils n’ont jamais le même template.
Généralement la QA fait ça bien, avec vidéo, screenshot, scénarios et log et fichier de test. Mais pour d’autres, faut s’agripper.
Du coup en séance d’affinage vous vivez un vrai moment de solitude. Vous déballez vos bugs et les développeurs n’y comprennent rien. Il ne vous reste plus qu’à les remballer après avoir fait perdre une heure à tout le monde.

Enfer 4 – on n’arrive pas toujours à les reproduire

Un grand classique, le bug est bien présent chez le client mais impossible de le reproduire à la maison. Là c’est du pain béni pour les devs : « bah si on ne peut pas le reproduire on ne peut pas le corriger quoi… ».
Mais pendant ce temps-là votre client, lui il l’a toujours son fichu bug bloquant-critique-urgent qui va péter son business.
Y a plus qu’à payer des pintes aux devs pour qu’ils se bougent ou encore jouer de la flûte au DSI furax qui est au bout du fil.

Enfer 5 – ils n’apparaissent pas sur tous les serveurs

Bon ce bug relou qui est sur le serveur de dev mais nulle part ailleurs. Est-ce que ça vaut le coup de se faire chier à le corriger franchement ?
J’ai envie de répondre non. Mais la QA va venir vous rappeler que leurs scénarios de test automatiques ne passent plus et qu’ils n’arrivent plus à valider quoi que ce soit.
Oui on n’y coupe pas, va falloir s’y coller aussi.

Enfer 6 – on ne sait jamais trop comment les prioriser

Bon une fois qu’on a géré l’urgence, c’est à dire tous les bugs bloquants et critiques, qu’est-ce qu’il nous reste ? Bah les bugs majeurs et mineurs. Bien.
C’est là qu’on commence à être paumé. Surtout quand on a 200 bugs qualifiés majeurs dans le backlog, et qui existaient avant que vous n’arriviez dans cette belle société.
On choisit comment ? on fait pic et pic et colégramme ?
Bon encore une fois on va être pro, on va se retrousser les manches et se les taper tous en essayant de les comprendre. Et c’est là que vous retombez dans l’enfer 3.

Enfer 7 – on ne sait jamais trop comment les estimer

L’estimation des bugs en séance d’affinage c’est magique aussi. On va montrer ce bug aux développeurs en espérant que ça leur parle. Et après vient le moment de l’estimation. Et là c’est le drame. Contrairement à une feature avec des specs claires, l’estimation d’un bug, c’est l’inconnu pour un développeur.
Certains bugs ont des root causes provenant du fin fond du code legacy qui appelle un mystérieux module COBOL dont tout le monde tait le nom de peur d’en prendre la responsabilité. Et là, va l’estimer ton bug.
Allez, bonne chance.

Enfer 8 – on ne sait jamais trop combien on doit en prendre par sprint

Quand vient le moment du sprint planning, c’est aussi une question que se pose le product owner : combien de bugs j’embarque dans le prochain sprint ? 3 ? Pourquoi pas 5, 10, 15 ? Pourquoi pas 0 ?
C’est quoi la règle ?

Enfer 9 – Corriger des bugs, c’est bouffer du temps sur la roadmap métier

A force de fermer les yeux sur les bugs, l’appli est truffée de pièges. Impossible de faire plus de 3 clicks sans avoir un vilain message qui pète à l’écran.
Les utilisateurs n’en peuvent plus et vous le font savoir. Si vous ne réagissez pas vite, ça finit par monter très haut pour redescendre très fort dans votre face.
Alors on se retrousse les manches et on dépile les bugs. Et là on tombe sur tous les 8 cercles de l’enfer précédent.
S’ajoute à cela le 9ième enfer : les bugs vont flinguer votre roadmap. Vous étiez déjà à la méga-bourre sur toutes les dates de livraison prévue et en plus vous vous mettez à dépiler du bug parce que votre application est devenue inutilisable.
Naturellement, vous lancez donc un sprint dédié à la correction de bug. L’équipe est ravie, vous vous en doutez bien.
Au bout de votre sprint de 2 semaines, les gars ont réussi à corriger 10 bugs. Cool. Seulement, il vous en reste 190 dans le backlog, et pour couronner le tout, il y a eu 7 nouveaux bugs qui ont rappliqué dans le backlog pendant ce temps là. Et bien sûr, ils sont super mal rédigés.
En général, à c’est à ce moment-là que le PO commence à songer à la démission.