Discussion :

[Victor Vincent]

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

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

[Aooka]

Elles sont juste selon moi, évitons de nous poser des questions superflus, c'est du temps de perdu à l'optimisation du logiciel.

[yonisolo]

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"

[Invité]

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.

[Zirak]

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.

[Issam]

Enfin une article écrit par un "expert" et cité dans la rubrique actualités de DVP qui a du sens !

[yann2]

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.

[tazio]

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.

[mothsART]

Il a effectivement raison dans la majorité de ce qu'il avance. Cependant, c'est délicat à appliquer dans des conditions réel.
Les clients sont souvent commanditaire des délais et vu qu'ils ne sont pas du domaine, ils planifient selon leurs conditions!
Si on ne s'aligne pas à leur raisonnement, c'est la concurrence qui remporte le marché en règle générale.
Après, beaucoup de boites font tout pour appâter le client avec des estimations alléchantes et s'ils finissent par avoir des retards, ils s'y retrouve néanmoins. (même si ça baisse les bénéfices)

[Jarodd]

Ca coule de (code) source, ce sont des évidences qu'il faut parfois rappeler.
D'ailleurs je m'empresse de transférer le billet à mon chef de projet

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.

Pourtant il est très connu ! Enfin, son père plutôt, qui a une série à sa gloire, American Dad! !

[TiranusKBX]

l'estimation des coûts je laisse ça à ceux censés faire passer la pilule au client ^^

[fluctus]

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...

[fenkys]

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.

[el_slapper]

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.

[webtb]

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.

;-)

[midonet7]

Bonjour,

Très bon article (y).

Sinon, Y’a-t-il une possibilité de télécharger ce genre d’article sous format PDF ?

[fluctus]

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!!!"
(...)

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.

Ce que tu décris est malheureusement tellement fréquent que c'en est à pleurer.
Le management, la gestion de projet sont des métiers à part entière. Etre un bon développeur ou un bon commercial ou un bon gérant d'entreprise ça ne donne pas les compétences pour gérer un projet.
Je croise même des gens du marketing qui écrivent sur leurs CV ou dans les services qu'ils proposent à leurs clients "gestion de projet". Et quand on travaille ensemble ils découvrent l'expression "diagramme de gantt", ou m'envoient des fichiers Excel avec des dates de MEP un jour férié.

Quant à l'ambition et l'éthique, c'est une question indépendante des compétences.
Avec de tels comportements, allez vous étonnez du turn over dans certaines sociétés. Parfois, ce taux reste bas car dans les villes de provinces il est difficile de changer de poste, alors quand on a un travail on le garde !
A l'inverse, certaines sociétés n'ont aucun mal à recruter les meilleurs. Elles ne proposent pas forcément des salaires élevés.
Elles traitent "seulement" les gens correctement.

PS : je ne connaissais pas Bruce Webster. Merci, car grâce à ton lien, je l'ai découvert et ses articles ont l'air de petite mines d'or.

[sierramike]

Au contraire, je pense que ce monsieur est le prototype même de la personne qui se plaint que ce qu'on lui demande n'est pas faisable, croyant qu'il est l'exception du reste du monde.

Prenons justement son exemple de la construction de bâtiment.

Le commercial aura tendance à promettre une construction dans un délai et un tarif des plus serrés pour remporter le marché, à l'opposé des chefs de chantiers et ouvriers.

L'entrepreneur utilise des matériaux connus avec des coûts déterminés

Au contraire, les constructeurs sont loin de maitriser toutes les notions chimiques des matériaux qu'ils utilisent et se laissent souvent surprendre. De plus, un retard dans le planning peut conduire à voir le coût de la matière première fluctuer.

Or, pour le développement d’un logiciel, une grande partie du système est construit à partir de zéro, d’après Steve.

Comme un immeuble construit sur un terrain initialement gazonné...

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.

Comme un bâtiment dont la construction débute avant d'en connaitre tous les futurs occupants.

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é.

Comme deux ouvriers ne sauront pas exécuter une même tâche dans le même temps et avec la même qualité.

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.

Comme deux artisants menuisiers ne sauraient pas monter des portes et des huisseries dans le même temps.

il peut arriver que la fonctionnalité soit tout simplement abandonnée pour une raison ou une autre.

Comme on peut abandonner des aménagements dans un bâtiment parce qu'on estime finalement que ce n'est pas nécessaire, ou qu'on va les modifier car on se rend compte que la demande a évolué.

Une estimation qui en vaut la peine d’être faite est bien celle du budget des dépenses

C'est encore plus vrai dans le bâtiment ! Aurait-il pris des cours chez Lapalisse ce monsieur ?


En bref, ses directives sont louables, mais clairement pas adaptées à un marché commercial. Ce ne sont que les revendications d'un architecte/chef de projet excédé, qui peuvent s'appliquer à la totalité des métiers, informatique ou non, mais sont dans la réalité peu applicables. Le client a besoin de savoir quand son produit sera livré, et ce qu'il va lui coûter.

Lorsque nous commandons une voiture, nous voulons savoir combien elle coûtera et quand elle sera livrée. Nous n'accepterions pas de la recevoir un an plus tard pour le triple du prix, parce que finalement telle ou telle option a été modifiée parce qu'il y avait un bug, et entre temps le coût du métal a quadruplé. Lorsque nous faisons construire notre maison, nous avons besoin de savoir si nous emménagerons dans un an ou dans trois ans, car nous payons probablement un loyer entre temps et qu'il faut en prévoir le budget, tout comme le coût de la maison, que l'on ne voudrait pas voir augmenter parce que le prix du ciment et de la peinture ont augmenté pendant que l'hiver rigoureux a bloqué le chantier ...

[el_slapper]

(.../...)Lorsque nous commandons une voiture, nous voulons savoir combien elle coûtera et quand elle sera livrée. Nous n'accepterions pas de la recevoir un an plus tard pour le triple du prix, parce que finalement telle ou telle option a été modifiée parce qu'il y avait un bug, et entre temps le coût du métal a quadruplé. Lorsque nous faisons construire notre maison, nous avons besoin de savoir si nous emménagerons dans un an ou dans trois ans, car nous payons probablement un loyer entre temps et qu'il faut en prévoir le budget, tout comme le coût de la maison, que l'on ne voudrait pas voir augmenter parce que le prix du ciment et de la peinture ont augmenté pendant que l'hiver rigoureux a bloqué le chantier ...

C'est dommage, jusque là, j'étais d'accord.

Mais une p***de voiture, il en sort une toutes les 120 secondes de la p*** d'usine. Donc le cout est parfaitement connu, maitrisé, et lissé. Il peut y avoir de petites variations en fonction du prix des matières premières, mais ça s'arrête là.

Un bâtiment, c'est pareil. Si c'est du jamais fait(fréquent), on est, comme tu le dit très bien, dans un cas similaire au logiciel. Si on en est au 120ème pavillon du lotissement, ben, tout est lissé, on sait parfaitement ce que ça va nous couter, il suffit de faire des stats sur les 119 premiers pavillons.

En logiciel, on est toujours sur du jamais fait(sinon, on récupère le code qui marche, de préférence par encapsulation, par copier-coller si on est un goret). Mais tu as raison, sans être systématique, c'est fréquent dans d'autres domaines(je pense à la construction navale, par exemple).

[sierramike]

C'est dommage, jusque là, j'étais d'accord.

Mais une p***de voiture, il en sort une toutes les 120 secondes de la p*** d'usine. Donc le cout est parfaitement connu, maitrisé, et lissé. Il peut y avoir de petites variations en fonction du prix des matières premières, mais ça s'arrête là.

Un bâtiment, c'est pareil. Si c'est du jamais fait(fréquent), on est, comme tu le dit très bien, dans un cas similaire au logiciel. Si on en est au 120ème pavillon du lotissement, ben, tout est lissé, on sait parfaitement ce que ça va nous couter, il suffit de faire des stats sur les 119 premiers pavillons.

En logiciel, on est toujours sur du jamais fait(sinon, on récupère le code qui marche, de préférence par encapsulation, par copier-coller si on est un goret). Mais tu as raison, sans être systématique, c'est fréquent dans d'autres domaines(je pense à la construction navale, par exemple).

J'avoue que le choix de la voiture était un peu bancal, à la rigueur ça s'appliquerait mieux sur des camionnettes d'artisans à aménagement spécifique, ou des remorques de poids lourds spécifiques.

Dans le bâtiment, des lotissements avec 120 pavillons identiques, c'est quand même pas le cas le plus fréquent, j'ai vécu dans plusieurs régions de France, je n'ai vu que des lotissements avec des maisons individuelles dont aucune ne se ressemblait, et je n'ai aucune personne dans mon entourage qui n'ait fait construire une maison identique à une déjà existante. D'ailleurs mes principales citations concernaient des immeubles, qui à part les tours jumelles du feu WTC ou celles de Kuala Lumpur, sont toujours des constructions uniques.

D'ailleurs, au 120ème pavillon de ton lotissement tu ne seras jamais à l'abri d'être en bordure du lotissement sur une galerie d'une ex mine de charbon qui fait tout s'affaisser et mette le projet en retard, en engendrant des surcoûts ...