Développement et estimation de temps
Vous devez déjà vous dire "encore un article disant que les estimations de temps ça sert à rien" ? C’est en effet la grande mode depuis quelques années. Mais comme toujours, le diable se cache dans les détails et donnerai mon avis personnel sur cette question.
Les estimations, vraiment utile ?
Quand les gens parlent d’estimations, ils décrivent généralement deux situations.
Les estimations en début de projet
Le projet n’est pas encore lancé qu’il faut déjà faire des estimations, par exemple dans des réponses à appel d’offre.
Comme vous vous en doutez, ces estimations sont souvent fausses. De plus, ce n’est pas forcément l’aspect technique qui est pris en compte lors de ces estimations.
C’est encore plus vrai sur des gros projets où trop de variables rentrent en compte.
De plus, dans le cas de prestations externes, ne pas forcément connaître le domaine métier du client ou l’équipe du futur projet (qui n’est parfois même pas encore recrutée à ce moment là) n’aide pas.
Si demain vous me dites "Bon, il faut que tu développes un site de e-commerce faisant ça, ça et ça avec une équipe que tu ne connais pas", en effet je ne saurai pas faire une estimation de temps.
Une estimation approximative est possible
Néanmoins, une estimation approximative est possible selon moi si le projet respecte plusieurs critères:
-
L’équipe développant le projet est connue, les gens ont déjà travaillés ensemble, des méthodes de travail et automatismes sont déjà en place… Bref, on ne part pas en terrain inconnu avec 20 prestas arrivant d’on ne sait trop où.
-
Le domaine du projet est connu par l’équipe.
-
Le scope du projet est connu. On sait d’où on part, où l’on veut arriver, et dans les grandes lignes ce qui doit être fait pour y arriver.
-
On a pris un peu de temps pour valider certains besoins techniques, voir on a quelques maquettes du projet… Bref, on ne part pas d’une feuille blanche.
Dans ce cas, et si le projet n’est pas un truc gigantesque sur 10 ans, je pense qu’une estimation approximative peit être donnée. Bien sûr, il y aura des surprises. Le projet estimé à 4 mois mettra peut être 3 mois, ou bien 6 mois, mais cela donne au moins un ordre de grandeur et permet de voir si le projet est réalisable dans un temps acceptable.
Avoir un ordre de grandeur est important. Si vous prévoyez de sortir dans les 6 mois un produit pour vos clients mais qu’en fait vous mettez 3 ans, cela peut être problématique pour l’entreprise.
Les estimations de tâches
J’ai travaillé il y a quelques années sur un gros projet où à chaque sprint des products owners et un lead dev estimaient toutes les tâches présentes dans le backlog (JIRA pour ne rien arranger).
Evidemment, cela ne fonctionnait pas du tout, notamment parce que les personnes faisant les estimations n’étaient pas les personnes développant les fonctionnalités. Il fallait d’ailleurs aussi mettre sur les tickets JIRA le temps réellement passé dessus. Bien sûr le grand jeu était en fin de semaine de mettre des temps random sur les tickets pour que ça fasse 8 heures/jour. Mais cela est une autre histoire.
Estimer les tâches de cette façon est complètement inutile et même néfaste. Cela prend du temps, met la pression aux équipes (car les devs se disent "OMG je vais dépasser l’estimation") et ne sert strictement à rien.
On sait que l’on va avoir des imprévus, que certaines tâches seront en fait plus difficiles que prévu… Bref, estimer n’apporte rien dans ce cas.
Mais faut-il quand même se passer totalement d’estimation sur les tâches ? Je ne pense pas. A entendre certains devs, estimer serait complètement impossible quelle que soit la tâche.
Pour être honnête, je me poserai beaucoup de questions si un dev travaillant depuis plusieurs mois sur un projet, connaissant la stack technique… affirmait ce genre de choses.
Quand estimer ?
L’estimation doit être avant tout un exercice personnel.
Quand je me lance sur une tâche, j’estime toujours mentalement le temps que cela va me prendre. Si vous ne le faites pas, essayez, c’est un très bon exercice.
En connaissant bien le projet, ses technos, et le domaine métier, il est selon moi possible de taper assez juste (bien sûr, avec une marge d’erreur) pour un certain nombre de tâches.
Si vous n’arrivez pas à donner une estimation mentale "à la louche" pour une tâche, demandez vous pourquoi. Par exemple, peut être que:
-
La tâche n’est pas assez détaillée ?
-
Vous ne connaissez pas bien le projet ou n’êtes pas à l’aise avec la stack technique utilisée ?
-
La tâche est trop grosse, peut être mériterait t-elle d’être découpée en plusieurs sous tâches ?
Bien sûr, parfois on tombera sur une tâche où on se prendra un mur car un truc important n’avait pas été identifié (surtout vrai en début de projet je trouve), ou bien certains types de tâches (investiguer des bugs complexes par exemple) ne sont pas vraiment estimables, mais globalement estimer un certain nombre de ses tâches est je pense possible.
Cela me permet également de savoir si je suis en train de bloquer ou non, et de savoir si c’est le moment de re-réfléchir au problème voir de demander de l’aide.
Enfin, estimer les tâches mentalement permet de savoir à peu près ce qui devrait être fait (et donc arriver en prod) dans un futur proche. C’est toujours cool de pouvoir se dire que telle fonctionnalité devrait arriver en prod en fin de semaine (et de finir la semaine en ayant effectivement terminé la tâche).
Cela me permet également de donner une estimation si la tâche est attendue par une autre personne ou équipe (mais tout le monde doit être au courant que c’est une estimation et non un engagement).
En conclusion, estimer est un très bon exercice à réaliser de son côté.
Add a comment
If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).