Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Le côté peut-être le plus novateur du manifestement
tient pour moi à son côté itératif et incremental.
Ce sont ces notions qui sont les plus difficiles à faire comprendre.
Je veux dire, vraiment.
C'est pas la technique, c'est pas les procédures, c'est pas...
Non, c'est vraiment cette notion pour moi.
À chaque fois que je fais un cours qui est la plus difficile à comprendre.
C'est pourtant dingue car le monde du vivant est itératif et incremental.
Avec le printemps, la maison ressemble à une arche de noé.
Pousse un canoton et châton envahissent la maison le temps de prendre des forces
et aller vivre leur vie dans la nature.
Ils sont nécomplés, en tout cas ceux qui survivent.
Ils vont grandir et bien entendu à la naissance,
ils ne peuvent pas encore faire tout ce qu'ils pourront faire plus tard.
Les châton ne peuvent même pas encore ouvrir les yeux.
C'est difficile d'explorer le monde.
De toute façon, ils tiennent à peine sur leurs pattes.
Mais plus tard, plusieurs cycles quotidien et annuel après,
ils pourront faire beaucoup plus de choses.
L'agilité apporte des cycles beaucoup plus courts
que les approches classiques cyclenvées.
Quoique, est-ce qu'on peut encore dire classiques aujourd'hui ?
Les approches agile s'adaptent en contenu au contexte.
Sauf que...
Pour accélérer, cela demande de la maîtrise.
Si tu mets un kidney trop glissérine sur ta deux chevaux,
tu vas aller plus vite.
Mais est-ce que tu as vraiment envie de rouler à 200 km heure
avec une deux chevaux ?
Si tu attaques un virage avec des pneus lisses,
tu as plutôt intérêt à rouler tranquille.
Pas à faire le fou et à te croire sur un circuit.
J'ai essayé et ça a mal fini.
Bon, j'étais jeune et con depuis j'ai juste lié.
Principe numéro 9 du manifeste.
Une attention continue à l'excellence technique
et à une bonne conception renforce l'agilité.
L'excellence technique, est-ce qui te donne de la maîtrise ?
Sans la maîtrise, la puissance n'est rien.
Et si tu reconnais un slogan de pub, c'est normal.
Si tu pédales plus vite dans une fosse à purin,
tu vas juste en mettre partout.
Pas vider la fosse.
C'est le grand reproche que je fais à Scrum.
Il balaie la dimension technique d'un revers de main.
On recrute des gens compétents qui font bien le boulot.
Voilà, problème réglé.
Circulé, rien à voir.
Pourtant, dans l'adoption des pratiques agiles,
les pratiques techniques sont les moins adoptées.
Et je me suis longtemps posé la question du pourquoi.
Alors, bien sûr, c'est une interprétation très personnelle que je te livre.
Je pense qu'il y a au moins deux facteurs.
Le premier, c'est que ça ne se voit pas.
Ou le moins, ou pas tout de suite.
Un bord des rituels, des post-it, ça se voit tout de suite.
C'est visible.
Alors que faire du code propre, ça ne se voit pas.
A l'arriqueur du code CRAD va se faire sentir.
On parle de code SMELL.
D'abord des développeurs.
Mais si ça pourrit trop, ça va aussi se voir par les utilisateurs.
Mais du code propre, c'est perçu comme normal.
Les trucs, c'est que dans la tête de beaucoup de monde,
c'est normal qu'un développeur fasse du bon boulot.
Y compris dans la tête des développeurs.
Bah non, ça s'apprend.
Et c'est d'ailleurs loin d'être la norme.
J'ai aussi une explication complémentaire.
Et peut-être plus importante d'ailleurs.
C'est aussi ce qui remet le plus en cause le développeur.
Finalement, tant qu'il s'agit de changer le fonctionnement du groupe,
chacun garde sa cohérence interne.
Mais changer des pratiques techniques,
c'est remettre directement en cause le développeur dans l'intime.
Et pas grand monde aime ça.
Je pense que c'est agréable pour personne.
Par contre, certains ont compris que le bénéfice d'ailleurs
était beaucoup plus grand que l'inconforte temporeur
de redevenir débutant.
Car sauf à tomber dans la marmite des bonnes pratiques à l'école
ou dans la première expérience professionnelle,
cela va demander parfois de déconstruire des années de travail,
d'expérience, de pratique,
pour accepter de voir le monde sous un angle différent.
C'est particulièrement vrai pour deux pratiques.
Le TDD et le Père Programmes.
Ils remettent tellement en question le développeur dans ses habitudes
qu'elles sont difficiles à s'approprier.
Bref, si tu veux garder la maîtrise de ton projet,
intéresse-toi à l'excellence technique.
Il va au-delà de tes peurs en acceptant la remise en cause.
Remarque, si tu coûtes ce podcast,
j'enfonce peut-être une porte ouverte.
En tout cas, merci d'avance pour ton soutien.
Si tu pouvais mettre une bonne évaluation à ce podcast sur iTunes,
tu me rendrais un immense service.
Et si tu connais quelqu'un qui sera intéressé par l'épisode,
partage-le lui,
même s'il n'a pas l'habitude d'écouter des podcasts,
il pourra facilement le télécharger sur SoundCloud.
Bonne journée et à demain !