Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas-Brandin-Bernard et aujourd'hui on va parler de pourquoi est-ce que c'est si dur
d'estimer le temps de développement d'un projet et on va aussi aborder un concept qui est assez
central qui est le concept de complexité accidentelle. Alors il y a beaucoup de développeurs et
développeuses juniors que je rencontre et qui je discute, qui m'avoue avoir une difficulté majeure
dans leur travail de tous les jours, c'est estimer le temps de développement d'une fonctionnalité
ou d'un projet au complet. Et en général ma réponse elle est très simple, c'est normal. La
première cause de ça c'est que les développeurs et développeuses qui souffrent d'un manque d'expérience
n'ont pas encore les bagages techniques nécessaires pour réaliser une estimation correcte du temps.
C'est pas pour rien que la racine du verbe prévoir c'est voir et pour prévoir quelque chose il
faut déjà l'avoir vu au moins une fois en tout cas c'est beaucoup plus facile de le faire.
Mais c'est pas tout parce que même si on s'améliore avec le temps et avec l'expérience,
ça ne veut pas dire qu'en devenant un développeur confirmé ou senior, développeuses évidemment,
nos estimations seront juste 100% du temps, loin de là, il y a même beaucoup de fois où ils ne sont
pas du tout juste. La différence entre le temps estimé et le temps effectif, il peut y avoir
énormément de causes à ça mais il y en a trois qui sont vraiment majeurs et dont on va parler
tout de suite. La première c'est ce qu'on appelle la complexité cachée. Ça arrive que certaines
fonctionnalités basiques à première vue peuvent être par exemple proposées en option à un client
par l'équipe commerciale sans consulter l'équipe technique, ce qu'il faut évidemment pas faire ou
éviter de faire et ces fonctionnalités qui paraissent basiques renferment en fait une complexité bien
plus importante et qui va dépendre aussi de la manière dont elle est conçue et du projet dans
lequel elle est conçue. On va prendre l'exemple d'une simple barre de recherche. Par exemple,
une fonctionnalité comme celle-là sur une liste fixe d'éléments ou une liste très réduite
simplement trahira effectivement en quelques lignes de code avec un simple affichage conditionnel,
en recherchant sur le nom, la description, peu importe. Mais pour gérer une recherche textuelle dans
une liste de ressources complexes et dont le nombre augmente au fur et à mesure de la vie de l'application,
il faudra sans doute mettre en place un moteur de recherche externe comme elastic search par exemple,
lequel devrait être synchronisé avec la base de données et rendra tout de suite l'architecture
du projet bien plus complexe. On passe d'ajouter quelques lignes de code avec un affichage
conditionnel à carrément une modification de l'architecture, des services en plus,
un maintien de ces services, de mises à jour, etc. Ça, c'est ce qu'on appelle la complexité cachée.
Maintenant, on va parler de la complexité accidentelle comme je l'ai évoqué au tout début de l'épisode.
Alors, en anglais, on parle d'accidentile complexity, c'est plutôt transparent. Et ça,
c'est une notion qui correspond à la complexité qui va venir s'additionner au fur et à mesure
du projet et de son développement. Et c'est vraiment à prendre en compte quand on crée une nouvelle
fonctionnalité. Par exemple, une fonctionnalité X pourra être très très simple à développer dans
un projet vierge, mais dans un projet basé sur une architecture déjà complexe avec des dizaines
de modules métiers et des dizaines de milliers de lignes de code, la même fonctionnalité mettra
un temps beaucoup plus important pour être intégré. Cette complexité est vraiment
compliquée à estimer de par sa nature, mais aussi et surtout parce qu'il faut déjà connaître très
bien le projet et l'état de l'existent pour pouvoir l'évaluer. En plus, c'est carrément une
complexité qui est strictement dépendante à l'expérience des développeurs et développeuses
qui travaillent sur le projet et qui ont déjà travaillé sur le projet. Et c'est aussi lié
au temps, aux deadlines qu'on va avoir sur le projet. Parfois, on demande une solution qui
demanderait une semaine à développer un développeur et une développeuse expérimentée, mais en fait,
il va falloir l'implémenter en un jour parce qu'il y a un vrai enjeu commercial.
Évidemment, la solution sera moins propre, il sera moins maintenable sur le long terme. Et là,
on va ajouter une complexité accidentelle qui est bien plus importante que si on avait eu le temps
nécessaire pour la développe. Et enfin, le dernier concept qu'on va avoir sur justement qui va
influer sur la précision de l'estimation d'un projet, c'est ce qu'on peut parler de la différence
de vision. On peut parler, alors évidemment, ça touche directement l'expérience, mais on va
pouvoir se le représenter un petit peu avec des oeillères comme on met un cheval. Et ça joue
simplement quand vous demandez à plusieurs développeurs et développeuses d'estimer le temps
de développement de la même fonctionnalité. Et bien, vous pouvez vous retrouver avec des
différences qui vont du simple au triple, voire même plus parfois. Les raisons que j'ai citées
juste avant, évidemment, ça peut en être la cause, mais il y a aussi un biais dans cette démarche
parce qu'on pense souvent que l'estimation la plus courte sera donnée par un développeur
sénor qui sera, développeur sénor, qui sera tiré profit de son expérience. Mais en fait,
c'est souvent l'inverse qui se passe parce qu'au contraire, il arrive bien plus souvent
qu'un développeur expérimenté et des estimations plus longues parce qu'il n'aura plus seulement
la vision de la fonctionnalité quand toutes les conditions sont réunies pour que tout se passe
bien. C'est ce qu'on parle de happy path. Mais il sera aussi en mesure de prévoir tous les cas
spéciaux où il faudra être vigilant lors de l'implémentation, les fameux edge cases. Alors,
ça rejoint un petit peu le concept de complexité cachée, mais là, c'est même pas forcément qu'elles
sont cachées au développeur, c'est le développeur lui-même ne s'en rend pas compte en amont du
projet. Ça, c'est pour moi les trois raisons principales qui font que oui, estimer un projet,
c'est très compliqué. Parfois, c'est extrêmement difficile, voire impossible d'estimer précisément
le temps de réalisation d'un projet. Et moi, ce que je trouve et que j'essaye de mettre en place
dans mon quotidien depuis quelques années, c'est toujours de donner plusieurs fourchettes et surtout
de mettre un point d'honneur à annoncer tous les sujets qui touchent au projet, mais sur lesquels
on n'est pas du tout expérimenté. On a très souvent des développeurs et des développeuses qui
n'ont par exemple jamais implémenté de système de paiement. Et bien, s'ils doivent estimer la
durée d'un projet qui inclut un système de paiement, eh bien là, il faut vraiment par exemple
être très très violent et mettre des signalisations et des warnings partout en disant à l'équipe
« projet, attention, je n'ai jamais touché à ça ». On parle de paiement, on parle de gestion
financière, il y a énormément d'implications. Donc, l'estimation que je vais donner de ce truc-là
n'aura en réalité quasiment aucune valeur en termes de précision parce que ça pourra changer
énormément. Il faut toujours être très très transparent et ne pas essayer de faire la course,
la compétition notamment pendant les, par exemple, on a des entreprises qui utilisent le
poker planning ou le planning poker où chacun donne son estimation comme avec des chetons,
c'est un jour, deux jours, peu importe. Et il y a une espèce de pas de mise en compétition,
mais en tout cas où tout le monde doit donner une estimation, il faut faire très très très attention
à ça, notamment à cause des facteurs que je viens de vous lister. J'espère que vous en aurez
appris un petit peu plus sur l'estimation. Je ne vous ai pas donné de clés précises pour
améliorer vos estimations, mais je vous ai donné des clés au moins pour faire attention et alerter
en général et ça c'est la première pierre justement dans ces cas. Moi je vous donne rendez-vous la
semaine prochaine pour un prochain épisode du podcast ou directement sur code ThierryGarage.fr pour
retrouver tous nos articles de blog, tous nos épisodes de podcast, toutes nos formations. Alors là,
on est vraiment dans une phase où on ajoute de plus en plus de fonctionnalités communautaires. Donc,
maintenant vous pouvez en plus de ce que vous pouvez faire avant, c'est-à-dire créer votre
portfolio pour pouvoir le partager sur votre CV, créer des projets, avoir des stats sur vos
projets. Vous pouvez maintenant discuter en direct avec d'autres utilisateurs dans des salons
de discussion, un petit peu comme sur Discord, mais directement sur la plateforme. Il y a toutes les
fonctionnalités communautaires qui sont dans une page spéciale communauté. Il y a un leaderboard pour
les utilisateurs et utilisatrices qui ont le plus de points de réputation, les projets qui sont
le plus soutenus par la communauté. On ajoute des petites fonctionnalités comme ça au fur et à
mesure. Donc si vous avez des demandes aussi, n'hésitez pas à nous les faire sur les réseaux
sociaux ou peu importe parce qu'on tient vraiment beaucoup à cette partie parce que chez Code
Garage, on croit fermement que avancer tout seul c'est bien, mais en réalité avancer à plusieurs
et apprendre à plusieurs, on va plus vite et souvent beaucoup plus lent. A la semaine prochaine
pour un prochain épisode du podcast. Salut !