Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Est-ce que tu as déjà entendu parler de l'effet tunnel ?
L'effet tunnel, elle vient de cette image du tunnel,
quand même tu as vu comme c'est original.
Est-ce que tu as déjà pris un long tunnel,
genre le tunnel qui va de France vers l'Italie sous le Mont Blanc ?
C'est long.
Et tu vois, dans un tunnel,
tu as rarement d'indication de là où tu en es du tunnel.
Et si tu utilises un GPS, tu verras que ton GPS, il est paumé dans un tunnel.
T'as pas les outils qui te permettent de savoir où tu en es dans le tunnel,
alors qu'on dort du tunnel, oui.
Et d'ailleurs, à un moment donné, tu vois la fameuse lumière au bout du tunnel.
Et là, tu te dis, ok, on est bientôt sorti du tunnel.
Le problème des approches type cyclon V, cascade,
c'est que tu as un fichu effet tunnel.
Tu as le premier effet tunnel qui est lié à l'usage de l'utilisateur.
Est-ce que ce que je vais livrer correspond à ce que j'avais demandé ?
Puis tu as un deuxième effet tunnel au moment où on intègre tout vers la fin,
tous les composants sont assemblés d'un coup.
Et là, on se rend compte de ce qui marche ou de ce qui ne marche pas.
Le problème de ces approches, c'est qu'elles ne permettent pas d'avoir du feedback.
Elles ne permettent pas de savoir où est-ce qu'on en est.
Or, dans un projet informatique, tu as souvent au moins 50% des hypothèses initiales
qui s'avèrent fausses en cours de route.
Bon, ça, ce chiffre, il ne vient pas d'une étude scientifique très poussée,
il vient juste de 20 ans de carrière d'expérience.
Je remarque entre l'idée initiale et ce qui est réellement à un moment donné
mis en œuvre et utilisé, c'est à peu près la moitié.
Donc ça veut dire qu'il y a 50% de choses qui étaient bonnes et 50% qui étaient ajoutées.
Ça serait bien qu'on n'ait pas à développer ces 50% qui ne servent à rien.
Autre point aussi.
Le besoin évolue.
Situé dans un projet qui va durer longtemps sans pouvoir collecter du feedback
un mois, deux mois, trois mois, six mois, douze mois, tu prends le risque que ton
objectif change en cours de route sans même que tu t'en rendes compte.
Et là, c'est beaucoup plus que 50% que tu vas jeter.
Et puis, tant qu'il n'y a pas de feedback, l'équipe n'a pas appris à travailler ensemble.
Donc ça veut dire qu'on ne s'est pas mis d'accord, on ne s'est pas assuré qu'on avait
bien compris l'intention du client.
Or, dans le meilleur des cas, le client croit qu'il sait ce qu'il veut.
Mais dans la vraie vie, il se trompe souvent beaucoup.
Évidemment, quand je parle de clients, je parle de celui qui est client de l'équipe,
du donneur d'ordre, de celui qui mène le projet.
Ça peut être un client externe comme un client interne, c'est pas l'enjeu.
Et quand je dis qu'il croit qu'il sait ce qu'il veut,
c'est pas qu'il a une mauvaise vision de son marché.
Non, c'est qu'il fait des hypothèses.
Or, en logiciel, il n'y a qu'une fois que tu es là dans les mains,
que tu peux te faire une opinion réelle.
C'est un truc qui m'a toujours fasciné, ça.
Même pour nous, quand on fait nos propres projets,
je me rends compte que c'est qu'une fois que j'ai l'application sous les yeux,
que je peux vraiment me faire une opinion.
Et ce n'est qu'une fois que je l'ai sous les yeux,
que je peux imaginer l'étape suivante.
Tu vois, développer un logiciel sans prendre de feedback,
c'est un petit peu cuisiné et salé en aveugle sans jamais goûter.
Tu ne goûtes pas ta cuisine.
Tu mets de l'assaisonnement, mais tu ne goûtes pas ce que tu fais.
Tu ne goûtes pas ton plat.
Tu mets du sel, mais tu ne goûtes pas le plat.
Ça ne peut pas marcher.
Même quand tu regardes dans Top Chef, même les gars, ils se font engueuler
s'ils n'ont pas goûter parce que c'est soit trop salé, soit pas assez salé,
soit trop assaisonné, soit pas assaisonné.
Donc recueillir du feedback, c'est fondamental.
Et c'est un peu le principe, le premier principe du Manifest Agile.
Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée.
Là, qu'est-ce qui est important ?
Il y a cette idée de satisfaire, c'est-à-dire d'apporter ce dont le client a besoin.
Et notez bien, ce dont il a besoin n'est pas forcément ce qu'il veut.
Mais ça, il va s'en rendre compte qu'une fois qu'il aura le logiciel dans les mains.
On livrant rapidement.
Donc on n'est pas là dans une logique d'attendre X semaine, X mois.
Non, rapidement.
Et régulièrement, des fonctionnalités à grande valeur ajoutée.
C'est-à-dire qu'on va commencer par ce qui a le plus de valeur ajoutée
pour le client.
Pourquoi ?
Parce que ça permettra en cours de route d'ajuster le tir.
Si finalement, comme en général, c'est le cas, il n'y a pas d'où qu'il rentre.
Est-ce qu'il vaut mieux avoir développé plein de petites choses
qui ne sont pas très importantes ou deux grosses choses
qui sont vraiment très importantes et qui ont apporté de la valeur ?
Alors pour faire ça, ce n'est pas si compliqué que ça.
Ça veut dire que tu montres au client régulièrement
ce que tu fais.
L'inconvénient de ça,
c'est que le client n'est pas forcément habitué à cette approche
et dès qu'il va voir quelque chose,
il risque d'avoir l'impression que tu lui présentes un produit fini.
Alors Thorebaud lui dire, et c'est important de lui dire,
il est probable qu'il est du mal à comprendre au début.
Mais c'est pas grave, tu lui expliques.
Tu le prends par la main.
Tu lui expliques que c'est une livraison intermédiaire,
que le but n'est pas de se faire...
n'est pas là de livrer ça,
mais de se faire une opinion d'échanger, d'avoir du feedback.
Et tu verras que ça apportera beaucoup,
ça apportera beaucoup parce que ça permettra d'ajuster le tir.
Plus cet échange sera fréquent
et mieux le projet avancera dans la bonne direction.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si tu l'as apprécié,
tu peux me rendre service,
il te suffit d'aller sur iTunes
et de mettre une bonne note à ce podcast.
Si en plus, tu te sens de rajouter un commentaire sympa,
franchement, ça sera super.
Pourquoi je te demande ça ?
Parce que c'est vachement important pour faire monter le podcast dans les rankings.
Et j'aimerais vraiment qu'un maximum de monde
tombe sur ce podcast pour en récupérer les idées.
Je te remercie et je te souhaite une bonne journée.
Sous-titres réalisés par la communauté d'Amara.org