Extrapoler les estimations données par une équipe de développement

mois-homme,estimations,effort,budget,programmeurs,développeurs

Ce à quoi cet article se propose de répondre est une question à laquelle les chefs de projet sont souvent confrontés: une feuille d'estimations à été remise par des programmeurs et il faut maintenant transformer ces estimations en budget.

Tous les chefs de projet vous le diront, les programmeurs sont dans l'incapacité de déterminer le budget qui couvre le travail qu'ils vont devoir fournir.

La capacité intellectuelle — grands dieux, non — n'a absolument rien à voir avec le constat d'incapacité préalablement énoncé. C'est tout simplement qu'ils ne peuvent avoir une vue globale du travail à réaliser et qu'ils prennent pour mesure de leur productivité des conditions artisanales dans lesquelles ils ne se retrouvent que très rarement.

Ainsi, il est bon de savoir que les programmeurs, lorsqu'ils remettent des estimations, en sont réduits à émettre des hypothèses qui peuvent très bien ne pas se vérifier. Ils émettent toujours l'idée que les analyses, tant fonctionnelle que technique qui sont faites en amont, font commerce de détail, qu'elles sont suffisamment fouillées, qu'elles font l'inventaire de TOUT ce qui est à faire.

Et cela, nous savons que ce n'est pas le cas. D'ailleurs, premier élément sur lequel il va falloir plancher, c'est justement de calculer le travail d'analyse … et ce travail d'analyse, nous le découpons toujours en 3: l'analyse d'impact, l'analyse fonctionnelle et, enfin, l'analyse technique (et cela quel que soit le nom qu'on leur donne!

Puis, ils ne vous parleront pas non plus, ou très rarement, de l'effort de test, effort qui pourrait très bien être découpé en plusieurs phases également, comme le propose le modèle en V. S'ils vous parlent de tests, soyez assuré que ce qu'ils entendent par tests ce sont les tests unitaires, activité qui s'apparente au développement. Voilà donc un deuxième élément dont il va falloir tenir compte, car par expérience, les programmeurs ne vous parleront pas des activités en aval de leur travail.

Au rang des activités en aval du travail des programmeurs, et donc non incluses dans les estimations que vous fournissent les programmeurs, on compte également les activités de déploiement … car l'objectif est quand même d'installer les programmes réalisés, de les mettre en production. Nous y reviendrons plus loin.

Ce que leurs estimations ne couvrent pas non plus, ce sont toutes les activités de supervision, de contrôle. En d'autres termes, il va falloir tenir compte d'activités de Gestionde projet. Nous vous invitons donc à prendre connaissance de l'article que nous aavons consacré au sujet: Calculer correctement l'effort de Gestion de projet.

Enfin, leurs estimations ne renseignent généralement pas le nombre de personnes auxquelles ils envisagent d'assigner le travail à faire. A priori, nous sommes un peu déconnectés de la problématique des estimations avec ce sujet embêtant: les ressources. Mais pas tant que cela car le nombre de personnes qu'ils envisagent sur les tâches peut avoir une influence non négligeable sur le budget. Cela mériterait quelques éclaircissements qui pourront faire l'objet d'un nouvel article. En essence, sachez que toute équipe de 5 à 6 personnes implique l'addition d'un chef d'équipe … et c'est là bien évidemment qu'une influence sur le budget peut être détectée.

Ce qu'il faut ajouter aux estimations

Comme l'invite de cet article le suggère, son prodrome, il y a donc, aux estimations fournies par le développeur, quelques activités supplementaires que le chef de projet avisé budgètera.

1. L'analyse (fonctionnelle et technique) (l'analyse d'impact n'appartient pas à la phase d'exécution d'un projet)
2. Les tests
3. L'activité de supervision
4. Les déploiements

… et cela fera déjà une énorme différence, comme vous allez le voir. En fait, nous partons de la formule globale que nous présentons au paragraphe suivant.

Formules

Comme il s'agit donc de pouvoir budgéter le travail global, nous vous proposons une formule globale également que voici:

    ET = ANA + DVL + TST + DEPL + PM + CTGY

… où

ET

Effort Total

ANA

Effort Analyse (fonctionnelle et technique)

DVL

Effort Développement (compréhension et étude des analyses, programmation et tests unitaires)

DEPL

Effort de déploiement (installation)

PM

Project Management (supervision)

CTGY

Contingence (% prévu pour couvrir … l'imprévu)

… et comme nous vous le disions, seul le terme DVL de l'équation correspond aux estimations que vous ont fournies les développeurs. Autant le savoir!

Formule de l'effort

Dans la formule de l'effort global, ET, différents membres de l'équation peuvent être évalués en fonction de membres premiers. Cela parait évident si par exemple on en revient aux termes PM et CTGY.

Le terme PM doit être évalué en fonction de la taille de l'équipe et de la durée de la mission. Voyez à ce propos notre article Calculer correctement l'effort de Gestion de projet.

Le terme CTGY, peut se voir attribuer une valeur relative, un pourcentage par exemple en fonction des certitudes/incertitudes avec lesquelles vous devez composer.

Quant au terme TST, une valeur de subsitution de 33% de ANA + DVL est acceptable.

Posons donc que ANA + DVL est l'effort:

    E = ANA + DVL

… on en déduit que ET équivaut à:

    ET = ( 1,33 x E ) + DEPL + PM + CTGY

L'effort d'analyse

L'effort d'analyse est calculé chez Lato Sensu Management, quand il n'a évidemment pas été estimé spécifiquement, comme représentant une fois et demie l'effort de développement (programmation + tests unitaires). Ainsi, ANA = 1,5 x DVL! On en déduit dès lors – si une estimation spécifique pour l'effort d'analyse n'a pas été fourni, et à cette condition expresse – que la formule de calcul de l'effort devient:

    E = 2,5 x DVL

… et donc la formule du calcul de l'effort total devient:

    ET = ( 1,33 x ( 2,5 x DVL ) ) + DEPL + PM + CTGY

Si, à ce stade nous voudrions tenter une petite comparaison avec les estimations initiales d'une équipe de développement, où cela nous mènerait-il? Livrons-nous au calcul avec une estimation de départ de 100 jours (provenance: équipe de programmation):

    ET = ( 1,33 x ( 2,5 x 100 jours ) ) + DEPL + PM + CTGY = 332,5 jours + DEPL + PM + CTGY

Et vous voyez que nous sommes déjà très loin de l'estimation d'origine, ce qui nous fait étrangement penser à ce chef de projet expérimenté qui nous disait toujours multiplier les estimations par π (pi)! Il n'était pas loin le bougre, car enfin, 1,33 x 2,5 = 3.325.

L'effort de Project Management

L'effort de supervision de projet a été détaillé dans un article antérieur. L'idée sous-jacente développée vise à équilibrer la durée du projet et la taille de l'équipe qui doit réaliser le travail.

Dans le secteur informatique, et plus particulièrement dans la gestion de projets "logiciels", le span de contrôle est de 5 ou 6. Cela veut donc dire qu'un chef de projet est capable de superviser 5 à 6 personnes de manière directe.

Voyons cela à l'aide d'un exemple! Nous avons donc un effort de 332,5 jours à superviser. Equilibrer durée de la mission et taille de l'équipe, sur une base de 20 jours de travail par mois, revient à effectuer le calcul suivant:

    Durée = Taille = SQRT( 332,5 / 20 ) = 4

… où

SQRT

Racine carrée

On se retrouve donc avec une équipe de 4 personnes travaillant pendant 4 mois. Comme le chef de projet devrait, en théorie, être capable de superviser en span direct de 5 à 6 personnes — disons 6 — cela veut donc dire qu'on a besoin d'un chef de projet à 67% de son temps (4 / 6 = 66.67%) et cela sur la durée du projet, c'est–à–dire 4 mois de 20 jours. Nous y voilà! Cela donne les chiffres suivants:

    PM = SQRT( E / T ) * ( SQRT( E / T ) / 6 ) * T

… où

T

Nombre de jours ouvrés par mois

c'est–à–dire

    PM = SQRT( 332,5 / 20 ) x  ( SQRT( 332,5 / 20 ) / 6 ) x 20 = 55,42 jours

Vous pouvez aussi préférer une approche de calcul relatif de l'effort de supervision de projet. En la matière, il n'est pas rare qu'on réserve 15% de l'effort calculé. Dans notre cas, cela donnerait:

    PM = 332,5 jours x 15% = 49,875 jours.

L'effort de contingence

Voilà l'intrusion de la partie forfaitaire. Vous devrez lui substituer toute valeur qui vous semblera appropriée à couvrir les incertitudes de votre projet. Pour l'exercice, et parce que c'est une valeur habituelle, nous vous proposons de partir sur une contingence de 20%.

    CTGY = ( ( 1,33 x ( 2,5 x 100 jours ) ) + DEPL + PM ) x 20% = 465.5 jours

L'effort de déploiement

Nous ne pouvons pas vous proposer la moindre alternative ici. Il faudra vraiment obtenir des estimations de déploiement pour vous permettre de proposer une estimation globale, ou, à défaut, de parler d'estimations hors effort de déploiement.

Et au final, cela donne?

Et bien, nous allons vous laisser le soin de calculer cela pour votre projet! Remplissez les zones et voyez le résultat. Étonnant, n'est-ce pas?

Effort de programmation:
Effort d'analyse (optionnel)
Effort de testing (optionnel):
Jours de travail en un mois:
% contingence:
Déploiement :
Date de début (jj/mm/aaaa):
Prix (€/jour):

Bien sûr…

Bien sûr, ne prenez pas appui sur ce calcul pour vous éviter d'évaluer le plus précisément possible l'effort global requis par un projet. Nous vous encourageons à être critique ! Cet article vous propose une évaluation grossière qui vaut de base de comparaison, c'est tout !