fbpx

Le cauchemar de l’estimation

deadline monsterQui de nous n’a pas été frustré quand son boss lui a demandé d’estimer le temps qu’il lui faut pour un tel script ou un tel projet ? Ceux qui sont en relation directe avec les client ont toujours entendu les expressions : « Je veux un site web, combien cela va me coûter et combien cela va-t-il vous prendre de temps ? »
Chanceux sont ceux qui n’ont pas à dealer avec ces contraintes. Malheureusement, je ne fais pas partie d’eux, je suis plutôt d’une équipe de services professionnels et la première question que mon chef de projet me pause est : « combien cela va-t-il prendre de temps ? », et après : « ou est ce que tu es arrivé ? »

Nos projets ont toujours des « deadlines » et des budgets, et nos clients attendent de nous de livrer le travail dans le budget et avant les « deadlines ».

Dans cet article, je vais essayer de partager mes connaissances par rapport à la question « combien cela va-t-il prendre de temps ? ».

L’importance des estimations

Vous ne connaissez pas peut être la vraie importance de l’estimation si vous n’auriez jamais eu à faire de la gestion de projet ou que vous n’auriez jamais eu une relation directe avec un client. Aussi, quand on est au poste de développeur et que l’on ne se soucie que du code qu’on écrit, on ne voit pas vraiment l’importance du sujet. Mais les estimations servent à déterminer plusieurs points importants:

– Déterminer les dates limites « deadlines »

Déterminer la date limite du projet est souvent la tâche du commercial. Mais dans la plupart des cas, les avis de l’équipe de développement influencent la décision en déterminant le temps que va prendre le développement d’une telle ou telle fonctionnalité. Le gestionnaire de projet peut suite à cette estimation élaborer un plan de projet qui prend en considération les requis de délai et la charge de travail.

– Déterminer les coûts

Avant qu’un client accepte d’acheter un produit ou un service, il veut toujours savoir combien cela va lui coûter. Aussi, dans le cas ou le projet nécessite plusieurs parties, le coût devient un facteur important. Même si le coût n’est pas vraiment le plus grand facteur pour beaucoup de projets (la ou la qualité et la confiance le sont), c’est toujours un facteur essentiel à prendre en compte.

– Déterminer la valeur

La valeur est différente du coût. En particulier dans le cas des estimations de nouvelles fonctionnalités dans un projet existant, votre estimation va beaucoup aider pour déterminer la valeur de cette fonctionnalité. Un client peut vouloir une liste de fonctionnalités, mais pas à n’importe quel coût. Il va comprendre qu’une fonctionnalité « fantaisiste » va avoir un coût significativement important de temps, il va alors vouloir repenser si elle est bien utile et s’il en a vraiment besoin ; ou à sa priorité s’il en a vraiment besoin.

– Éliminer la mal-compréhension

Si vous êtes ouvert à propos de vos estimations, vous allez découvrir les mal compréhensions et les mauvaises interprétations à un stage précoce. Si vous estimez par exemple une fonctionnalités à 3 jours de travail, et que vous discutiez ceci avec le client, il pourrait vous dire que c’est bien au-delà de ce qu’il pensait et qu’il voyait la chose plus simplement que vous ne la voyez. Si au contraire vous l’estimiez à 5 minutes, il va vous faire comprendre que vous l’avez peut être sous estimation. Spécialement dans les projets ou le prix est fixe, il est commun que les estimations ne soient pas ouvertes avec le client, mais en effet, le fait qu’elles soient ouvertes fait plus de bien que de mal !

– Améliorer vos estimations

La meilleure façon d’avoir de meilleures estimations est d’estimer, et d’évaluer par la suite les estimations. Si un projet est fini, analysez vos estimations et voyez ce qu’il y a eu de bon et de mauvais. Ceci va vous aider à être plus au courant combien de telles tâches prendront.

Le syndrome de l’étudiant !

J’aime bien cet exemple, j’avais lu ça il y pas longtemps et je trouve que ça fait beaucoup de sens :
En général, les développeurs sous-estiment plus qu’il ne sur estiment. L’une des raisons est ce qu’on appelle « le syndrome de l’étudiant ». Si les étudiants ont trois semaines pour finir un travail, ils vont glander les deux premières semaines et ils vont commencer à travailler la troisième semaine. Quand le travail s’avère plus important qu’ils ne l’auraient pense, la date d’échéance serait venue et ils auraient dépasse les délais.
Ceci est également le cas pour les développeurs, même si ils ne le font pas exprès, si vous aviez une tâche qui prend 4 heures, les chances sont grandes que vous allez utiliser plus que ces 4 heures. Même si vous pouviez la faire en 2 heures, vous voulez avoir un truc plus fantaisiste et passer plus de temps pour vos tests etc. c’est lorsque les 4 heures soient finies que vous réalisez que vous avez besoin de plus de 4 heures pour la finir, mais le temps serait déjà écoulé.
Une bonne façon pour éviter ceci est de vous donner moins de temps au lieu de plus. C’est un peu controverse mais si vous dépassez beaucoup vos estimations, vous tendez à les augmenter. Si vous n’avez pas pu finir la tâche en 4 heures, vous allez vous donner 6 heures la prochaine fois pour la finir. Mais si vous vous donnez 6 heures la prochaine fois, il y a de fortes chances que vous auriez besoin de plus de temps, et ainsi de suite.
Au lieu de ce faire, la prochaine fois, si vous estimiez une tâche à 4 heures, donnez vous 3 heures pour la faire lorsque vous commencez le travail. Vous aurez une heure de tampon à la fin de la tâche (l’heure tampon est calculée dans les estimations) et la chance de joindre vos estimations augmente.
En effet, quand vous êtes au courant du syndrome des étudiants vous allez faire de meilleures estimations et vous allez être capable de finir a temps.

Doubler les estimations

Ce scénario est très courant, on tend toujours à dire arbitrairement quand on a du mal à faire une bonne estimation : « ok, on va doubler les nombres ». C’est la décision la plus mauvaise que vous pourriez prendre. Si vous doublez les nombres, le syndrome de l’étudiant sera toujours présent et vous allez passer plus de temps dans le développement qu’il n’en est nécessaire. Aussi cette méthode va rendre les estimations arbitraires. A un certain moment, les estimations vont être plus importants que leurs valeurs commerciales, ce qui veut dire que l’équipe va passer tellement de temps sur un projet que ce dernier ne sera plus vraiment viable. Vous allez alors entendre vos client dire: « je ne vais vraiment pas payer CECI pour un simple site web ! », et vous aller savoir que vous avez certainement a revoir comment vos estimations ont été créées.

« Doubler les nombres est la chose la plus mauvaise que vous pouvez faire dans une estimation »

Au lieu de doubler les nombres, ce qu’il faudrait faire est plutôt de penser à un nombre dans lequel vous pensez que vous pouvez réellement développer la fonctionnalité, sans avoir à calculer un tampon pour chaque fonctionnalité. Ajoutez ensuite 30% au projet en entier. Ceci va aider à ne pas avoir le syndrome de l’étudiant parce que chaque fonctionnalité est basée sur une estimation réaliste et que vous vous êtes donnés une bonne période tampon si vous rencontrez un problème.

Les tâches non reliées au développement
Le temps non alloué au développement est souvent mal estimé et négligé. Ce temps comprend le temps de gestion de projet, de test, de mise en place des environnements, d’assistance pour la mise en production etc. Si vous estimez un projet, donnez de l’importance à ces tâches. Vous allez savoir par le temps combien qu’ils prennent de temps. Le temps de mise en place d’un environnement est constant, le temps de gestion de projet tend à être un certain pourcentage du temps total du projet, bien qu’il dépende de plusieurs facteurs comme le facteur client. Certains clients nécessiteront plus de temps de gestion de projets que d’autres. Ceci dépend en fait de la complexité du projet.

La meilleure estimation est la votre

Dans les grands projets, l’estimation est souvent faite par quelqu’un d’autre à part vous. Cela peut être par exemple un développeur senior qui a beaucoup d’expérience, bien que ce n’est pas lui qui va écrire le code. Toutefois, si vous travaillez sur un projet avec des estimations, traitez ces estimations comme votre budget, mais créez toujours vos propres estimations au préalable. Si vous trouvez que vos estimés sont très différents de votre budget, parlez avec la personne qui les a faites et essayez de comprendre le pourquoi de la chose, pour savoir si vous avez mal compris une partie, ou peut être que cette personne a dépassé quelques détails inconnus lors de son estimation. Le fait d’en parler va certainement permettre de faire une meilleure estimation.

Anis Berejeb

Anis est avant tout un passioné de l'agilité et du développement. Avec plus de 15 ans dans le domaine du développement web, son expertise combine des connaissances accrues dans l'ensemble des notions partant du développement logiciel jusqu'à l'organisation des équipes dans les environnements agiles à grande échelle.

You may also like...