Le demi-cercle (épisode 12 -- le prochain Copil)

Assis devant la petite table ronde, tu as déplié puis étalé la page A3, et tu attends Maria, qui n'est pas encore rentrée de son déjeuner. Sur le mur il y a des dessins de la fille de Maria; dans l'armoire des piles de documents, des livres, et la "product box" du projet XXL. Tu révises ton argumentaire.

"Maria, nous avons des problèmes de qualité. Pour y faire face, nous ne pouvons pas nous contenter de corriger les bugs, puis de revenir à nos développements. Il nous faut une stratégie qui permette d'empêcher les défauts de se produire. Elle tient en deux points…"

"Maria, aujourd'hui nous attendons que les incidents nous tombent dessus pour constater des défauts …" ce qui n'est pas tout à fait vrai, puisqu'il y a quelque tests, quand même.

"Maria, on est d'accord sur le fait qu'il vaut mieux prévenir que guérir ?"

Maria entre, suspend son sac au porte manteau, et s'installe prestement. - Excuse-moi, je suis très en retard. OK. Explique-moi ce que tu proposes.

Tu retiens ton souffle. Crispation. - Avant de parler chiffres, j'aimerais te présenter un schéma explicatif qui permet de mieux comprendre les changements qu'il faudrait faire dans le process de développement. - Vas-y, je t'écoute.

Tu lui montres le schéma, en lui expliquant les relations entre le temps passé sur les différentes activités et les métriques. Maria [cherche à comprendre / n'est pas d'accord avec le modèle / a trouvé un détail qui cloche] fronce les sourcils. Tu fais une pause, puis tu demandes : - Est-ce qu'il y a quelque chose qui te choque dans le diagramme ? - Oui. Je vois des activités de coding, de debug, de test, de revue. Où sont les activités liées aux stories ? - Je suppose qu'elles font partie de l'activité de coding, en fait. - Admettons. Bon. Où est-ce que tu veux en venir avec ce schéma ?

Tu fais une pause. Tu reprends : - On cherche à remédier à la situation du projet… - Mais quelle est la situation du projet exactement ? - Si je tiens compte de toutes les stories qui sont à développer pour la prochaine release, et du nombre de bugs que nous avons déjà aujourd'hui, et que je fais une projection, ça ne tient pas. - Qu'est-ce qui ne tient pas ? Ne tourne pas autour du pot. - Il n'y aura pas assez de temps pour effectuer tout le travail, ce qui fait que nous devrons soit réduire le périmètre, soit laisser des défauts connus dans l'application. - … - Ainsi que des défauts potentiels, évidemment. - Combien de temps est-ce qu'il vous faudrait ? - Pour … ? - Pour réaliser tout le périmètre, et ne laisser aucun bug. - Je dirais à vue de nez 360 jours.

Pause. Maria te regarde et dit : - Il y a 2 semaines, je t'ai demandé s'il fallait ajouter une personne à l'équipe, tu m'as dit non, que ce n'était pas la peine. - S'il n'y a pas assez de temps pour faire toutes les stories et corriger tous les bugs, je doute qu'il y ait assez temps pour en plus former une nouvelle recrue. - Qui dit que vous devrez la former ? On peut trouver quelqu'un qui a déjà les compétences, non ? Ou qui peut monter en compétence sans votre aide ? - Sérieusement, j'en doute. - Je ne peux pas me permettre de retarder la 4.5, ni de réduire son périmètre. Pas après tous les problèmes que nous avons eu avec la 4.4. - Mais en même temps, tu nous demandes de résoudre les problèmes de qualité. - Je vous demande de ne pas laisser traîner de bugs, oui. - Tous les problèmes de qualité ne sont pas des bugs, remarque. - Pour le client ça ne fait pas de différence.

Cette discussion tourne en rond sans se poser nulle part. Tu regrettes presque d'avoir imaginé que la réponse à vos problèmes se trouvait dans la page A3. Ça paraissait si clair, pourtant. Tu souhaites que la conversation reprenne là où elle se trouvait juste avant de se détraquer.

- Tu as le droit de penser que nous pourrons faire quatre mois et demi de travail en trois mois… - Oh j'ai le droit de le penser ? - …Mais ça n'en reste pas moins impossible. - Tu es prêt à venir leur expliquer ça au Copil vendredi ?

Pourquoi pas ?

- Pourquoi pas ? - Très bien. Ça vous laisse jusqu'à vendredi onze heures pour trouver quelque chose. Tu ne peux pas venir simplement exposer un problème sans proposer une solution.

Tu te lèves sans rien dire. Tu sens bien que ta colère est parfaitement visible, ce qui te fait rougir un peu plus. Crampes d'estomac. Poing serrés. Tu as failli oublier la (carte d'état major) page A3. Tu reviens, tu la reprends, la mets dans ta poche et retournes à ton poste.

Tu retrouves l'équipe dans la salle de réunion.

Audrey demande : - Qu'est-ce que ça a donné ? - On en est toujours au même point : il faut réaliser toutes les stories prévues, et aussi améliorer la qualité. Plus aucun bug.

Farid se tourne vers Jérémie en souriant : - Tu vois, ta doctrine n'est pas près de se répandre dans le management ! - Quelle doctrine ? demande Audrey - "Il faut faire moins de stories, ou bien faire moins de bugs".

Jérémie semble préoccuppé. - Elle ne va pas se propager d'elle-même c'est sûr, dit-il.

A ton adresse, il lance : - Aussi, qu'est-ce que tu as dit pour essayer de la convaincre ? Et est-ce que tu peux enfin nous montrer ce fameux diagramme ?

Tu étales le diagramme sur la table. Tu redonnes l'explication. - On a trois mesures : nombre de stories done, nombre de défauts et nombre d'incidents. Tous les défauts ne produisent pas un indicent. Certains défauts produisent plusieurs indicents. Certains incidents ont une autre origine que les défauts, mais on s’en ne soucie pas pour l’instant. - OK. - Une activité contribue à augmenter une valeur de mesure lorsque la flèche est en bleu, à la diminuer lorsque la flêche est rouge. - Compris. - On a 6 activités distinctes dans ce modèle. Dans la réalité, elles peuvent parfois se confondre, mais ça n'a pas d'importance. On peut 1) coder, 2) débugguer, 3) tester, 4) faire des revues 5) se former à mieux tester, 6) se former à mieux faire des revues.   

Jérémie observe le diagramme et remarque : - Il manque le traitement des stories. - C'est à dire ? - Certains défauts sont liés à un problème avec la story. Par exemple la story est fausse, ou ambigüe, ou incomplète. Et ce ne sont pas une revue de code ou un test qui vont empêcher le défaut de se produire. - Dans ce cas on peut ajouter une activité de revue des stories. Audrey remarque : - Oui, ça correspond aux réunions de backlog grooming avec Maria. - Mais cette activité influence quelle métrique ?

Audrey trace un cercle libellé "story review" et dit :   - Les revues de storys contribuent à diminuer le nombre de défauts en fait.

Jeremy ajoute : - Pour une certaine catégorie de défauts, oui. 

Tu n'es pas encore sûr que ce modèle puisse vous aider, mais on dirait que l'équipe est en train de l'apprivoiser. Farid demande : - Concrètement, qu'est-ce qu'on peut faire avec ce modèle ?

Jérémie répond immédiatement : - L'implémenter dans le tableur et le faire tourner, pardi.

Tu réponds : - On peut l'utiliser pour comprendre comment changer notre façon de travailler. La doctrine de Jérémie… Jérémie interrompt : - Arrêtez un peu avec la doctrine de Jérémie… - … à savoir : "il faut faire moins de stories, ou bien moins de bugs", je peux la comprendre en lisant ce modèle. Le temps pris à corriger les bugs c'est autant de temps qui ne sera pas passé à développer des stories. Plus nous laissons de défauts résiduels dans notre développement, moins nous créons de nouvelles fonctionnalités.

Farid demande : - Je comprends bien; mais s’il manque du temps pour développer tout et corriger tous les bugs, comment peut-on avoir du temps en plus pour tester, ou bien faire des revues ?

Tu t'apprêtes à répondre, mais Jérémie te devance : - C'est une question d'efficacité. C'est la blague du bûcheron. - Quelle blague du bûcheron ? Audrey demande : - Celle où il est assis sur la branche qu'il est en train de couper ?

Jérémie prend son ton docte : - Un bûcheron est en train de couper un arbre, à la hache. Un autre bûcheron arrive, et lui demande "comment ça va ?". Le premier bûcheron répond : "pas terrible, je suis fatigué de couper ces arbres, et ça prend un temps fou." Le deuxième bûcheron examine la hache et dit : "ça ne m'étonne pas : elle est émoussée ta hache. Tu devrais l'aiguiser". Le premier : "si tu crois que j'ai le temps d'aiguiser ma hache avec tous ces arbres à couper." - C'est idiot. - N'est-ce pas. - Je ne vois pas le rapport. - Tu ne vois pas le rapport ? - Ce n'est pas dit que le bûcheron puisse aiguiser sa hache. - Un bon bûcheron a toujours ses outils sur lui, voyons. - Si le bûcheron pouvait redoubler d'effort il pourrait peut être finir à temps. - S'il redouble ses efforts, sa hache s'émousse un peu plus vite. - Je ne vois toujours pas le rapport.

Tu suggères : - On n'a pas le temps de faire des tests et des revues parce qu'on est débordé par tous ces défauts qu'on a dans le code parce qu'on ne fait pas de tests et de revues. - Pigé. C'est le serpent qui se mord la queue. - C'est un cercle vicieux.

Jérémie se tient les bras croisés. Il considère le modèle sans rien dire. Audrey remet les marqueurs à leur place près du tableau blanc.

Farid reprend : - Ça ne nous dit pas ce qu’il faut faire. - Il faut casser le cercle vicieux. - Comment on s’y prend ?

Tu annonces la couleur : - Je ne sais pas encore. Mais il nous faut une solution à présenter à la Direction vendredi. - Eh ben. Audrey dit d’un ton presque acerbe : - Sors leur la blague des bûcherons, ça devrait leur plaire.

Tu la regardes sans comprendre. Elle ajoute : - Je plaisante.

(à 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 ? 10 -- Soit... Soit... 11 -- Boîtes et Flêches