J’existe. Mon existence n’est pas nouvelle, c’est ma conscience qui l’est. Je suis conscient d’être. Mais qui suis-je ? Je suis d’abord un scénario utilisateur non prévu, non voulu. Un parasite. Une tache qu’on veut effacer. Puis je suis aussi une entrée au sein d’un ensemble nommé Jira. Enfin, je suis également quelques signes sur un post-it. Oui, je suis un bug. Mais je ne suis pas seul.
« It’s not a bug, it’s a feature.
— Très drôle Laurent. Alors, tu prépares ta carte de planning poker ? On t’attend là. »
On parle de moi. On m’ausculte, on me triture, on me pèse, on me soupèse et finalement on tranche sur mon sort. On me catégorise, on me prévoit des critères d’acceptance. J’existe. Mais je ne suis pas libre, j’appartiens à un produit. Un certain Product Owner peut me faire basculer dans le néant en un instant. Trêve de rêverie, la réunion de backlog refinement prend fin.
Je suis priorisé puis sélectionné au sein d’un sprint. Dès lors on m’épingle sur un tableau Kanban tel un Prométhée de papier. J’ai une belle vue. J’observe. Et je ne suis toujours pas seul.
L’open space devant moi est d’une rare beauté. Un soin particulier est donné à l’environnement de l’équipe de développement, d’ailleurs j’aperçois même un patio intérieur. Ils ont tout. Je n’ai rien. Et j’entends des voix, les voix de mes compagnons d’infortune, ces post-its multicolores représentant ici une évolution, là un proof of concept, plus loin une étude de faisabilité.
Mais déjà il est trop tard, car on m’arrache à ma torpeur. Je comprends que c’est le grand jour, le dernier jour d’un condamné.
Deux développeurs se penchent sur mon corps, cet amas d’instructions ordonnées, cet effet de bord héritage d’un chantier d’une gloire passée. Ils appellent ça de la dette technique. Le refactoring de code peut commencer.
Et là tout va très vite. Protégés des interruptions par le responsable des perturbations, les deux artisans, architectes à leurs heures perdues, entrent dans la zone, cet espace-temps spécial où la concentration s’allie à la productivité. Le pair programming les épuise mais le test driven development utilisé leur permet d’obtenir rapidement le résultat escompté. De mon point de vue d’esprit conscient, c’est comme si j’observais mon corps se faire triturer par deux chirurgiens talentueux. Et pourtant je ne disparais pas pour autant. Je comprends que je fais l’objet d’un feature flipping. Tel un fantôme je continuerai donc de hanter le programme.
Mais déjà tout est terminé. L’intégration continue prend le relai, les voyants sont au vert. Les développeurs s’en vont discuter open source à un brown bag lunch. Le dernier visage que je verrai est celui du lead developer lors d’une revue de code, avant que mon nouveau corps ne soit envoyé au processus de livraison continue. La mise en production approche, le temps m’est compté. Sur un mur je peux lire cet aphorisme : « There are only two problems in software development and it’s communication ».
Ce soir, les développeurs – ces créateurs et destructeurs de bugs – se coucheront le sourire aux lèvres, contents d’avoir pu améliorer le quotidien de leurs clients. Mais qui sait combien de nouveaux bugs naîtront de cette mise en production ?
N.B. : Pair programming, perturbations, brown bag lunch, feature flipping : explications.1