L’art sombre de l’estimation logicielle

Disons le clairement : les dépassements de coûts/délais que peuvent connaître les projets web relèvent souvent plus d’une mauvaise estimation initiale que d’un véritable raté technique. Au moment de faire les comptes, on a bien évidemment toujours des raisons de penser que l’on aurait pu faire mieux ici ou là, que certaines parts des spécifications avaient été incomprises ou que quelques détails techniques subtils avaient fait perdre un temps que l’on n’avait malheureusement pas. Oui, il est certain qu’il y a toujours matière à s’améliorer, mais la perfection n’étant pas de ce monde, mieux vaut se résoudre à faire des estimations qui sauront prendre en compte à l’avance les inévitables aléas que connaissent les projets du monde réel.

En dehors de la bible du développement qu’est « Code Complete« , Steve McConnell a eu le génie de publier il y a près de 10 ans « Software Estimation : Demystifying the Black Art« . Après un peu plus d’un an de suivi des pratiques qu’il recommande, je dresse ici un compte-rendu des principales leçons que j’en tire.

Un précieux grimoire trop peu connu du monde du web

Un précieux grimoire trop peu connu du monde du web

Pourquoi les estimations sont-elles si souvent mauvaises ?

Une des choses les plus marquantes du livre est de découvrir à quel point les estimations ont tendance à sous-évaluer les projets. Nombreux sont les intervenants du monde logiciel à le ressentir et au fil des années, les plus expérimentés multiplient artificiellement toutes les estimations qu’ils transmettent par un facteur extrêmement variable (j’ai croisé dans ma carrière des multiplicateurs allant de 1.3 à 4 !) de manière un peu arbitraire pour compenser cette tendance naturelle. Cette manière de procéder est néanmoins néfaste : elle conduit en général à faire exploser les estimations des projets bien maîtrisés tout en gardant un risque important d’erreur sur les autres. Or, la sous-estimation comme la sur-estimation ont un impact sur la qualité et le coût final des projets.

Mais alors, qu’est-ce qui provoque une telle généralisation de la sous-estimation ? Les raisons ne manquent pas :

  • des spécifications encore trop imprécises
  • l’influence des donneurs d’ordre : les gens qui demandent les estimations ont, qu’ils le disent ou non certaines attentes… et sous leur pression (volontaire ou non), les estimateurs vont avoir tendance (consciemment ou non) à rapprocher leur estimation de ces attentes.
  • des demandes d’estimation « au débotté » qui ne laissent pas aux estimateurs le temps de réfléchir correctement à la question posée
  • l’oubli d’éléments de travail à accomplir : plus une tâche est importante, plus le risque d’oublier des sous-tâches qui la composent est important. Mon expérience est qu’une tâche dépassant 2 jours de travail estimé présente ce risque de manière très significative.
  • la seule prise en compte des temps de développement : ce sont bien souvent les développeurs qui donnent les estimations. Ils vont donc livrer une estimation de ce qu’ils font, à savoir le développement… activité qui ne représente qu’entre 40% et 80% d’un projet logiciel.
  • la faible mesure du risque : on observe généralement que les estimations données correspondent au cas où tout se passe bien. L’évaluation des inévitables aléas n’est en général pas assez sérieuse pour avoir une vision réaliste des temps moyens les plus probables.
  • l’effet Dunning-Kruger : dans les domaines qu’ils connaissent moins, les individus ont une confiance trop importante dans leurs compétences… or, le domaine logiciel est trop vaste pour que toutes les parcelles d’un projet à estimer soient bien maîtrisées par un seul estimateur.

Steve McConnell livre ainsi dans son blog une expérience personnelle dans laquelle il  construit une cabane pour ses enfants et dépasse de 100% son temps passé et ses délais. C’est amusant de voir à quel point, tous les défauts relevés au dessus y sont présents, mais ce n’est guère étonnant quand on sait à quel point les projets logiciels et  BTP partagent des caractéristiques. Steve McConnell résume ainsi l’échec de son estimation : « je n’ai tout simplement pas pris le temps de faire une véritable estimation sur papier et un planning détaillé pour ce projet ». C’est peut-être la leçon la plus importante à retenir : faire une bonne estimation exige de la méthode et du temps. Si l’on est prêt à investir en ce sens, voici comment s’y prendre.

Compter, calculer, juger

La première étape d’une bonne estimation est de trouver un élément dénombrable qui soit dénombrable sur lequel il sera possible de s’appuyer : nombre d’écrans, d’éléments d’interface, de requêtes, de « use cases », de points de fonction, de classes, de lignes de code… bref, il faut pouvoir compter.

Une fois que l’on est en mesure de compter un élément que l’on pense significatif, il est nécessaire de calculer afin d’aboutir à une estimation. La plupart du temps, il s’agit de faire de simples multiplications, mais si les données à votre disposition s’y prêtent, il est possible de procéder à toute sorte de régressions mathématiques en travaillant par analogie avec des projets précédents.

Le jugement sans quelque chose que l’on puisse décompter ne doit être utilisé qu’en dernier ressort. Et si il est utilisé, il ne doit concerner que des estimations de petites tâches (la fameuse limite de 2 jours évoquée plus haut). La décomposition du projet en  micro-activités est donc fondamentale si le jugement doit intervenir.

Collecter des données

C’est là le point central de la démarche de McConnell : pour faire des estimations correctes, il faut s’appuyer sur des chiffres issus de la réalité des projets menés par vos organisations. Cela demande de mettre en place un process de collecte des temps suffisamment précis pour les affecter à des tâches particulières au sein d’un projet donné : la plupart des outils de gestion de projet permettent cela. En l’absence de données internes, McConnell fournit quelques sources de données de l’industrie logicielle.

Autant le dire immédiatement, c’est loin d’être aussi simple qu’on pourrait le penser. Même avec un bon gestionnaire de tâches et une équipe habituée depuis plusieurs années à saisir ses temps passés, nous avons rencontré des difficultés à avoir des données réutilisables. Il nous a semblé que les tâches que nous créions soient trop spécifiques aux particularités de nos projets : nous nous sommes ainsi aperçus qu’il fallait créer des tâches un peu standard et des « templates » de découpage de projet encourageant à utiliser ces standards, puis à créer des sous-tâches pour y mettre les points plus spécifiques.

Appliquer une méthode

Steve McConnell ne donne pas une méthode d’estimation toute-faite, mais un ensemble d’approches qui peuvent se combiner et qui s’avèrent plus ou moins adaptées en fonction du contexte. La taille des projets et surtout le moment auquel intervient l’estimation amènent donc à choisir une approche plutôt qu’une autre. La méthode que préconise McConnell est en fait de vous construire votre propre processus d’estimation en choisissant selon les situations parmi une ou plusieurs des techniques suivantes :

  • le jugement individuel d’un expert
  • la décomposition-recomposition
  • l’analogie
  • l’estimation basée sur des éléments dénombrables
  • l’estimation en groupe d’experts
  • l’utilisation d’outils dédiés

A titre d’exemple, mon processus simplifié est le suivant :

  • si je n’ai pas encore de véritables spécifications
    • je travaille par analogie
    • j’essaie de trouver des éléments que je peux déjà dénombrer : le plus souvent un nombre d’écrans à faire si nous devions réaliser un story-board
    • je regarde comment je dois adapter mon estimation en fonction de l’influence des facteurs de la méthode COCOMO
  • si les spécifications le permettent
    • je prépare une feuille de calcul équipée de quelques formules préconisées par McConnell pour travailler par décomposition/recomposition
    • je confie l’estimation à la personne de l’équipe ayant la plus grande expérience sur la technologie envisagée et lui demande de remplir la feuille
    • je fais une revue de l’estimation avec mon expert

Au delà de l’estimation donnée, ce processus a plusieurs effets bénéfiques :

  • quand je travaille en l’absence de spécifications précises, je peux préciser à mon donneur d’ordres : « mon estimation part de l’hypothèse de 50 écrans de story-board, cela vous paraît-il réaliste ? Bien, il faudra l’ajuster en fonction du nombre que nous aurons une fois le story-board complet ». Il n’a ainsi aucun mal à comprendre que le budget soit de l’ordre du double si le nombre d’écrans a doublé.
  • travailler séparément par décomposition/recomposition avec un expert puis faire une revue ensemble permet d’identifier plus de risques ou de manques dans les spécifications qu’en travaillant en une seule session.
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s