Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles sont les cinq lois à respecter pour une estimation logicielle optimale ?
Un architecte logiciel partage son expérience

Le , par Victor Vincent

0PARTAGES

12  0 
Les estimations sont généralement un mal nécessaire dans le développement logiciel, estime Steve Smith, architecte logiciel sénior, formateur et entrepreneur. Selon lui, beaucoup de gens ont tendance à croire que la réalisation d’un nouveau logiciel est comme la construction d’une maison et que comme l’entrepreneur, l’architecte logiciel doit être en mesure de fournir une estimation correcte et fiable du travail à faire au client. En effet, l’entrepreneur travaille généralement avec des matériaux connus qui ont des coûts déterminés. Or, pour le développement d’un logiciel, une grande partie du système est construit à partir de zéro, d’après Steve. Même la manière dont les différentes parties de ce logiciel seront assemblées, la manière dont il va fonctionner et ce qu’il devra faire exactement ne sont pas connus de manière absolue et peuvent changer à tout moment. Il est difficile dans ces conditions de pouvoir déterminer les dates de début et de fin des différentes tâches du projet.

Steve a donc essayé de puiser de son expérience personnelle pour établir cinq règles qui d’après lui, si elles sont respectées, permettent de réaliser une estimation fiable lors de la réalisation d’un nouveau logiciel.

Première loi : ne perdez pas votre temps à faire des estimations

Steve Smith estime que le temps passé pour faire des estimations peut être valorisé autrement, sur d’autres tâches du projet. Ce temps peut par exemple être ajouté au temps de développement. Mais au lieu de cela, ce que constate Steve c’est que ces derniers sont souvent interrompus pour faire d’autres estimations étant donné que les premières n’étaient pas correctes. Ce qui implique un manque de productivité des équipes de développement. Selon l’architecte, les équipes de développement perdent environ 2 à 4 heures à cause des estimations sur une semaine de 40 heures impliquant une perte en productivité entre 5 à 10 %. Steve rapporte en effet, qu’il y a quelques années, un département de Microsoft a réussi à augmenter la productivité de son équipe sans nouvelles ressources et sans changement de la façon dont étaient effectuées les différentes tâches. Les seuls changements opérés, poursuit l’architecte, concernaient le planning et la façon de faire les estimations. Le paradoxe de l’histoire est que souvent les estimations sont initiées par la direction en vue de plus de transparence, mais aussi dans le but de pouvoir améliorer la productivité de l’équipe.

Deuxième loi : les estimations sont non transférables

Ce qu’il faut comprendre par là, d’après Stève, c’est qu’une estimation faite par un individu n’est pas forcément valable pour un autre pour la simple raison que les personnes ne sont pas les mêmes, n’ont pas les mêmes capacités ni les mêmes compétences en face d'un problème donné. C’est encore moins valable quand l’estimation a été faite par une personne qui n’est pas du même domaine ou qui n’a pas les mêmes intérêts. C’est le cas par exemple quand c’est un commercial, dont le souci est de vendre un produit qui n’est pas encore sorti d’usine, mais qui fait croire au client que le produit en question peut être livré dans un délai assez court, qui fait l’estimation. C’est moins grave quand il s’agit d’une estimation faite par une personne du même domaine, avec un niveau d’expérience similaire. L’erreur à ne surtout pas commettre, avertit Steve, est de faire les estimations pour une équipe en considérant le temps que mettrait le plus rapide de l’équipe pour exécuter une tâche donnée.

Troisième loi : il faut savoir qu’une estimation est par défaut erronée

Les estimations ne doivent pas être considérées comme étant des promesses, mais plutôt comme des suppositions dépendant de l’évolution de l’activité et des risques d’erreurs, d’après Steve. Il déclare en effet que personne ne devrait être surpris lorsque des estimations se révèlent fausses, mais il faut plutôt l’être quand elles sont exactes. C’est d’ailleurs la raison pour laquelle le mot estimation est utilisé et non le mot exactitude. Steve ajoute qu’il faut s’attendre à des précisions plus près de la réalité quand il s’agit d’une petite tâche, mais aussi pour des projets individuels ou des projets en cours d’achèvement. En effet, pour ces derniers, on apprend de ses erreurs pour améliorer les estimations futures pour qu’elles soient les plus précises possible.

Quatrième loi : les estimations sont temporaires

Les estimations sont périssables avec une durée de vie relativement courte, estime Steve. Pour lui, un développeur peut faire une estimation d’une semaine pour « coder » une fonctionnalité de son application avant le début du projet. Trois mois après le démarrage du projet, il peut arriver que certaines spécifications en relation avec la fonctionnalité en question aient changé. D’une semaine, la fonctionnalité peut se retrouver avec une nouvelle estimation d’une heure ou d’un mois, c’est selon, ou alors, il peut arriver que la fonctionnalité soit tout simplement abandonnée pour une raison ou une autre. C’est pour prévoir des cas pareils que certaines équipes recommandent une révision de l’ensemble des estimations de façon périodique, continue Steve. Cependant, cela peut exacerber les membres de l’équipe qui ont encore en tête la première loi. Pour trouver le juste milieu entre les lois « une » et « trois », le conseil de Steve est de retarder les estimations le plus possible en vue d’y inclure tous les facteurs déterminants. Mais pour ceux qui souhaitent une estimation avec 100 % de précision, ils peuvent aussi attendre la fin du travail pour donner une estimation.

Cinquième loi : faire une estimation de ses dépenses

Une estimation qui en vaut la peine d’être faite est bien celle du budget des dépenses, d’après Steve. En effet, l’architecte logiciel affirme qu’aucune équipe de développement ne prendrait la décision de réaliser un nouveau logiciel sans avoir fait au préalable une estimation de ses dépenses. Si les lois précédentes sont valables, cela ne signifie pas faire fi de toute estimation. Pour mieux réussir cette estimation, Steve estime que toute l’équipe doit y participer, du gestionnaire du projet au développeur en passant par le commercial.

Source : Ardalis

Et vous ?

Que pensez-vous de ces cinq lois ?

Voir aussi

la rubrique Humour et Divers

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de webtb
Membre à l'essai https://www.developpez.com
Le 30/11/2015 à 15:36
Bonjour,

En effet, après plusieurs années d’expériences en tant que développeur et chef de projet, ces constatations sont bien réelles.

Malgré un cycle de 60 applications / an (réparties sur plusieurs développeurs), j'arrivais encore à me tromper sur certaines estimations de temps. Donc à la fin, je mettais un coussin proportionnel au volume global de temps.

;-)
3  0 
Avatar de yonisolo
Membre du Club https://www.developpez.com
Le 27/11/2015 à 15:51
Un article qui décrit l'évidence mais qu'il est nécessaire de rappeler.
Il a peut être omis de citer les estimations avant d'avoir lu le cahier des charges sinon globalement je dirai "INDEED"
2  0 
Avatar de 7gyY9w1ZY6ySRgPeaefZ
Expert confirmé https://www.developpez.com
Le 27/11/2015 à 15:56
Ce qui je n'aime pas dans ce genre d'article, c'est que c'est une traduction qui provient d'un blog de quelqu'un que l'on ne présente même pas. C'est quoi la crédibilité de cette personne ? Parce que des experts sur tout et rien, ce n'est pas ce qui manque sur le web...
Apparemment, ce Steve Smith a l'air de tenir la route mais je n'ai pas été plus loin que LinkedIn.
2  0 
Avatar de Zirak
Inactif https://www.developpez.com
Le 27/11/2015 à 16:01
Je trouve tout cela plutôt raisonnable et bon à rappeler en effet.

Au final, je ne vois pas pourquoi cela a été mis dans le forum Humour, je trouve cela plus sérieux que certaines autres actualités du forum en question qui auraient plus leur place ici.
2  0 
Avatar de fenkys
Membre éprouvé https://www.developpez.com
Le 30/11/2015 à 10:52
C'est marrant, je croyais que l'outil indispensable pour faire une estimation était un ensemble de dés de jeu de rôle, le talent de l'estimateur résidant dans la sélection du dé à utiliser.
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 30/11/2015 à 10:59
Fluctus, tu as raison, sauf que face à des managers du genre :

"_j'ai une tâche à vous demander. Combien de temps ça va vous prendre?
_Euh, dites-moi d'abord ce quoi il s'agit?
_Je vous ai posé une question, espèce d'insolent, vous allez répondre? Combien de temps???
_Mais quel est le sujet?
_Non!!! vous répondez d'abord, ou vous êtes viré!!!!! C'est pas compliqué, putain, je demande juste un délai, sombre connard!!!"

"_euh, la spec, il y a deux-3 trucs à corriger.
_Quoi? Je l'ai validée moi-même il y a deux ans!!!
_oui, oui, oui, elle était exacte, à l'époque. Mais l'existant a évolué et il f...
_Ta gueule!!! j'ai validé cette putain de spec, j'ai 60 gugusses qui travaillent dessus, il est hors de question d'en changer la moindre virgule! Sinon, tu sautes!"
(le projet a pris 5 ans dans la vue, j'ai eu la chance d'en sortir très vite)

(authentiques).

On m'a aussi reproché d'avoir consommé 172 jours sur un projet estimé à 170. Un jour, on m'a demandé un chiffrage précis sur une évol simple, mais sur une appli que je ne connaissais ni d'Eve ni d'Adam, et qui avais des dépendances de partout sur la partie comptable de la banque. J'ai appliqué mes ratios prudentiels habituels, j'ai dit 11 jours, j'en ai pris 3, ça s'est passé comme sur des roulettes, les homologateurs n'ont trouvé aucune régression ni aucun impact, et je me suis fait brûler en place publique par le grand chef.

Dans ces conditions là, tu as beau avoir raison, tes conseils, euh, comment rester poli? La vraie problématique des estimations, elle n'est pas technique. Steve McConnell, c'est vieux, et c'est toujours vrai. La vraie problématique, elle est politique. Le manager intermédiaire a besoin de bonnes nouvelles à annoncer pour faire avancer sa carrière, et c'est tout ce qui compte pour lui. La vérité du terrain, rien à foutre.
2  0 
Avatar de Martin Lestas
Membre éprouvé https://www.developpez.com
Le 27/11/2015 à 15:42
Elles sont juste selon moi, évitons de nous poser des questions superflus, c'est du temps de perdu à l'optimisation du logiciel.
2  1 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 27/11/2015 à 16:45
Que pensez-vous de ces cinq lois ?
J'en pense que la 5ème est mal traduite... enfin, l'auteur dit bien qu'il faut estimer les dépenses mais pour ce faire il faut estimer le temps de réalisation des tâches. Puis en fait, il ne se limite pas qu'aux dépenses, il parle bien du temps dans l'article. Ce qui est logique, quand on fait une estimation c'est pour avoir une estimation de coût, de délai, de planning, de ce qu'on peut paralléliser, etc.

Et, il ne dit pas que tout le monde doit y participer (ça serait enfoncer une porte ouverte...) mais, que toutes les parties concernées doivent être consciente et comprendre les 4 précédentes lois.

Just because the above laws are true doesn’t magically mean estimates can go away (#NoEstimates). However, one can better manage expectations and time spent on estimating if everybody involved, from the customer to the project manager to the sales team to the developer, understands these truths when it comes to custom software estimates.
1  0 
Avatar de tazio
Membre à l'essai https://www.developpez.com
Le 27/11/2015 à 16:51
Je suis sensible à l'idée que demander trop d'estimation coute énormément.
Mais, comment propose-t-on une date de livraison si on applique la première loi?

Le poker planning et les révisions de planning sont à mon sens la bonne approche.
1  0 
Avatar de fluctus
Membre à l'essai https://www.developpez.com
Le 29/11/2015 à 14:34
On retrouve les bases décrites par Steve Mc Connell dans son livre "Software estimation : demistifying the black art" : http://www.stevemcconnell.com/est.htm
A lire également : les posts autour du hashtag #noEstimates sur Twitter, hashtag initié par Woody Zuill. A retrouver de manière plus détaillée notamment sur son site : http://zuill.us/WoodyZuill/

La base des techniques d'estimation prédictives reste les abaques.
La méthode des points de fonction est réputée la plus efficace, devant Cocomo.
Peu de gens utilisent l'estimation par points de use case, qui reste ma préférée.

Mc Connell recommande d'utiliser une fourchette allant du scénario le plus optimiste au scénario le plus pessimiste (worst case scenario). Il démontre qu'il existe un cône d'incertitude : les estimations deviennent de plus en plus exactes au fur et à mesure... de l'avancée du projet : http://www.construx.com/Thought_Lead...f_Uncertainty/

Sans abaques applicables au contexte, comment estimer ?
La moins mauvaise technique reste la méthode du planning poker, en utilisant le t-shirt sizing, plus simple que la vélocité : https://youtu.be/CGJOZHCI2a0

En résumé, si vous débutez, découpez le projet en tâches (pas en fonctionnalités).
L'idéal est de partir de la liste de vos use cases UML. Munissez-vous de leur description textuelle (c'est à peu près l'équivalent des user stories de scrum).
Demandez-vous simplement si une tâche va mettre MOINS de 2h, MOINS de 2 jours, MOINS de 2 semaines, ou plus.
N'essayez pas d'estimer plus finement : le but n'est pas d'obtenir quelquechose de précis, mais une estimation que l'équipe peut réussir à réaliser.
Une tâche plus grande que 2 semaines n'est pas assez finement découpée. Il faut d'abord la découper en tâches inférieurs à 2 semaines pour pouvoir l'estimer.

De facto, un sprint scrum durant entre 2 et 4 semaines, vous ne pouvez pas réaliser dans un sprint plus d'une tâche de moins de 2 semaines.
Vous avez donc la réponse qui compte vraiment aux yeux de votre client.
Le but est de l'aider à prioriser ses demandes, en associant un coût aux fonctionnalités qu'il demande. Ainsi, il se rend compte de la faisabilité de son projet et peut ajuster ses demandes.
Ce type d'estimation vous fera peut-être rater des marchés, parceque vous serez plus chers que d'autres concurrents.
Par contre, vous serez plus fiables, ce qui augmentera votre rentabilité et évitera à voter entreprise les affres des pénalités de retard et du bad buzz.
En vous obligeant à formuler le pari que la tâche dure "MOINS que", vous placez la borne extrême du cône d'incertitude (worst case scénario).

Si vous êtes capable d'estimer plus exactement les tâches, c'est que vous disposez déjà d'un peu d'expérience dans le contexte de développement.
Du coup, vous pouvez vous orienter vers une méthode prédictive car vous disposez en fait d'abaques.
Beaucoup de développeurs n'enregistrent pas leurs abaques dans un fichier. Pourtant, avec un peu d'expérience ils savent se souvenir du temps qu'ils ont déjà passé sur une tâche en fonction de sa nature, sa complexité et son "volume".
Pour classer simplement les tâches dans les abaques je recommande de dire si une fonction est longue/courte/courte et simple/normale/compliquée à coder.

Difficile de dire tout en quelques lignes sur un sujet aussi difficile, mais je pense qu'avec ces bases on peut éviter bien des déboires...
1  0