Estimation des charges des projets informatique (1/3)

C’est peut être le sujet le plus stratégique de toutes les entreprises réalisant des projets informatiques. Si elles ne le savent pas c’est à mon avis un peu embêtant ……


Dans la pratique de l’estimation il faut tout de suite bien percevoir deux objectifs.

Le premier est évident, il s’agit de prévoir aussi bien que possible les charges en jours homme de l’équipe de projet et ainsi réaliser, d’une part un planning réaliste et d’autre par d’obtenir une évaluation des coûts permettant de prendre les bonnes décisions.

Le second souvent moins visible est l’opportunité offerte grâce à la mise en place d’une méthode formelle d’estimation reproductible de calculer des valeurs de performance objectives de son organisation et ainsi de lancer des actions d’améliorations continues.

Pour parler du premier objectif , je vais présenter sous forme de caricature la méthode d’estimation des charges la plus répandue :

« La Pifométrie sous tableur »Cette méthode consiste en deux étapes assez simples :

     - Ouvrir un tableur , et lister les tâches du projet (une ligne par tâche)

     - En face de chaque ligne un expert du domaine indique une charge en jours homme contenu de son expérience et de son « pif » : on obtient l’estimation de son projet.

Avantages de la méthode :
     - Très facile et rapide à mette en œuvre pour peu qu’on dispose
     des experts.
     - Donne un taux de justesse des estimations tout à fait honorable.

Pour devenir sérieux et essayer de convaincre ceux qui ont besoin de l’être qu’une vraie méthode d’estimation est plus avantageuse, voici les inconvénients de la méthode « La Pifométrie sous tableur » :

     1) Tout repose sur la compétence et la disponibilité des experts, pas possible de faire une estimation correcte sans eux et risque d’erreur important dès qu’un élément non connu de l’expert est à estimer.

     2) L’expert raisonne très souvent sans même s’en rendre compte en pensant « Si JE fait cela il me faut x jours/homme ». Hors ce n’est pas lui qui réalisera forcément toutes les tâches et c’est l’origine bien souvent de sous estimation.

     3) C’est aussi le fait que pour éviter l’inconvénient ci-dessous les chefs de projet appliquent un coefficient de majoration sensé tenir compte de beaucoup de choses ( y.c des imprévus). Hors la nature à horreur du vide et ce coefficient est un peu à mon avis une fuite en avant qui va conduire au fil des projets à dégrader la performance globale de son équipe et l’image des informaticiens.

Attention je ne dis pas qu’appliquer des coefficients contextuels n’est pas une bonne pratique, cela le reste si c’est fait au bon moment et de manière formalisé avec des règles claires.

Sur cet inconvénient je citerais une définition que l’on trouve dans le doc ci-dessous:

Loi de Parkinson : « le travail se dilate jusqu’à remplir le temps disponible »

http://www.lirmm.fr/....

     4) Pour finir l’inconvénient à mon avis majeur : En oubliant une notion fondamentale : « La Taille » on se prive de la possibilité de construire des indicateurs de performance et donc de lancer des actions d’améliorations.

Pour donner un exemple, mesurer la taille pourrait être d’estimer le nombre de lignes de code nécessaire (Ce qui n’est d’ailleurs à mon avis pas une méthode facile. On le verra dans mes articles suivant) pour réaliser une application puis d’associer un coefficient de productivité du type x/Jours homme par Kilos de lignes pour obtenir la charge.

Voilà une introduction, je l’espère intéressante pour certains , des objectifs d’une méthode d’estimation agile et mature que je présenterais dans les deux articles suivant de ce sujet.

Pour finir sur une note d’humour ceux qui ne connaissent pas la méthode de l’institut
l’IILaR (l’International Institute of La RACHE) peuvent aller la consulter sur le site http://www.cafenware.com/la-rache/.

Il y a d’ailleurs une présentation de la « Pifométrie » très complète http://www.cafenware.com/la-rache/zfiles//unites.pdf