Le demi-cercle (épisode 9 -- Que faire ?)

le 27/10/2017 par Christophe Thibaut

Since practical computation demands that implicit assumptions be brought out into the open, it is no coincidence that computer programmers are attracted to an approach devoted to studying how people make assumptions. Gerald Weinberg

numéro : 4240 date : 2017/08/29 statut : en cours type : bug sévérité : grave émetteur : C. COURDEL nature : report budgeté partiel ne marche pas description : je passe l’année budgetée, effectue un report partiel, option sans dépassement, je valide, rien ne se passe!!! prise en charge : _ statut résolution : _

Tu viens d’ouvrir le ticket 4240 et tu parcours la description en marmonnant. Il va falloir appeler Claudia. Tu te demandes si ça ne vaudrait pas le coup de tenter de reproduire le bug avant de l’appeler, histoire d’en savoir un peu plus (et puis tu te sentiras moins bête quand il faudra lui demander des détails). Tu n’as pas la moindre idée de ce qui a pu se passer.

Tu te retrouves à nouveau comme en rêve devant l’immeuble blafard, massif, dans cette rue déserte. Cinq étages. Toutes les fenêtres sont condamnées. La pluie ruisselle le long des croûtes de crépi qui sont encore collées ça et là sur le long mur de brique beige. C’est déprimant et inquiétant à la fois. Il faut rentrer là dedans. Login, mot de passe.

Tu soupires tellement fort que Jérémie t’as entendu. - Ça va ? - Non ça va pas. - Tu es sur la 4240 ? Si ça se trouve Claudia Courdel, eh bien elle n’a pas les bonnes données de départ, et du coup ça marche chez nous mais pas chez elle. - Mais quelle sagacité !

Trois secondes de silence longues comme deux minutes.

- Si tu le prends comme ça… - Je sais pas moi, on pourrait d’abord regarder avant de décider… - J’émets juste une hypothèse… - Non. Tu émets un avis. Une hypothèse, ce serait si tu disais: je voudrais démontrer que le défaut se produit dans l’environnement de Claudia mais pas dans le nôtre. Je vais donc commencer par comparer les deux bases de données sur les tables concernées. Si elles sont identiques, j’examinerais les fichiers récemment importés, et puis… - Tu joues sur les mots.

Pause. Je n’ai jamais mis les mains dans le code en question. Et en tout cas ce n’est pas de ma faute. Mais en ce moment précis, j’ai juste besoin d’avoir raison. Alors je suis en train de me fâcher avec la seule personne qui peut m’aider sur ce ticket.

Jérémie se concentre sur son écran. Il a l’air tendu.

Tu te lèves, tu te rapproches de Jérémie et tu lui dis : - Je me mets en colère, et je me trompe de problème. Et je dis n’importe quoi. Je retire ce que j’ai dit, c’était nul, excuse moi. - Pas de mal.

Silence. Tu fais dans ta tête la liste des trucs à faire aujourd’hui. Ou au mieux avant mercredi.

Tu vas vraiment te lancer sur ce ticket ? Je croyais que tu devais établir un plan d’action pour en finir avec ces problèmes de qualité, accompagné d’une estimation de charge pour sa mise en œuvre. C’est urgent ! Et il y a aussi le redesign du module budget, sur lequel vous avez convenu de travailler ensemble, tu te rappelles ?

Tu contemples à travers la fenêtre la congestion habituelle du trafic sur le boulevard à 8h30.

- J’ai besoin d’un café. Ça te dit de prendre un ? - Je suis sur un truc… - Je te ramène quelque chose ? - Non merci. Sur le trajet vers le coin-cuisine, tu repenses au rêve que tu étais en train de faire quand ton réveil à sonné. Tu te fais la remarque que si tu les notes tout de suite en te réveillant, tu retiens mieux tes rêves.

Ça se passe dans un bowling. C’est une partie entre deux équipes qui tourne mal. Tu es dans une des équipes, celle qui perd. Tu n’as fait que des gouttières depuis le début de la partie. Tu te tiens debout devant la piste. Un sentiment de gêne. Tu te cherches une contenance en sirotant une bière éventée. Un des joueurs — tu ne sais pas qui c’est, visage indéfini — est écœuré par la nullité de votre score, au point qu’il lance sa boule de bowling dans l'afficheur des scores en hurlant « maintenant on va voir qui c’est les meilleurs ! ». Et tu te réveilles.

Évidemment, le coin-cuisine est en désordre. L’évier déborde de toutes les tasses de café d’hier après-midi. Tu laves quelques tasses. Tu les essuies. À votre service. Tu réfléchis.

Voyons, 51 tickets, à raison de… à raison de combien d’heures par ticket ? Je n’en sais rien, moi. Si ça se trouve, entre 2 et 4 heures par ticket ? Sans compter le temps de relivrer, sans compter les réunions intermédiaires… Mais non, certains tickets ne prennent même pas 10 minutes.

Tu te fais un café, puis tu cèdes la place à un trio particulièrement bruyant qui vient d’arriver. Tu retournes à ton bureau. Tu comptes naïvement sur le café pour clarifier un peu tes pensées. Tu ouvres ton cahier et tu commences une liste.

Jamais vu une matinée aussi lente.

Tu réfléchis. Tu demandes à Jérémie :

- Jérémie, pour résoudre un ticket, il nous faut combien de temps ? - Ça dépend du ticket.

Évidemment.

Tu trouves une meilleure question : - Le temps de résolution d’un ticket : de combien de choses différentes ça dépend ? - Pas compris. - Quels sont les facteurs de vitesse de résolution d’un ticket ?

Farid, qui est en train de démarrer son PC dit : - Bonne question. Il y en a un certain nombre, mais le plus important c’est : est-ce que le ticket est un bug ou bien une demande d’évolution.

Jérémie ajoute : - Est-ce que c’est un problème de calcul, ou un problème cosmétique, ou bien dans les données… - Est-ce qu’on peut le reproduire facilement ? - Est-ce que la personne en charge du ticket connaît bien cette partie du code ? - Oui, ça c’est obligatoire. - Ça devrait être obligatoire, mais ce n’est pas forcément le cas. - Tu te charges du ticket : c’est donc que tu connais le code. Sinon tu risques de faire pire que mieux. - Dans l’idéal, oui. - Dans l’idéal, il n’y aurait pas de tickets. - C’est plus facile à estimer, du coup. - Donc : qui s’en occupe, c’est un facteur. - Pas qui s’en occupe, mais : est-ce que la personne qui s’en occupe connaît le code. - Le temps qui s’est écoulé depuis que le ticket a été enregistré. - La qualité du code dans lequel se trouve le problème.

Tu notes tous ces facteurs sur ton cahier. Tu ajoutes, en énonçant à voix haute : - Est-ce que le code dans lequel se trouve le problème a des tests ou non.

Tu te perds soudain dans des réflexions vaseuses. Le coup du café ne marche pas. Tu reprends : - Comment est-ce que l’on estime le temps de correction des tickets ici, Jérémie ? - Tu es là depuis assez longtemps maintenant, tu devrais savoir ça : on utilise le pifomètre. - Ah. - On ne se pose pas la question de combien de temps ça va prendre, en fait. - Mais moi je me la pose.

Farid demande : - Pourquoi faire ? - Maria me demande de faire en sorte qu’il n’y ait plus de problèmes de qualité dans la prochaine version. Ni dans les suivantes. - Et comment tu comptes t’y prendre ? - Pour l’instant, je n’ai pas d’idée. Mais ça serait utile qu’on en discute tous ensemble.

Jérémie, sans quitter son écran des yeux : - Et bim. Encore une réunion.

Un point partout.

Audrey entre la première dans la salle de réunion. Néon blafards. Restes de viennoiseries sur la table. - Merci, les gobelets de café et les miettes. Je te jure !

Tu exposes ton sujet, sur un ton neutre : - Bon. Maria nous demande de résoudre les problèmes de qualité avant la prochaine release, qui a lieu dans trois mois exactement, et c’est sa priorité numéro 1. Elle a besoin de savoir quelle solution on envisage et quel budget ça représente.

Jérémie demande : - Qu’est-ce qu’elle entend par problèmes de qualité ? J’ai bien une idée, mais j’aimerais connaître votre point de vue.

Tu te connectes sur le PC de la salle, et tu cherches l’icône du bug tracker en disant : - On a à ce jour 51 tickets en attente ou en cours de résolution. C’est plus que le nombre total de tickets qu’on a reçu sur la dernière version livrée en production, et on n’est qu’à 60% d’avancement sur cette nouvelle version.

Farid reprend : - Encore une fois, tout n’est pas du bug. On devrait faire le tri avant de se lancer à fond dans la résolution. - Bien sûr. En fait je me demande même si ça vaut le coup de résoudre tous ces tickets. - Pardon ? Lance Audrey. - Je pense qu’il faudra plus de trois mois pour les résoudre, même en ne faisant que ça pendant 80% du temps. - Si tu comptes livrer une version bugguée et sortir vivant de la première démo tu as encore du chemin à faire dans la boîte… - On peut le voir comme ça. Mais à l’impossible nul n’est tenu. - Donc toi, tu serais partisan de laisser les bugs dans le produit ? - Audrey, tu as remarqué, j’imagine, que certains tickets sont apparus du fait d’une correction précédente ? - Oui. Ce n’est pas la majorité des cas. Et qu’est-ce que tu proposes, en fait ?

L’ambiance est tendue. Ton baromètre interne est formel : « Nœuds à l’estomac. Tendu, avec possibilité de coups de gueule. » Tu n’aurais pas dû prendre ce troisième café. Ce n’est peut-être pas une question de café. Tu réponds à la question :

- Je propose qu’on trouve des mesures préventives, de manière à améliorer notre process, et qu’on les présente à Maria, afin qu’elle valide notre stratégie et nous aide à la mettre en place. - Corriger les bugs, ce n’est pas du préventif ? - Ben non. Tu attends que les bugs se manifestent, ensuite tu les analyses, et ensuite tu les corriges. Où est la prévention là-dedans ? - Ok. Si on faisait un peu plus de tests…

Jérémie interrompt Audrey : - Alors là, je t’arrête. Pour un programme même trivial, comme une simple calculatrice, que tu voudrais couvrir entièrement, c’est à dire exécuter tous les chemins possibles dans le code, au moins une fois, en combinant toutes les entrées possibles, il te faudrait un temps quasi infini. - Quasi infini, ça ne veut rien dire. - Ce que je veux dire, c’est qu’on ne peut pas tout tester. - Alors du coup on ne teste rien. - Pas rien ! On a une couverture de 26% ! Mais si tu veux t’amuser à tout tester, c’est ton choix. - On a 26% donc 74% du code n’est jamais vérifié. Mais on ne peut pas tout tester, donc ce n’est pas grave.

Tu as l’intuition qu’entre Audrey et Jérémie ce n’est pas la première fois que le ton monte.

Audrey ajoute précipitamment : - C’est comme si tu disais : le vélo ça n’ira jamais aussi vite qu’en train. Donc on va à pied. - N’importe quoi ! Tu relis tes notes : Bugs — demandes de changement Tests — quasi-infini — 26% — rien — tout

Dans cet immeuble imposant qui demeure sous la pluie, au quatrième étage, il y a une grande salle qui servait probablement à ranger du matériel. Il y règne un désordre indescriptible. Cette salle possède une particularité. Sur une des fenêtres, les planches qui servent à barrer l’accès sont mal ajustées. Si tu arrivais à ramper jusque là, tu pourrais presque, en t’aidant d’une barre à mine ou même d’un tournevis assez grand, démonter une planche. Tu t’apercevrais alors qu’à l’extérieur il fait nuit également. À quoi bon ?

Farid tente de calmer le débat, en changeant de sujet : - Que l’on teste ou pas, dès qu’on écrit du logiciel, on a des bugs, c’est la vie.

Audrey rétorque : - Planter une démo, voire se faire virer, c’est la vie aussi. On pourrait essayer de ne pas se faire virer. Si on peut l’empêcher, je suis partante. - On ne va pas se faire virer. - Ce n’est pas la question. La question c’est : est-ce qu’on déclare forfait devant les bugs ou bien on cherche une meilleure façon de faire ?

Tu es enfin arrivé à te connecter au bug tracker sur le PC, et à lancer la requête que tu avais concocté la semaine dernière. Tu demandes l’attention de l’équipe en pointant le tableau qui se présente à l’écran.

- Voici une synthèse de tous les bugs ouverts et résolus sur la précédente version livrée en production, par type de ticket.

Tu penses à ta dernière conversation avec Oleg. Tu dis :

- Tous les incidents ne proviennent pas d’un défaut dans le code. Un défaut dans la documentation peut être à l’origine d’un incident. - Je vois.

Tu poursuis : - Il nous manque une information cruciale dans ce bug tracker : le temps passé pour corriger un bug.

Jérémie : - Facile : c’est le délai écoulé entre le moment où le bug est pris en compte chez nous, et le moment où son statut passe à résolu. - Oui mais l’info n’est pas renseignée. Il y a une date de création, mais il n’y a pas la date de prise en compte, ni la date de résolution. - Il suffit de lire la table historique des modifs. - Comment on fait ? - Là, maintenant ? Ça va prendre un peu de temps… - Tu penses qu’on pourrait faire ça quand ? - On ne peut pas accéder à la table historique en mode normal. Il faut des droits d’accès sur les tables. C’est Mazare, à la prod, qui m’a montré ça. - Quand est-ce qu’on peut aller le voir ? - À peu près n’importe quand. Sauf le vendredi. - Pourquoi pas le vendredi ? - Le vendredi, Mazare est super occupé. Il déjeune même devant son écran. - Occupé à quoi ? - À vérifier que personne ne fait de mise en prod.

Audrey se lève. Tout le monde se lève. Audrey murmure en sortant : - Cette boîte, il y a des jours, je te jure…

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch 6 -- Conseils à emporter 7 -- Crise / Opportunité 8 -- Le Cinquième Étage