Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
J'ai surtout bossé dans des environnements de start-up dans lesquels le temps joue contre nous.
La raison principale étant qu'on consomme du cash sans forcément remplir les caisses.
Du coup, ça met pas mal de pression.
Et je pensais que dans les autres boîtes classiques avec des business motels rentables, c'était différent.
Bah non, pas forcément.
Je remarque qu'il y a souvent ce que j'appelle le syndrome du lapin blanc.
On est en retard, tout le temps en retard.
Alors parfois je pose la question, en retard par rapport à quoi ?
Et là j'ai des yeux à gare, un peu perdu, comme si ma question était incongru.
Être en retard en fait pose la question de la référence.
Je suis en retard, mais ok, mais par rapport à quoi ?
Et c'est là que le bablesse.
Car bien souvent, on est en retard par rapport à des choses qui se sont passées en amont du projet.
En retard par rapport à un planning qui a été cadré par des accords commerciaux,
avant même de s'adposer à la question de la faisabilité.
En retard par rapport à des estimations qui sont fausses.
Par manque de temps, par manque de compétence, par manque d'information,
par manque de connaissances du projet,
les raisons pour lesquelles les estimations sont fausses sont multiples,
surtout quand on n'a pas eu les mains dedans.
Et du coup la réponse à ce moment est souvent la même.
Faut bosser plus pour rattraper le retard.
Je dois reconnaître une chose, c'est que les coups de bourgons ont l'avantage de souder une équipe.
Par contre attention, l'équipe fait partie des livrables.
Si l'équipe se défonce pour sortir une itération, comment va-t-elle remplir le lendemain ?
A quoi bon foncer si c'est pour devoir ralentir le rythme après ?
Pour moi, les seules raisons qui me paraissent valables, c'est de devoir tenir une date.
Une date forte, tu vois, comme un lancement, un plan de com, une livraison client symbolique.
Par contre attention, c'est le signe qu'il y a quelque chose qui ne va pas.
Et d'ailleurs le manifest nous dit, les processus agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires et les développeurs et les utilisateurs devraient être
capables de maintenir indéfiniment un rythme constant.
Mais pourquoi ? Après tout tu primes dire c'est fun.
Work hard, play hard et puis on a toute la mort pour se reposer.
Sauf que à trop tirer sur la corde, tu ne sais pas quand elle va casser.
Et c'est rarement au bon moment.
Quelle est la qualité de ce que tu fabriques quand tu es fatigué ?
Tu vois le cercle vicieux arrivé ? Tu es fatigué donc tu produis du moins bon code.
Donc des bugs arrivent qui te ralentissent encore plus.
Donc tu bosses encore plus pour compenser ?
Tu t'épuises d'autant plus et tu es encore plus fatigué ?
Tu es fatigué donc tu fais des erreurs etc.
Et Last but not least, au delà des enjeux humains, ce qui est déjà pas négligeable,
mais en dehors de ça, c'est aussi une question de devenir prévisible.
C'est une question de pouvoir anticiper les choses, de pouvoir donner des orientations au business,
le business a besoin de savoir comment les choses vont se passer et s'y identifier.
Si tu fais le yo-yo dans ta velocité en alternant des sprints de rush et des sprints de repos,
l'équipe n'est pas prévisible.
Or c'est bien l'enjeu à un moment, donner de la visibilité au décideur.
Donc on retrouve cette idée de rythme constant, mais il y a une autre notion.
Indéfiniment, on est là pour longtemps.
C'est comme faire un marathon en courant à la vitesse d'un sprint.
J'ai déjà testé et c'est une très très mauvaise idée.
J'ai couru une fois dans ma vie un marathon et j'ai couru la première heure à ma fréquence
cardiaque maximale.
Ce qui est complètement stupide, mais en fait, pour te rassurer, c'était pas volontaire.
J'avais juste oublié que j'avais vieilli, que ma fréquence cardiaque maximale avait
bien baissé.
Je peux te dire que à partir du 26e km, ça a été très très dur.
Et dans un marathon, il y a 42 km.
Donc ça fait encore un paquet de kilomètres où j'y suis allé pas à pas.
C'est pas malin.
Et puis il y a une autre notion encore aussi.
On dit bien, les commanditaires, les développeurs et les utilisateurs ensemble.
Il y a cette idée qu'à un moment donné, c'est pas juste une des parties prenantes
qui doit donner le coup de bourg.
C'est tout le monde, on est dans le même bateau.
Bref, viser un rythme soutenable, c'est trouver le bon compromis entre donner le meilleur
de soi et garder de l'énergie sur la durée.
Je te remercie d'avoir écouté ce podcast.
J'espère qu'il t'a plu.
On en est pas mal sur iTunes.
On commence à collecter pas mal d'évaluation.
Je vous en remercie.
Je t'en remercie.
C'est vraiment super.
Il faut continuer.
Il faut continuer.
Ce sera le meilleur moyen de répondre le podcast, de le faire connaître et de partager
ces idées avec un maximum de monde.
Je te remercie.
Je te souhaite une bonne journée.
A demain.