Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Les sponsors du projet, que ce soit le client, les utilisateurs,
se font une idée à priori de ce que sera le logiciel.
Sauf que dans la vraie vie, 50% au moins des idées initiales sont de fausses bonnes idées.
Et franchement, si tu as que 50% de fausses bonnes idées sur ton backlog initial,
c'est pas mal, c'est pas mal.
Parce qu'en fait, ton client, il croit qu'il sait ce qu'il veut,
mais dès qu'il va voir le logiciel vivre sous ses yeux,
ça va plus être pareil.
Tout d'un coup, dès que tu l'as en main, certaines portes se ferment et d'autres s'ouvrent.
Et je ne te parle pas de quand tu mets l'appli entre les mains d'utilisateurs, c'est encore pire.
C'est que les bougres, ils en ont des idées.
Si l'outil est vraiment destiné à eux, je te garantis qu'ils vont en donner plein de bonnes idées.
Ou de mauvaises aussi.
Alors du coup, toute la question c'est, comment est-ce qu'on fait pour éviter d'avoir trop de gaspillage ?
On peut limiter les choses avec des étapes intermédiaires comme les wireframe,
où on va venir dessiner les écrans, on va pouvoir se projeter dans un usage.
C'est déjà pas mal, mais, parce qu'il y a un mai, il n'y a pas forcément de vrais données.
Et là, un détail d'implémentation, un truc qui a l'air anodin, qui passe sous le radar du développeur.
Et en fait, quand il met les mains dedans et qu'il commence à réfléchir,
mais comment je vais coder ça, ça peut devenir un vrai cauchemar.
Et si ça sent le vécu, c'est parce que je baigne en plein dedans.
Alors, comment on limite le gaspillage ?
Eh bien, l'idée elle est simple.
Il faut recueillir le feedback dès que possible.
Et là, le principe numéro 3 du manifeste nous aide bien.
Il est livré fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
Là, il y a deux choses qui sont importants.
Des cycles les plus courts possibles.
Alors oui, en 2001, des cycles de quelques mois, ça paraissait déjà révolutionnaire.
De quelques semaines, c'était juste la folie.
Moi, tu sais, je viens de l'extrême programming.
Donc, si j'attends deux mois ou même deux semaines, c'est long pour moi.
Et surtout, si le projet est un peu chaud, moi, ça me paraît trop lointain.
Je viens de l'experter.
Donc, moi, je le déviens tous les jours et même plusieurs fois par jour.
Mais on va reparler de comment on fait ça.
Et il y a bien une idée qui est importante aussi.
De livrer fréquemment des logiciels opérationnels.
On se comprend bien.
Il y a cette idée d'être quasiment à un niveau de production.
En fait, pas quasiment à un niveau de production.
C'est-à-dire qu'au fil de l'eau de ce que tu livres,
pouvoir le déployer pour tes utilisateurs.
Donc, comme je te l'ai dit, il m'arrive de livrer plusieurs fois par jour.
Comment je fais ça ?
Il n'y a pas de magie.
Il faut automatiser.
Il faut tout automatiser.
Première chose à automatiser, bien entendu, c'est le build.
Enfin, d'abord, ou pas parce que peut-être qu'en fait, c'est d'abord la recette que tu vas automatiser.
Dans l'extrême programming, la recette est automatique.
Je ne te parle même pas des TDD ou du test unitaire.
Je te parle vraiment de cette logique d'avoir une recette automatisée.
L'idée, c'est qu'à chaque fois que je veux livrer quelque chose, je ne me prends pas la tête.
Pour moi, une livraison, c'est un guide push et c'est livré.
Ça ne coûte pas grand-chose, ça coûte un petit peu au démarrage à installer.
Et après, on est bon.
On installe une version pré-prod pour les beta-tester et ça roule.
Le résultat, c'est quoi ?
C'est que tout le monde peut voir et quasiment en temps réel les avancées du projet.
Et ça, c'est très, très fort, c'est très puissant.
Plusieurs fois par jour, même parfois, ou en moins une fois par jour,
tout le monde peut se synchroniser et voir ce qui est en train de se passer.
Du coup, tu peux collecter du feedback au fur et à mesure et adapter ce que tu vas livrer,
ce que tu es en train de faire au plus près du besoin en évitant d'en développer trop
ou de développer de fausses bonnes idées.
Si ça t'a plu, cet épisode est le troisième sur les principes,
mais il y avait aussi les épisodes sur les piliers.
Et j'ai créé une playlist sur SoundCloud pour dérouler tout ça.
Si tu veux venir l'écouter, c'est chouette.
Ici, en plus, tu me rends du feedback sur ce que ça t'apporte,
en quoi ça résonne chez toi, c'est juste génial.
Je te remercie et je te souhaite une bonne journée.