Comment estimer le temps de développement efficacement ?

Table des matières

Comment estimer le temps développement efficacement ?

Deviner quoi ? On dit que les projets informatiques en échec sont dus à une mauvaise gestion et une mauvaise estimation de temps 🔗.

Et s’il y a bien une chose commune avec tous les développeurs que j’ai pu discuter, c’est la difficulté d’estimer au plus juste la réalisation des fonctionnalités à créer. Tout le monde y est confronté un jour au l’autre. Et le moins que l’on puisse dire, c’est que la tâche reste difficile même avec de l’expérience.

Mais pourquoi il est difficile de faire une estimation du temps de développement nécessaire (et un indirectement du coût) pour une fonctionnalité ? On va dire que les causes sont assez variées et multiples : le manque d’expérience, le manque de connaissance, le manque de recul sur un sujet, le manque d’informations précises sur le sujet, etc. Bref, énormément de variables à vous rendre fou dans votre estimation.

L’estimation à vue de nez

Il faut comprendre une chose importante : humainement, nous ne savons pas réellement quantifier au plus juste. Que ce soit une quantité, un volume ou le temps nécessaire pour réaliser une tâche même si on l’a déjà fait.

Et on peut s’en rendre très simplement avec des petites choses du quotidien. Prenons un exemple simple :

bouteille d’eau pleine et fermée

Si je mets devant vous une bouteille d’eau d’un litre et demi non ouverte et que je vous demande d’estimer le contenu, vous allez me répondre un litre et demi, car c’est écrit dessus et parce que la bouteille n’est ouverte.

bouteille d’eau ouverte avec un verre d’eau

Mais si j’ouvre la bouteille et que je me sers un verre (non gradué bien évidemment) et que je vous pose la même question : qu’allez-vous me répondre ?

Difficile pas vrai ? Vous allez réfléchir sur la contenance possible de verre et la comparer à ce qui manque au niveau de la bouteille. Et c’est là que vous allez commencer à me donner des estimations évasives. Vous allez faire des propositions du genre environ 1 litre ou un peu plus d’un litre ou encore entre 1 litre et 1,25 litre.

En clair, une estimation précise et juste ne sera plus possible car l’unité de mesure n’existe pas sur le verre. Vous avez saisi ? C’est tout notre problème.

Reportons cela à ce qui nous intéresse : la programmation. Que nous ayons déjà effectué une tâche similaire ou non, nous n’avons aucune garantie de bien pouvoir la quantifier.

Pourtant, nous avons à notre disposition une unité de mesure par rapport à notre verre à savoir le temps.

Unité de temps + points de référence = mauvaise idée ?

Pour réaliser une fonctionnalité, vous allez passer du temps. Et il est donc tout à fait naturel d’estimer en unité de temps. Comme il est naturel de prendre des points de référence pour faciliter son estimation de temps.

Ses points de référence sont nombreux et variés dont voici quelques-unes :

• vous avez déjà réalisé le même genre de fonctionnalité dans le passé
• vous avez une vision d’ensemble sur le projet et vous avez une idée de comment la réaliser
• le cahier des charges de la fonctionnalité est ultra-détaillé
• vous faites confiance à votre instinct
• vous avez une solide expérience et vous avez foi dans vos capacités

L’autre chose qui fait que nous estimons toujours en temps, c’est parce que notre société et plus précisément le monde professionnel dans notre cas veut cela.

Pourquoi estimer en temps ne marche pas ?

Une société qui vous missionne sur un projet va forcément vous rémunérer et elle a besoin de connaître le coût de la tâche qu’elle veut vous demander faire. Comme vous allez passer du temps pour produire son travail, vous allez lui faire un devis dans ce sens. Vous allez vendre votre main d’oeuvre et chiffrer en quantifiant en heure multipliée à votre taux horaire pour faire votre devis. La quantité montrera à votre client le temps nécessaire pour développer sa demande.

C’est ce que la plupart feront pour arriver à ce résultat, mais il y a 2 problèmes majeurs à faire cela :

• Le temps estimé ne reflète pas TOUT le travail qui sera réellement effectué. Réaliser un projet ou une fonctionnalité, ce n’est pas juste codé. C’est réfléchir, organiser, anticiper, se tromper, recommencer, bloquer sur un problème, se former ou former des personnes. Tant de points extrêmement importants à prendre en compte et qui sont souvent sous-évalué voir pas du tout pris en compte dans une estimation.
• L’estimation n’est pas objective tout simplement parce que vous avez estimé le temps selon vous sans prendre en compte qui fera réellement la tâche si vous travaillez en équipe. Une tâche que vous êtes capable de faire en 1 journée prendra peut-être 2 fois plus de temps pour l’un de vos collègues et peut être 2 fois moins de temps pour un autre.

Vous êtes sûr à 90% que vous partez perdant dès le départ sans même avoir commencé le projet et que vous allez annoncer un surcoût à votre client. Pas la bonne stratégie !

D’ailleurs, ça me rappelle des vieux souvenirs dans mon ancienne boîte où le patron disait : «  Ton estimation je vais la prendre et je vais au minimum faire x2 ». Même avec ça, ça ne fonctionnait pas.

Points d’effort + points de référence = bonne idée ?

Alors comment est-ce que l’on pourrait faire pour estimer au plus juste en prenant en compte un maximum de paramètres et sans se prendre la tête : avec la bonne unité de mesure. Et celle que je vous conseille d’utiliser ce sont les points d’efforts.

Qu’est-ce qu’un point d’effort ? Si vous connaissez « SCRUM 🔗 », vous en avez sans doute déjà entendu parler puisque cette méthode de gestio n de projet utilise cette unité. D’ailleurs, j’aurais beaucoup à dire sur cette méthode mais ce n’est pas le sujet (j’y consacrerais très certainement un article, mais en attendant vous pouvez explorer la toile pour en apprendre un peu plus sur « SCRUM »).

Pour faire simple, un point d’effort représente l’effort à fournir pour développer une demande en prenant en compte sa complexité, les contretemps que l’on imagine pouvoir rencontrer, les inconnues de la demande mais aussi les dépendances à des éléments extérieurs (comme un prestataire externe par exemple).

Ne faites pas de comparatif du genre 1 point d’effort = 1 heure ou 1 jour de développement. Vous devez absolument faire abstraction de cette vision.

Comme vous le voyez, il n’y a pas de notion de temps dans un point d’effort. Le temps va rentrer uniquement en ligne de compte lorsque l’on planifie le développement.

Comment utiliser les points d’efforts ?

Pour utiliser les points d’efforts, on utilise la suite de Fibonacci 🔗  qui est une suite d’entiers dans laquelle chaque terme est la somme des deux termes qui le précèdent (1, 2, 3, 5, 8, 13, 21). Dans notre cas, pas besoin d’aller plus loin que le nombre 21 car sur le principe plus l’estimation en points d’effort est haute, plus la demande est imprécise et incertaine.

Alors, comment attribuer au mieux les points d’efforts ?

1. Estimer le nombre de points en groupe (si vous travaillez en groupe bien sûr)
2. Catégoriser vos points d’efforts sur vos demandes (Front, Back, Design, UX)
3. Estimer sans crainte et sans remord tout en vous reposant sur votre expérience et vos connaissances
4. Si vous avez un doute sur une fonctionnalité, n’hésitez pas à mettre le nombre de points le plus haut
5. Si vous mettez le nombre de points le plus, demandez-vous pourquoi vous le faites ? (manque de précision de la demande, trop d’incertitude, irréalisable)

Ce qui est pas mal avec les points d’effort c’est qu’ils ne sont pas figés dans le temps. Vous pouvez très bien revoir une estimation de points à la baisse car vous avez de nouveaux éléments en main vous permettant de la réestimer.

Bien entendu vu que c’est tout nouveau, vous aurez des difficultés pour vos estimations en points. Le plus simple étant de lister toutes les fonctionnalités de votre projet. Ensuite, vous estimez en premier les plus faciles et les plus rapides. Logiquement avec cette tactique vous devriez avoir de grosses variations de points, c’est plutôt bon signe.

N’oubliez pas que votre estimation n’est pas figée dans le temps et que vous pouvez la réévaluer si vous le souhaitez

Un exemple concret d’utilisation

vous devez développer une application qui contiendra un système d’authentification. Vous savez d’expérience que vous allez devoir développer une page de connexion couplée à un traitement des informations pour connecter l’utilisateur au système. Il y aura donc du front, du back et du design.

Mais à ce stade, nous n’avons aucune idée sur la réalisation de l’authentification. Est-ce que ce sera du SSO avec du Auth0 par exemple ? Est-ce ce sera de l’authentification sur-mesure ? Ou bien les 2 ? Et on peut imaginer que vous n’avez jamais utilisé Auth0.

Juste avec ça, on pourrait faire une estimation de ce genre :

• front : 3
• back : 8
• design : 3

Soit un total de 14 points. Autant dire que cette fonctionnalité sera complexe, longue et fastidieuse. Elle demandera beaucoup d’efforts. Grâce à cet indicateur, vous êtes capable de dire que cela prendra beaucoup de temps et que la fonctionnalité aura un certain coût. Il est donc nécessaire de ne pas commencer par cette fonctionnalité ou de la préciser un peu plus.

Vous apprenez qu’il faudra faire uniquement un système d’authentification sur-mesure. Vous pouvez dès lors réviser votre estimation de points pour la partie back en choisissant par exemple 3 points, ce qui ramène la valeur totale à 9 points.

Voici une représentation d’estimation de points :

exemple de feature avec des points d’effort

Et le temps dans tout cela ?

Si vous avez lu jusqu’ici et que vous avez compris le principe alors mes félicitations. Vous avez compris qu’estimer en points d’effort consiste à faire une abstraction du temps pour l’estimation des fonctionnalités en ne prenant que ce qu’il y a de l’importance pour la rendre la plus correcte et judicieuse possible.

Mais le temps a tout de même son importance mais uniquement à l’étape de la planification de vos tâches. Car oui à un moment donné, vous voudrez (et votre client aussi) savoir combien de points d’effort vous êtes capable de faire.

Vous ne le saurez pas dès le départ et devinez quoi c’est le temps qui vous le dira.

Pour pouvoir évaluer cela, il faut définir des périodes et planifier ce que vous pouvez faire. En général, on planifie les tâches qui demandent le moins de points d’efforts.

Dans SCRUM, ces périodes sont en général de 15 jours à 1 mois. Mais gardez bien en tête qu’une fois que vous avez choisi votre temps de période vous devez vous y tenir (ne faites pas une période de 15 jours puis celle d’après 1 mois).

Normalement au bout de 3-4 périodes, vous serez capable de connaître la moyenne des points d’efforts que vous faites par période. Vous aurez donc une meilleure représentation de ce que vous êtes capable d’accomplir sur une période de temps donnée.

Au final, ce sera plus efficace d’utiliser cette façon de faire plutôt qu’estimer de manière évasive et non exhaustive en se focalisant uniquement sur le temps.