Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Comment est-ce que tu mesures l'avancement de ton projet ?
De manière classique, on utilise les estimations.
Puis on les confronte à la réalité.
Alors la première erreur, c'est de considérer les choses sous la manière d'un budget.
Par exemple, tu as une tâche estimée à 5 heures,
et tu y as passé 2 heures dessus, quel est ton budget restant ?
A priori, facile 3 heures.
L'erreur sous-jacente là, c'est de croire que une estimation est quelque chose de précis.
Mais bon, si tu fais ça, du coup tu peux suivre l'ensemble du backlog et des tâches à faire et dire,
bon ok, sur un budget de 100 heures, on a consommé 30 heures, donc il en reste 70 à produire.
Bref, nous en sommes à 30% d'avancement.
En général, tu touches la limite de cette approche dans la zone des 90%.
Tu sais, ça fait un peu comme la barre Windows.
Ça va vite de 0 à 90, et de 90 à 95, ça met plus de temps que la première partie,
et ainsi de suite chaque pourcent qui avance.
Et là tu te rends compte que ça bouge plus.
Là, tu es dans un effet tunnel, et tu sais pas quand tu vas en sortir.
Une autre approche beaucoup plus intéressante que j'utilise, c'est celle du reste à faire.
Sur une tâche de 5 heures, estimé à 5 heures, tu en as consommé 2.
Quel est ton reste à faire ?
Alors là, c'est plus fin.
Tu as peut-être envie de répondre 3 heures ?
Bah peut-être, ou pas.
Peut-être qu'en fait, le reste à faire, ce qu'il reste à faire, il porte bien son nom.
Mais peut-être que d'une heure, bonne surprise.
Ou alors peut-être que tu es tombé sur un gros caillou.
Et là, en fait, c'est 7 heures qui reste.
Et là, c'est mauvaise maillonneuse.
Alors tu vas me dire, mais comment ça ?
Comment est-ce que c'est acceptable ou même possible
qu'un quelque chose estimé à 5 heures, finalement, en ayant déjà passé du temps,
coûte encore plus que ce qu'on a, l'estimation initiale ?
C'est tout simplement qu'on a maintenant une meilleure visibilité,
une meilleure vision, une meilleure compréhension de ce qu'est à faire.
Et donc on est capable d'ajuster le reste à faire au fur et à mesure qu'on avance.
Parfois, il y a des mauvaises surprises, parfois il y en a des bonnes,
mais en tout cas, au moins, tu as une vision la plus réaliste possible de l'avancer.
Et du coup, tu peux effectivement te donner une idée de l'avancer du projet
en pointant régulièrement le reste à faire.
Le reste à faire associé à un Burndown Chart est un excellent outil de prévision.
Il coûte presque rien à mettre à jour et permet vraiment de rendre l'invisible visible,
cette idée de comment on avance.
Si tu extrapoles la ligne de ton Burndown,
tu es capable même, avec une précision redoutable,
de donner une estimation de la date de release.
Alors tout ça est très bien.
Mais est-ce qu'on peut faire encore mieux ?
Le septième principe du manifeste nous dit
un logiciel opérationnel et la principale mesure d'avancement.
Tu peux avoir tous les plans budget du monde, les plus précis qu'ils soient.
Les restes à faire les plus affutés.
Tant que tu n'as pas un logiciel fonctionnel dans les mains, tu n'as rien.
Je doute que ton client ou ton patron te paye pour mettre à jour des restes à faire.
A priori, bon c'est pas le cas partout,
mais a priori, t'es payé pour livrer du code qui marche.
Et c'est pour moi la meilleure manière de savoir si le projet avance.
C'est pour ça que je refuse de repousser les dates d'une livraison.
Une fois qu'on a choisi une date, il faut s'y tenir.
Je préfère livrer deux fois moins de choses que prévues et livrer quand même.
Au moins, on est capable de se donner une idée de comment ça avance.
Parce que quand on pose un jalon, un jalon est là pour ça,
pour se nous permettre de voir comment on avance.
Si tu acceptes glisser la pente, tu sais ce que c'est, elle va glisser tout le temps.
De toute façon, tout prend plus de temps que prévu.
Ta beauté prévoire n'aura jamais tout prévu.
Alors autant s'adapter au plus juste.
Pour ça, il faut livrer en itération courte.
Il faut travailler en itération courte et livrer à chaque fois quelque chose.
Si tu tombes dans le piège du genre, cette semaine on livre la base de données.
Tu comprends, ce sont les fondations, après on aura une base solide.
Est-ce que les utilisateurs pourront y accéder ?
Ça ne va pas, non. Il n'y aura pas d'HM, ça va être une base de données.
Là, tu sais que tu vas droit dans le mur.
Par contre, si tu livres des stories, c'est-à-dire quelque chose d'exploitable par un utilisateur,
morceaux par morceaux, qui t'a peut-être à devoir reprendre certains bouts,
quand d'autres concepts auront émergé, alors tu peux sentir que tu avances
dans le regard de tes utilisateurs.
Tu peux voir où tu en es, tu peux recueillir du feedback.
Sur un plan technique, c'est pour ça que j'aime tant le TDD.
Il me donne une mesure objective de ma progression.
En particulier quand j'automatise les tests d'acceptance.
Tu sais, moi je suis plus extrême programming que Scrum.
Et j'ai un exemple encore qui date de vendredi dernier.
J'avais un algorithme à écrire.
Je me mets d'accord avec l'expert métier sur une dizaine de cas de test.
Du truc un peu trapue, du coup ça me faisait du bien d'avoir mon objectif à attendre.
Là c'était trop top, au fur et à mesure que mes tests passaient au verre,
je savais, je sentais que je progressais jusqu'à ce que tout soit vert.
Et là je push.
Grâce au TDD, j'ai une acceptance automatisée.
C'est pas ce qu'on recherche de prix ma bord, mais c'est un side effect qui est quand même assez sympa.
C'est le deuxième effet qui se coule.
Du coup, je peux livrer, quand je veux, je peux m'en livrer plusieurs fois par jour si besoin.
Et comme ça, je peux vraiment coller au plus juste et réduire au minimum les boucles de feedback avec mes utilisateurs et mon client.
Bref, livre régulièrement du code qui marche.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Et si tu veux me rendre service, j'ai un petit service à te demander.
Est-ce que tu peux aller sur iTunes et mettre une super évaluation ?
Ça serait top.
Si tu n'as pas le temps de faire ça, au moins mettre un petit 5 étoiles, ça serait génial.
Je te remercie d'avance.
Et je te souhaite une bonne journée.
A demain.