Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur,
qui parle de techniques bien sûr,
de codes durables,
mais aussi du métier en lui-même,
de recrutement, de développement personnel,
ou encore d'entrepreneuriat,
pour t'accompagner dans une vie de développeur épanouissante.
Alors,
est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui, j'aimerais te parler du reste à faire
et de comment je l'utilise.
Moi, j'utilise le reste à faire
avec un suivi temporaire,
donc ça nous donne
une espèce de graphe qui descend,
non seulement si tout va bien,
ce qu'on appelle le Burn Down Chart
dans le Scrum notamment.
Mais avant ça, j'aimerais définir ce qui est
exactement le reste à faire.
Le reste à faire,
c'est l'évaluation à un moment donné
de ce qui reste à faire.
Tu as vu, ce nom est quand même bien fichu.
Alors, j'aimerais juste apporter une notion
et souvent les gens confondent,
reste à faire et budget restant.
Si j'avais prévu 5 jours sur une tâche
et que j'en ai passé 2,
moi, on reste à faire,
c'est peut-être 3,
mais c'est peut-être 2,
c'est peut-être 4.
Mon budget restant, c'est 3.
Mais, mon reste à faire,
c'est vraiment une réestimation à chaque instant
de ce qui me reste à faire.
Donc, parfois ça baisse,
parfois ça monte,
en général, plutôt ça baisse.
Et ça nous permet à un moment donné
d'avoir une image, un instant précis,
une photo du travail qui est à faire.
Et si cette photo,
tu la suis dans le temps
que tu en fais plusieurs,
ça te donne une courbe.
Et cette courbe te permet de voir
l'évolution de ta tâche,
c'est-à-dire à quel point
tu vas vers ton objectif
et à quel point tu arrives
à atteindre ce que tu avais prévu de faire.
Alors, pour moi,
le reste à faire, c'est une épée à double tranchant.
Tu as d'abord le dark side du reste à faire
et celui que je ressens plus
quand je casse les pieds des devs
avec lesquels je bosse
pour avoir des estimations
et qu'ils mettent à jour le reste à faire,
tu as le côté flicage.
Genre, bon, alors,
t'en es à combien, quoi ?
Quand est-ce que ça sort ?
Et je trouve que ça met souvent
un peu une sale ambiance, quoi.
C'est pas le moment que je préfère
parce que ça demande de rendre des comptes.
Et en fait, personne,
je crois, aime rendre fondamentalement des...
Enfin, personne, j'en sais rien,
peut-être que ça liénaque,
ça éclate, mais moi, personnellement,
ça ne me claque pas du tout
de devoir courir après les gens,
les enquiquiner,
parce que je sens bien,
avec le nom verbal que je les gonfle.
Et pourtant, c'est tellement important.
Donc, moi, ce que j'aimerais dire,
déjà, si tu es développeur,
développe, c'est le cas de le dire,
cette compétence de réestimer le reste à faire.
Je sais que c'est stressant.
C'est stressant parce que quelque part,
on s'engage.
Alors, c'est un engagement qui est plus ou moins fort.
Il y en a qui vont le prendre
comme un engagement hyper formel.
Moi, personnellement,
je suis conscient que ce que le développeur va me dire.
Et moi, le premier, quand je le dis,
sera faux.
Ce n'est pas grave.
Je sais qu'il y a une marge de manœuvre.
Et puis, chaque développeur a un peu
son propre biais.
Donc, à force de connaître les développeurs,
on sait qu'il y en a qui sous-estiment,
il y en a qui surestiment.
On peut adapter un peu les choses.
Mais ce qui est vraiment important,
c'est de développer cette compétence-là.
Parce que c'est en essayant et en se trompant
qu'on ajuste qu'on calibre, en fait,
son estimateur de reste à faire.
Pourquoi est-ce que je disais
que c'était hyper important
de maîtriser cette compétence,
de savoir le faire ?
Parce que, pour moi,
le reste à faire est un élément
fondamental dans le suivi du projet.
Grâce à lui,
moi, je peux me projeter,
enfin moi, en tant que chef de projet,
peut-être en tant que directeur technique,
parfois en tant que celui qui mène un peu à l'équipe,
en tant que technique aussi.
Ça permet de voir l'évolution
vis-à-vis de la tâche qu'on a à faire.
Et c'est juste fondamental.
En plus de ça, personnellement,
moi, je travaille dans une société de service.
On ne va pas...
Et à un moment donné,
l'argent, c'est quand même vital.
Tous les développeurs sont contents.
Moi, le premier à être payé à la fin du mois.
Et donc, les questions d'argent
ne sont pas forcément un objectif en soi,
mais sont quand même une nécessité.
Et suivre la rentabilité d'un projet
et pas forcément après-coup,
mais pendant le projet,
c'est quand même,
il me semble quelque chose de juste,
indispensable, si on veut travailler sérieusement.
Et le reste à faire,
moi, me permet de projeter à tout instant
quelle va être la rentabilité du projet.
Évidemment, quand on travaille au forfait,
puisque quand on travaille à la régie,
la rentabilité, elle est connue à l'avance
du moment que le client paye.
Donc, pendant qu'on est...
Quand je travaille sur un projet au forfait,
je vais utiliser le reste à faire de manière régulière,
probablement tous les jours ou toutes les semaines
selon la taille du projet,
pour voir comment évolue la rentabilité probable.
Et ça, ça me permet de faire quoi concrètement ?
Ça me permet d'adapter la relation au client.
Quand je vois qu'on a de la marge,
on va plus facilement pouvoir prendre en compte
des modifications ou des changements
qui n'étaient pas forcément prévus,
pas forcément dans le périmètre initial.
Et si on commence à être récrac,
on va devenir un petit peu plus pointilleux
sur ce qui était inclus ou pas inclus.
Mais ça, j'ai envie de te dire, c'est normal,
c'est le jeu à un moment donné.
Il faut aussi défendre ton bif-tech
si tu veux pouvoir continuer à exister.
Et le premier qui sera content de ça,
ça sera le client lui-même.
Parce que, globalement,
quand tu commences à travailler avec une équipe,
tu as quand même, a priori, envie de continuer avec elle
et besoin qu'elle soit toujours là pour répondre à tes questions.
Donc le reste à faire, c'est vraiment important.
Et moi, je t'ai montré comment,
je t'ai expliqué comment je l'utilisais dans mon contexte,
à moi, c'était de service.
Mais si tu es dans le produit, c'est aussi vachement important.
Parce que c'est ce qui permet de définir des calendriers.
Alors même si c'est des calendriers à la grosse maille,
c'est aussi ce qui permet de donner des informations au vendeur,
au market pour pouvoir annoncer des choses,
pour pouvoir donner envie au client,
pour pouvoir créer de la nouveauté.
Et tout ça, je pense indispensable dans notre métier.
Le problème fondamental,
c'est pas tant de le reste à faire ou les estimations.
Pour moi, c'est la perception des estimations.
Le problème, c'est que bien souvent,
les gens et en particulier les non-techniques,
prennent une estimation pour un engagement fort.
Mais une estimation n'est que ce qu'est, c'est-à-dire une estimation.
Et moi, fondamentalement,
je sais qu'elle sera fausse,
ça je t'ai déjà dit,
mais ce que je t'ai pas dit,
c'est aussi que l'unité m'importe assez peu d'ailleurs dans le reste à faire.
C'est ça que j'aime dans cet outil,
parce que je le trouve extrêmement puissant.
C'est que tu estimes en jour,
que tu estimes en point de complexité,
voire même que tu fasses partie du mouvement de non-estimés,
et que tu estimes que tu n'as pas à estimer.
Oh, il était pas mal ça là,
tu estimes que tu n'as pas à estimer.
Tu peux toujours compter,
tu comptes en tâches,
puisque dans le non-estimés,
l'idée c'est d'avoir des tâches très granulaires,
d'une taille à peu près cohérente.
Il suffit de compter le nombre de tâches à faire,
et là, tu as une estimation,
tu as un reste à faire qui est encore plus facile à créer, à suivre,
puisqu'il te suffit de compter le nombre de tâches.
Voilà, j'espère que t'as avoir convaincu
que le reste à faire était quelque chose d'important
et que ça va te donner envie de creuser ça.
Je me pose la question de savoir
si ça peut intéresser des gens
que je fasse un screencast
ou même une formation carrément sur ça,
sur comment j'utilise le reste à faire
dans mon activité au quotidien de Société de service.
Bah écoute, si ça t'intéresse,
envoie-moi un email benoît
arobazartisandeveloper.fr
Comme ça, je verrai un petit peu ce que je fais de cette idée.
Je te dis à demain.