Le demi-cercle (épisode 10 -- Soit... soit... )

le 03/11/2017 par Christophe Thibaut

The Eye-Brain Law: To a certain extent, mental power can compensate for observational weakness. The Brain-Eye Law: To a certain extent, observational power can compensate for mental weakness. Jerry Weinberg

- J’ai bien reçu votre email. Je vois ce que vous voulez faire. Mais, c’est quoi le but ?

Confortablement calé dans un siège ergonomique dernier cri, et protégé par un rempart naturel formé d’éléments comestibles, combustibles, destructibles, fongibles, flexibles, inamovibles, putrescibles, sensibles et transmissibles, Mazare vous observe, toi et Jérémie.

Jérémie répond : - On souhaiterait analyser le délai de résolution des bugs à l’aide de requêtes que l’interface du bug tracker ne propose pas en standard. - C’est une D.S ? - Une D.S ? - Demande Spéciale. Il y a un formulaire à remplir. Ça permet de décharger le service au cas où quelqu’un veut examiner des données qui ne lui appartiennent pas.

Jérémie lève la main en disant :

- Je t’arrête, dans le cas présent, il s’agit de nos données. - Dans les tables du bug tracker ? Je ne crois pas, non. - C’est notre application. Ce sont nos bugs !

Mazare hésite. Tu reprends mentalement l’énumération, que sa première question avait interrompue, de la partie visible de son bureau. Mazare griffonne un mot de passe sur une note autocollante repositionnable et dit en la tendant à Jérémie :

- Vu comme ça. Prenez le poste au fond de la salle.

Tu t’assois à côté de Jérémie. - C’était facile. - Mazare est un copain. Je lui rends des services sur le monitoring.

En moins de temps qu’il ne faudrait pour seulement entamer le sujet du monitoring, Jérémie a interrogé deux tables, extrait les réponses dans un format tableur, déposé les fichiers sur un lecteur partagé, déconnecté la session, déchiré le mot de passe et remis les chaises en place.

- On a ce qu’il nous faut.

Trente minutes et deux jointures plus tard, le tableur de Jérémie affiche les informations que tu cherchais.

id | issue | date_1 | date_2 | d1-d2 0313 | Reprise données inopérante…| 2015/11/11 | 2016/01/04 | 54 0321 | Pb Boîte de dialogue "choi…| 2015/11/13 | 2015/11/16 | 3 0476 | Erreur calcul rés. S1 vs S…| 2015/11/16 | 2015/11/20 | 4 0477 | Erreur résultat S2 sans S1…| 2015/11/16 | 2015/11/20 | 4 0480 | "version inconnue" dans mo…| 2015/11/18 | 2016/02/03 | 77 … … 1397 | message incorrect après ca…| 2017/04/06 | 2017/05/02 | 26

Tu demandes : - Si tu sélectionnes tous les tickets qui concernent la version 4.3, je veux dire la version qui précède celle que nous avons en production actuellement... - Donc tous les tickets de Novembre 2015 à Mai 2016. - Oui. Combien de temps s'écoule en moyenne entre l'entrée d'un bug et sa résolution ?

Jérémie ajoute une formule et le tableur affiche : 9.390625

Jérémie ajoute encore une formule et dit : - Avec 65 tickets en 181 jours, on a donc entre 3 et 4 tickets en cours de résolution en permanence. Où est-ce que tu veux en venir ?

Tu ne sais pas. Tu n'a jamais été très à l’aise pour interpréter les chiffres. Tu demandes : - Et sur la version 4.4 ? - Alors de Mai 2016 à Octobre 2016…

8.753433

- Et sur la version actuelle ? - Tu veux dire la version en cours de développement ? - Oui. Ça doit faire 4 mois et demi, quelque chose comme ça. - 123 jours, avec 51 tickets. Tous les tickets ne sont pas résolus, note. - Quel est le temps moyen de résolution ? - 10.235475, soit entre 4 et 5 tickets en cours de résolution.

Tu réfléchis tout haut : - Sur la version en cours de développement, non seulement on aura — probablement — plus de tickets au total, mais le temps de résolution est plus long. Donc… - Donc… ? - Donc l'équipe va se retrouver avec plus de tâches que de temps pour réaliser ces tâches. Donc ça coince. - Tu fais une supposition erronée : la durée de résolution représente un délai, pas une charge de travail. - Qu'est-ce que ça change ? Il y a environ 210 jours de travail par an. Multiplie tous les chiffres par un facteur 210/365. Qu'est-ce que ça change ? - Ce n'est pas ce que je veux dire. On ne passe pas 10 jours par ticket. Le ticket passe du temps dans les tuyaux, mais ça n'implique pas que nous travaillons dessus tout le temps. - Encore une fois, qu'est-ce que ça change ?

La discussion produit comme un déjà vu, un arrière-goût, un mélange d'incertitude et de naïveté fébrile. La discussion des gogos qui n'ont pas assez de data mais qui ont déjà trop misé à cette table, et qui s'évertuent pourtant à tenter de deviner ce qui se passe en réalité.

- Allo ? - Pardon. Oui. Qu'est-ce que ça change ? Ces dix jours, c'est le rythme habituel auquel nous faisons les choses. Que le ticket attende 2 jours sur 10 ou bien 8 sur 10, c'est pour la même raison: c'est dû à tout ce que nous faisons à côté de la résolution des tickets : développement, réunions, etc. - Si ça se trouve, la correction des bugs ne prendra pas autant de temps cette fois. - Et en vertu de quoi les bugs prendraient moins de temps à corriger, cette fois ?

Audrey et Farid, qui étaient venus pour la pause de 10h, sont debout derrière vous, à contempler les mêmes chiffres. Audrey intervient : - Si on y met chacun du sien, il doit y avoir un moyen ! - Qu'est-ce que tu entends exactement par : y mettre du sien ? - Faire un effort ! - Je vais supposer que tu veux dire par là, en faire plus, c'est à dire perdre moins de temps. Où penses-tu que nous pourrions gagner du temps ? - Je ne sais pas ! - Parce que c'est ce que cette requête sur le bug tracker ne nous dit pas, jusqu'à maintenant. Jérémie insiste : - J'insiste : il n'est pas dit que ça va nous prendre autant de temps dans cette version que dans la version précédente. - Ah bon ? Qu’est-ce qui s’est amélioré dans la façon dont nous travaillons, depuis la version précédente ? - Eh bien, déjà, on connaît un peu mieux le système, et le métier. - Mais on a un peu plus de code, et les choses se sont encore un peu plus compliquées dans le modèle de données.

Farid intervient d'un ton calme : - Ce qu'il faudrait savoir, c'est d'où viennent les délais.

Audrey : - Ok, mais comment savoir ?

Personne ne sait. Plutôt que de faire une affirmation en l'air, tu restes coi. J'ai assez misé à cette table.

Jérémie referme le tableur, lance son EDI et conclut doctement : - Soit on fait moins de stories, soit on fait moins de bugs.

Audrey se dirige vers le café. - Tu en as de bonnes.

Farid amène sa chaise près de Jérémie et lui demande : - Au fait, Jérémie est-ce que tu aurais quelques minutes pour une revue de code ? J'ai corrigé la 4237 mais je voudrais être sûr que ça tient la route. - OK. Rappelle-moi quel module ça concerne ?

Ils inspectent le code. Tu les observes distraitement. Tu penses : il suffirait de savoir comment s'y prendre avec le code de ce projet. Savoir quelles portes ouvrir et quelles portes ne pas ouvrir, quels obstacles déplacer pour avancer, et ce à quoi il ne faut pas toucher, sous aucun prétexte. Et c'est comme ça qu'on survivrait dans cette base de code : en restant juste à sa surface, comme des patineurs sur un lac, qui auraient une parfaite connaissance des zones où la glace est trop fine. Faire tout au plus quelques changements cosmétiques ça et là, mais sans rien remettre en question.

Tu reprends le fil de la conversation. Farid explique : - Je n'ai pratiquement rien changé, juste cette variable qui devient un champ, et… - Stop. Il y a un bug ici. - Tu es sûr ? - Tu prends la valeur du champ avant d'appeler checkCompleteAmount, et donc tu ne passes pas par cette méthode qui sépare la clé en deux. - Hein ? - Tu es conscient que c'est ce champ qui sert de valeur de clé, d'accord ? - Peut-être… - C'est sûr. Et donc ta valeur de clé va se confondre avec une valeur de période déjà existante. - Quoi ? Je ne comprends pas. - OK. Laisse-moi te donner un exemple : la valeur de clé, c'est le jour concaténé au mois. - OK. - Et on a, disons, le 1er Novembre qui se confond avec le 11 Janvier, parce que "1" collé à "11", produit la même valeur que "11" collé à "1". - Ah la vache ! - Oui, la vache. Avec ce code, tu es parti pour accumuler deux budgets de périodes différentes.

Tu interviens : - On vient de gagner combien de temps ?

Jérémie et Farid te regardent sans comprendre. Tu reprends : - On vient d'identifier un bug, n'est-ce pas ? - Oui, répond Jérémie, et alors ? - En supposant que la revue que vous venez de faire n'ait pas eu lieu, combien de temps se serait écoulé avant que ce bug apparaisse ? - Apparaisse où ça ? - C'est ma question.

Farid tente de répondre. - On n'envoie pas le code en recette avant vendredi. Le temps que Charlène refasse les tests...

Jérémie intervient : - Quel tests ? Ça m'étonnerait que les jeux d'essais actuels contiennent le cas qui produirait le bug. - Alors ça ne pourrait être détecté que chez un client. Au mois de Novembre par exemple.

Tu comptes sur tes doigts : - À la réception du ticket : le temps de reproduire le bug, je dirais 4 heures. - Au moins. - Comprendre ce qui se passe, modifier le code : 1 heure. - Rejouer les tests… - Mettons 1 heure. Déposer la version, gérer la livraison : 1 heure. - Tu oublies qu'il faut aussi potentiellement réparer les données du client. La dernière fois que c'est arrivé ça nous a bien pris une demi-journée. - On est déjà à 10h. On vient de gagner 10 heures.

Farid approuve : - C'est pas faux. On devrait faire des revues plus souvent.

Jérémie intervient. - Pourquoi des revues plus souvent ? Ça prend du temps de faire des revues. - Si une revue comme celle que nous venons juste de faire peut nous faire gagner quelque chose comme 10 heures, je veux bien prendre un peu de temps. - Mais ce n'est pas dit que chaque revue remontera un bug du même genre ! - Non mais avec ce qu'on va trouver en moyenne, on pourrait être gagnant. - Je ne vois pas comment !

Tu réponds du tac au tac : - Tu ne vois pas comment une heure de relecture à deux vient de nous faire gagner 10 heures de travail ? Si on peut détecter un défaut au lieu de le laisser se glisser dans la version en production et avoir à le corriger plus tard… - La raison pour laquelle j'ai vu ce bug, c'est qu'on a déjà eu un incident du même genre il y a deux ans. C'est une coïncidence. Ça ne veut pas dire que toutes les revues vont être aussi fructueuses.

Tu te frottes les yeux comme pour chasser une migraine grandissante. Vous êtes de retour à la table de jeu. Au milieu du fatras. Les joueurs sont autorisés à tous les commentaires qu'ils jugent pertinents, ils peuvent tirer les conclusions qu'ils veulent. Il n'y a jamais assez d'informations, ou bien il y a trop de variations. Et le code est en train de pourrir. On y voit de moins en moins clair. Mais les joueurs continuent de parier, font des conjectures, et parient encore. Ils s'endettent, et c'est toujours la (complexité) banque qui gagne à la fin.

Tu retournes à ta place, en affirmant, plus pour toi même que pour le reste de l'équipe : - Ça vaudrait peut être le coup.

(à 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 9 -- Que faire ?