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à eu le client en face de recettes qui te dit un truc du genre ?
Ah ben non mais là en fait j'ai changé d'avis.
Et là c'est quoi la réaction en général des développeurs ?
Ah non pitié ! Qu'est-ce qui se passe ?
Ah non monsieur le client on ne pouvait pas changer d'avis là, c'est l'arsette, on est en train de livrer.
Enfin monsieur le client c'était pas prévu, vous vous rendez pas compte, il faut tout refaire.
Le vrai problème fondamentalement c'est que dans les approches classiques on essaye trop d'anticiper.
Pourquoi est-ce qu'on essaye d'anticiper ?
Parce qu'on nous a appris que le coût du changement varie de manière exponentielle avec le temps.
Et qu'il valait mieux être sûr de ce qu'on voulait dans les phases amont parce que le changement, son prix en tout cas explosé au fil du temps.
Pourtant si le client demande un changement, c'est qu'il y a une bonne raison, normalement.
C'est pas juste qu'il s'est élevé ce matin on se dit on tient je vais tout changer.
Bon peut-être j'en connais mais en général s'il le fait vu qu'il paye d'une manière ou d'une autre
il le paye soit directement par son argent soit parce que si c'est son travail de mener à bien le projet il a un patron à qui doit rendre des comptes.
Donc s'il le fait c'est qu'il y a une nécessité c'est qu'il y a un besoin.
Et nous en tant que développeur quelle est notre responsabilité ?
Justement le manifest nous dit dans le deuxième principe
accueillir positivement les changements de besoin même tard dans le projet.
Les processus s'agile exploitent le changement pour donner un avantage compétitif au client.
Et là il s'agit bien d'un avantage compétitif
c'est à dire permettre à notre client d'aller plus vite plus loin plus fort que les concurrents pour qu'il puisse continuer à nous nourrir.
C'est très simple si le client est content et qui gagne sa croûte, bah nous aussi.
Encore une fois que ce soit un client interne, externe c'est pareil, c'est pas la question.
Par contre pour que ce soit possible comment conféty ?
Non parce que c'est bien gentil les changements mais il faut pouvoir les encaisser surtout quand c'est tard dans le projet.
Moi j'ai connu des projets où à la première change request blam toute l'archie explosée.
Pour pouvoir faire ça, pour pouvoir être serein, pour pouvoir accueillir le changement positivement, il faut être prêt à le faire, il faut être disponible dans sa tête.
Il faut avoir une architecture souple mais vraiment souple.
Pour moi ça passe par les pratiques d'ingénierie de l'extrême programming.
J'avoue que je suis pas très objectif sur ça et c'est un petit peu ce que je reproche au Scrum.
C'est qu'il ne se soucie pas du tout des enjeux techniques.
Il part du principe que chacun sait bien faire son travail.
Moi je veux bien mais si vous vous contentez d'accélérer les choses sans prendre en compte la dimension d'ingénierie, vous allez juste dans le mur.
Un moment ou un autre vous allez vous planter.
Je suis convaincu que des choses, des pratiques comme le TDD, l'intégration continue, le déploiement continue, les boucles de feedback rapide.
Permette justement d'accueillir ce changement même tard dans le projet.
Parce qu'on a gardé une architecture souple.
Parce qu'on est disposé à changer puisque dès qu'on veut tester quelque chose, on sait instantanément si on fait fausse route, si on va dans la bonne direction, j'entends sur le plan technique.
Est-ce que le changement va nécessiter réellement tant que ça de travail ? Est-ce que c'est un carnage ?
C'est vraiment pour réellement savoir que si je fais un pas, ok, je fais un pas et ça ira.
Faire des gros changements.
C'est un petit peu si on faisait l'analogie avec le bâtiment comme déplacer un mur porteur alors qu'il y a des gens qui habitent dedans.
Bon sur un bâtiment on se rend bien compte que ça va pas le faire.
C'est quoi la différence avec le logiciel ? Mais c'est que le logiciel est immatériel.
Et nous on peut le faire ça. On peut le faire de déplacer des modules centraux hyper critiques tout en ayant des utilisateurs qui sont en utilisant le système.
Mais ça demande d'avoir des bonnes pratiques d'ingénierie.
Ça demande du savoir-faire. Ça demande un goût pour le travail bien fait.
Et ça effectivement c'est pas forcément répandu.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si ce n'est pas déjà fait, je t'invite à venir t'abonner sur artisan-dev.fr pour continuer à partager la passion du code.
Et si ce podcast a plu ou si le site a plu, je t'invite aussi. Je suis sûr que un tes copains que tu connais sera intéressé. Je t'invite à le partager avec lui.
Je te souhaite une bonne journée.