Dans un processus de développement idéal, chacun piocherait une user story dans la pile des US à réaliser, réaliserait toutes les tâches attachées à cette US dans les temps estimés, poserait cette US sur la pile des US à valider, piocherait la story suivante etc.

L’idéal ? Peut-être. Le rêve, non. Le cauchemar, oui.

À moins que votre projet ne consiste à poser aux développeurs des exercices pédagogiques ou des puzzles de type Advent of Code, s’il se déroule de cette manière il court à sa perte.

Un modèle de processus, c’est un diagramme. Un dessin schématique dont le sens peut se résumer à : “tu vois ce que je veux dire”. Un tel diagramme existe peut-être pour votre projet. Si ce diagramme a été tracé après 2005, il contient probablement une boucle, sous la forme d’une flèche qui remonte le temps, de la droite vers la gauche, en “sautant” au dessus de la flèche qui achemine des boites de la gauche vers la droite.

Non seulement aucun·e développeur·se n’a besoin d’un tel diagramme pour comprendre l’essentiel de ce qui va se dérouler durant le projet, mais en plus l’idée qu’on cherche à défendre ici est erronée. Certes le processus se déroule et pousse ses stories vers la production comme un fleuve charrie des boites vers la mer, mais nous ne nous baignons jamais dans le même fleuve.

🏞

Puisque le projet consiste à réaliser un système, il faut bien que le diagramme s’efface pour laisser place au réel.

Entre parenthèses, c’est là que le rôle du coach prend tout son sens. Le coach est justement la personne susceptible d’aider l’équipe à traiter le réel pendant qu’elle apprend à faire …du Scrum. (D’où le nom “Scrum Master”… 🤔 oui, bon, bref).

Quand au réel, il se charge de former l’équipe (et de la déformer aussi).

— la story qu’on a validé il y a 2 semaines ? Elle buggue.
— la story qu’on avait estimé à 3 points ? C’est plutôt 21.
— le système de points au fait ? On s’en passerait bien.
— oui bien sûr, le nouveau “fait des tests”. À coup de System.out.println
— binômer ? Si ça vous amuse. Quand à moi j’aimerais mieux pas.
— oui mais en binômant on produit du code plus propre.
— et plus fiable aussi. Mais le PO dit qu’on crame deux fois plus de budget…
— depuis qu’on fait cela, on résoud plus vite nos différends sur le code
— au moins il y a un standard, avant ce n’était pas le cas
— c’est clair : il faut changer de binôme souvent. C’est mieux.
— le Sponsor nous a félicité dis donc ! Vive le pair programming ?
— pas dit qu’en codant chacun en solo on aurait pas mieux fait.

À mesure que l’équipe se coltine le réel, son état de l’art, ce recueil théorique de recettes et de principes qui ne prend forme concrète que lorsqu’une discussion y fait appel, suit la longue pente descendante de la dette. Une pente entrecoupée — si l’équipe prend le réel par les cornes au lieu de s’en cacher ou de le maudire — de changements de plateau spectaculaires.

🧗🏼‍♀️

publié sur LinkedIn le 21/03/2023