Illusion de contrôle – partie 3

(précédement …)

Tableau 7

Dans lequel des signaux faibles sont savamment ignorés

Jeanne, Léa, Karim, Victor et Yasmina.

Victor : Je propose qu’on annule la rétro puisque tout va bien.
Karim : Ah, ça tombe bien j’ai plein de trucs à finir.
Jeanne : Bon, le graphe de burn-up, du coup, on le met à jour ?
Victor : Euh, peut-être plus tard ?
Léa : Attends, Yasmina comptait venir à la rétro pour nous parler d’un retour quali du client Revamping …
Victor : On n’a qu’à lui dire de passer. Pas la peine d’attendre la rétro pour ça.
Victor : Moi j’ai un problème avec le module RapportGeneralDtoFactory : ça a l’air assez compliqué d’instancier un objet de cette classe sans devoir instancier toute la smala du module RapportGeneral.
Karim : Ah, toi aussi ? C’est la raison pour laquelle j’ai commenté trois tests la semaine dernière.
Léa : Sans rire vous avez commenté des tests ?
Karim : Euh oui, j’avais passé déjà deux jours sur le sujet; au bout d’un moment faut avancer…
Jeanne : Yasmina a répondu : elle arrive dans 15 minutes.
Léa : C’est embêtant cette histoire de test …
Karim : Tu en as vraiment besoin ?
Victor : C’est à dire que j’aimerais factoriser RapportGeneral avec RapportDetaille parce que ça commence à sentir le copier/coller à plein nez dans ce module …
Léa : Refacto automatique ?
Victor : Hmmm j’aimerais pouvoir tester quand même …

15 minutes plus tard.

Yasmina : Bonjour à tous et toutes. Alors je voulais vous transmettre un retour client qui à mon avis pourrait avoir une certaine importance …
Karim : Bienvenue au feedback, on t’écoute.
Yasmina : Alors le client est globalement content. Il paraît qu’il dit en comité que c’est la première équipe agile qu’il rencontre capable de travailler à cette vitesse, sur des demandes de la veille pour le lendemain.
Léa : Cool.
Yasmina : En revanche, il y a un léger problème avec le RapportGeneral. Dans certaines circonstances, le rapport général plante au lieu de lancer le PDF. Ça fait “null pointer exception” ou un truc du genre.
Victor : Ah. Encore.
Yasmina : Le client aimerait qu’on corrige aussi rapidement qu’on a développé, d’autant que la dernière fois qu’un bug de ce type s’est produit, il nous a fallu trois livraisons avant de voir le problème corrigé définitivement …
Victor : Okééééé…
Yasmina : Et le client nous a signalé que ce bug se produit dans plusieurs rapports différents.
Jeanne : OK, on regarde et on s’en occupe.
Léa : Ce serait le moment de rétablir les fameuses couvertures de tests.
Karim : Très drôle. Elles étaient frelatées tes couvertures…

Tableau 8

Dans lequel ça barde

Alexandre, Jeanne, Léa, Victor et Yasmina.

Alexandre (entre soudainement) : Allo ? Vous êtes au courant ? Y’a plus rien qui marche.
Jeanne : Oui, oui, on a vu Yasmina. On traite le problème directement avec Revamping…
Alexandre : Je vous parle pas de Revamping, mais des douze autres clients qui ont perdu l’accès à leur données de rapport. J’en ai eu trois directement au bout du fil.
Jeanne : Euh ?
Alexandre : Si c’est moi qui vous l’apprend, c’est grave !!
Victor : Attends, qu’est-ce que tu veux dire, douze autres clients ?
Jeanne : Je regarde les logs. Ah oui. En effet. On a eu une NPE sur le process de préparation, mais vu que le code s’est arrêté, le batch suivant a dû bloquer aussi pour les autres clients programmés dans ce batch…
Victor : Le refacto, c’est Karim qui l’a fait.
Alexandre : Tu peux l’appeler ? Il est à son poste ?
Léa : Il est en congé maladie, il a un problème de dos…
Alexandre : C’est la guigne.
Jeanne : Victor et moi on va regarder les différentes versions qu’il a produites.
Alexandre : Aussi, pourquoi je confie autant de C.A à une équipe sans responsable, moi ?
Victor : Qu’est-ce que tu entends par là ?
Jeanne : Victor, tu peux regarder la log en détail du traitement d’hier s’il te plaît ?
Victor : OK tu as raison, je regarde.
Jeanne : Alexandre, on analyse la situation, et on te fait un état des lieux dans quinze minutes si ça te va ?
Alexandre : OK. Je dis quoi au DG de Tech-Co ?
Jeanne : Quinze minutes …
Alexandre : OK.

Quinze minutes plus tard

Alexandre : OK, on en est où ?
Jeanne : Donc voilà ce qui s’est passé : nous voulions modifier deux traitements afin de factoriser la solution pour avoir moins de code à gérer entre Rapport Général et Rapport Détaillé. On a donc modifié la structure de données à l’aide d’un programme.
Alexandre : Rien de bien sorcier jusqu’ici j’imagine …
Jeanne : Non, mais un détail de la structure de la table Rapport Général nous a échappé. Notre programme n’aurait pas dû compiler, mais il a compilé et tourné, en passant sous silence une erreur de structure.
Alexandre : C’est-à-dire ?
Jeanne : Une colonne obligatoire était donc vide, d’où le Null Pointer Exception.
Alexandre : Ok. On fait quoi ? Je dis quoi à mes clients ?
Jeanne : Est-ce tu peux leur demander —ou nous les passer en visio— s’ils seraient d’accord pour nous retransmettre un historique des transactions des trois dernières heures, et nous pourrons les ressaisir, et remettre les choses en état.
Alexandre : Ok. Autre chose à leur transmettre ? Par exemple, à quelle date leurs données seront disponibles à nouveau ?
Jeanne : Demande-leur 2 heures, ça devrait suffire.

Une heure plus tard.

Alexandre : C’est OK. Ils vont retransmettre, et attendre notre go. Merci pour votre réactivité.
Jeanne : Merci à eux et à toi aussi.
Victor : En tout cas à partir de maintenant, plus d’ALTER TABLE sans check automatisé du schéma. Je vais tout de suite écrire un script …
Léa : On devrait pas débriefer le problème avant de prendre des décisions structurantes ?

Tableau 9

Dans lequel l’équipe se recueille

Alexandre, Bernard, Jeanne, Karim, Léa, Victor et Yasmina.
Dans la salle de réunion.

Jeanne : Bienvenue à tous. Pour commencer ce débrief, je vous propose de prendre la parole chacun votre tour. Si possible, une idée à la fois.

Alexandre : Alors, je commence. Moi, je ne veux plus d’incident de ce genre, mais je veux aussi plus de personnes sur cette équipe. C’est une source majeure de revenu pour les 3 ans qui viennent. Je veux gagner des comptes, mais je veux la sérénité aussi. Je croyais qu’on construisait du solide.

Bernard : Je prends le relais : d’accord pour monter en charge, mais ce qu’il faut c’est industrialiser en même temps qu’on passe à l’échelle.

Victor : Tu veux dire passer à l’échelle ou passer sous l’échelle ? Parce que sous l’échelle ça porte malheur.

Bernard : Je vois pas le rapport. Est-ce que c’est vraiment le moment de faire des vannes ?

Léa : Victor, tu veux dire que si on grandit on risque de démultiplier les problèmes ?

Bernard : OK, industrialiser avant de passer à l’échelle.

Yasmina : Ce qu’il y a de positif je trouve, c’est qu’on a su réagir à temps, et on a fonctionné en transparence. Ça aide beaucoup.

Jeanne : Je suis d’accord. Victor, qu’est-ce que tu veux dire exactement ?

Victor : Je parle du sujet de couverture de test. On a commenté des tests à un moment pour gagner du temps. Dans un second temps, on a refactoré du code sur la partie qui n’était plus testée. On a perdu du temps à corriger des problèmes que les tests auraient pu prévenir.

Léa : Moi ce que j’en comprends, c’est qu’il faut maintenir, pas seulement ajouter du code.

Victor : C’est fun de construire du nouveau, mais si la construction s’écroule à la première mise en prod, on a construit sur du sable en fait.

Karim : J’avoue, sans fondation on bâtit sur du sable.

Jeanne : Il nous faut des fondations, donc ?

Victor : Oui, mais on n’a pas le temps de trouver les bonnes fondations du premier coup. Ce serait un luxe : on dépenserait beaucoup trop avant de produire de la valeur. Et puis même, elles deviendraient caduques au bout d’un certain temps. Donc on doit améliorer en marchant.

Karim : Mais on a des fondations : on a une architecture, un process, des outils.

Victor : Notre fondation, c’est pas tant l’architecture, ou la structure de nos applications, ça, ça devra changer aussi. Ce qui ne change pas, c’est d’avoir à constamment stabiliser ce qu’on produit, pour sécuriser les changements.

Jeanne : Et on devra sécuriser tous ces changements, avec un meilleur process.

Victor : Pareil, on ne va pas trouver le meilleur process, les best practices d’un coup. Notre fondation c’est d’améliorer en continu.

Alexandre : C’est à cause d’une amélioration qu’on a planté douze clients.

Bernard : C’est parce que l’amélioration du code n’était pas soutenue par un process de non-régression. On doit améliorer notre process, en l’examinant, et on peut l’examiner via des incidents tels que celui d’hier.

Victor : Donc, la fondation, c’est de partir du principe que ça changera tout le temps et qu’il faudra tout le temps consolider nos process, notre savoir faire.

Jeanne : Il faut maintenir la maintenabilité.

 
(fin de la première partie …)

Deixe um comentário

O seu endereço de e-mail não será publicado.


This form is protected by Google Recaptcha