Des Problèmes Nouveaux

Histoire courte, au dénouement brutal :

Une équipe Tech, à la demande et avec l’appui du CTO, décide de consacrer un (petit) extra de budget à améliorer sa stratégie de prévention des défauts, en se mettant à écrire systématiquement des vérifications automatisées.

Ce faisant, elle découvre immédiatement des problèmes nouveaux et insolites, qui vont l’amener à consommer cette poche en un temps record, et ouvrir la porte aux glissements de délai.

Le Métier s’en aperçoit, demande une explication au Management. Fin de l’histoire.

△

Une autre histoire est possible, moins courte. Mais de quels genre de nouveaux problèmes insolites on parle ? Des problèmes de…

• capacité : “le PO nous met la pression ; il n’avait pas compris que pour renforcer notre couverture de test on allait retirer des stories du sprint”
• différence théorie/pratique : “dans un kata ça marche peut-être, mais dans ce code legacy, on n’y arrivera jamais”
• conception fonctionnelle : “au fait, c’est quoi la règle dans cette fonction ?”
• conformité, fiabilité : “mais en fait ça n’a jamais marché ce truc, c’était buggué dès le départ”
• montée en compétence : “alors oui j’ai pu écrire un test, mais ça m’a pris 2 heures”
• confiance : “et tu crois que tout ça va vraiment résoudre nos problèmes ?”
• motivation : “vous pouvez continuer si vous voulez, moi j’en ai ma claque”
• cohésion : “moi si on poursuit dans cette voie, je me tire”

Avant cette manœuvre, la vie pour l’équipe était plus simple. Pénible, parfois, mais plus simple. Bon d’accord, tendanciellement en train de se dégrader jusqu’au point où on risquait de voir une version entièrement annulée. Mais plus simple.

Avant c’était la rencontre avec l’obstacle qui ralentissait l’équipe. Bim ! Un bug. Paf ! Une démo qui rate. Oups, un module entier à refactorer.

Aujourd’hui, c’est apprendre à éviter les obstacles qui est devenu l’obstacle.

Est-ce qu’on a une vérification sur ce comportement ? Non. On en écrit une. Agencement, Action, Assertion. C’est parti. Oui mais on ne va pas réussir à écrire un test isolé sur ce bout de code. Pour ça il faudrait lui donner tous les objets dont il dépend. C’est comme une forêt de ronces, ces dépendances.

L’équipe, qui s’était dit : “on va juste améliorer nos techniques”, voit maintenant son projet (son projet technique, mais aussi son projet d’apprentissage, et son projet d’équipe) sous un jour nouveau, étrange.

Ce n’est pas encore le prochain plateau d’excellence — loin de là — mais on a passé un cliquet; ce n’est déjà plus “l’ancienne façon”. C’est excitant, et épuisant.

Xavier, CTO, fait le mieux qu’il ait à faire :

• Il écoute
• Il fait bureau des pleurs
• Il aide chacun à intégrer et ajuster ses solutions, et à transformer l’activité

Jusqu’au prochain plateau.

Où on ne se souviendra plus exactement, on ne saura plus dire qui a géré quoi. Mais l’équipe a géré.

C’est beau.

Mais pour l’instant, on manque de visibilité, les ennuis pleuvent.

Publié sur Linked In le 07/11/2024