Le jour homme
Chaque équipe de développeur est composée de différents profils. Vous voyez une équipe de foot ? Et bien une équipe de développement c’est pareil. Il y a celui qui abat le travail comme un bucheron, celui qui a des idées ou celui qui est fort en Web. Or il nous arrive encore de rencontrer des responsables de projets informatiques, qui ne perçoivent pas cet écart de performance et de capacité entre développeurs.
Il y a quelques années, je me souviens avoir discuté avec un chef de projet qui pensait que les développeurs étaient tous identiques, avec une capacité à produire du code facilement calculable dans Excel. La discussion était partie d’un tableau Excel justement. Il essayait de prédire, je dis bien prédire, la répartition de charge et de déterminer la date de fin de projet. Alors qu’il remplissait son tableau, je le voyais diviser des tâches entre développeur. Une tâche estimée à 8 jours passait ainsi à 4 jours s’il mettait 2 développeurs…
Grave erreur. S’il faut 9 mois à une femme pour faire un bébé, 9 femmes ne font pas un bébé en 1 mois (la phrase est de 1975, de Frederick Brooks, tirée du livre The mythical Man-Month).
Après discussion il a admit qu’il était très difficile de prédire quoique ce soit. Et nous avons travaillé à plusieurs pour réussir à faire un planning prévisionnel.
Prévoir et prédire
En fait si vous acceptez qu’il est impossible de prédire, vous avancerez et vous serez en mesure de chercher un autre moyen. Prévoir et prédire sont deux verbes différents. Il est possible de prévoir un budget, il est possible de prévoir le départ ou l’arrivée d’un développeur. Il est certainement important de prévoir la date de sortie de votre logiciel. Mais ensuite, la réalisation reste pour moi de la prédiction. Un planning détaillé de développement, que vous avez précieusement et difficilement mis à jour, n’est pas suffisant pour prédire correctement la fin d’un projet, dans le temps imparti, avec les fonctions demandées et en respectant un budget.
Il est évident qu’il est impossible de prédire le futur, et le problème se pose lorsque le responsable d’un projet confond prédiction et prévision.
Je vous prédis un bel avenir, je prévois que vous allez bien galérer avant d’y arriver.
(ce billet date en fait de septembre 2010)
0 no like
Bonjour,
Je pense qu’il y a une petite coquille dans votre article, bien que très intéressant.
Il me semble qu’on ne parle pas de jour/homme (lire « jour par homme ») qui consisterait alors à déterminer, pour chaque homme le nombre de jours qu’il va travailler (Jean 4 jours, Lise 2 jours).
On parle plutôt de jour.homme (« jour homme », avec un signe de multiplication et non de division) qui définit le nombre de jours qu’un projet nécessite pour être mené à terme. En divisant par « homme », on obtient le nombre de jours calendaires. 12 jours.homme divisé par 3 hommes = projet livré dans 4 jours.
Voilà, arrêtez-moi si je me trompe !
Bonne continuation.
@Olivier : j’ai corrigé le titre afin de lever la confusion. Merci.
Petite erreur d’orthographe dans l’avant-dernier paragraphe: « […], le problème se pose lorsque le responsable […] ».
Sinon je suis 100% d’accord avec toi. Je trouve détestable lorsqu’un chef de projet parle de ressource pour parler d’un développeur, et qu’il se permet selon son planning de la placer sur des composants divers et variés sans prendre en compte son background. J’ai aussi souvent vu que pour une tâche donnée, c’est un développeur différent de celui qui l’a estimée qui fait l’implémentation, ce que je trouve totalement illogique, ne serait-ce que parce que le second développeur doit refaire tout le travail de lecture et compréhension de la tâche…
J’aime bien ton analogie à une équipe de foot, je vais essayer de l’utiliser pour faire réfléchir mon chef de projet actuel 😉
Hum… Dans le cadre de nos projets aux forfait, nous arrivons (quasiment) toujours à *prevoir* la date de livraison. Il suffit comme tu l’as dis de tenir compte de qui va développer quoi et dans quel ordre, de prendre des marges de sécurités liées à la difficulté et de rester réaliste.
Celui qui évalue doit avoir un très bon background technique, connaître les membres de l’équipe et la réactivité du client. Rien d’impossible quand on fait pas un projet de 10M€ à 50.
C’est sûr que sur un très gros projet, ou seul un CP ou un DP (pas technique pour un sou) se charge du planning, c’est vraiment du temps perdu, si ce n’est pour remplir des slides avec des zolis diagrammes.
@Reynald
Je ne suis pas d’accord, quelqu’un peut évaluer alors que d’autres réalisent. Il faut juste que la-dite personne tienne compte des paramètres que j’ai cité plus haut. Et d’ailleurs, heureusement que c’est comme ça, sinon, faudrait évaluer à 10 en même temps pour un projet d’une certaine taille.
@ Waddle
Je me suis mal exprimé dans mon précédent commentaire. Effectivement, si on prend en compte lors de l’estimation que ça sera un autre développeur qui va réaliser la tâche, et qu’on adapte le temps imparti en fonction, alors ça me convient parfaitement. Là ou ça ne joue pas, c’est quand on ne prend pas en compte les spécificités des personnes. C’est finalement un cas assez rare qui se produit, je crois que j’ai légèrement exagéré ça dans mon premier commentaire 😉
Evaluer les tâches à 10 personnes? Pourquoi pas, ça me semble familier à du scrum, je pense que ça peux avoir du bon dans des projets d’une certaine taille.
Pour être en pleine lecture du vénérable ouvrage de Fred Brooks (The Mythical Man-Month), je peux préciser que la phrase d’origine de Brooks est sensiblement différente de celle qu’en donne Nicolas (j’ai moi-même longtemps fait la même erreur) :
«Faire un enfant prend neuf mois, quel que soit le nombre de femmes qu’on affecte à cette tâche.» («The bearing of a child takes nine months, no matter how many women are assigned.», p.17 de l’édition anglaise de 1995)
Le sens de cette phrase est, il me semble, très différent de la phrase que donne Nicolas. Parce que la phrase de Nicolas pourrait laisser penser que si 9 femmes ne peuvent pas faire un enfant en un mois, c’est bien le diable si elles ne peuvent pas le faire en 2 ou 3 mois (allez, 4, à tout casser). 2, 3 ou 4 mois, ce n’est peut-être pas 1/9ème de 9 mois, mais c’est quand même nettement moins que 9 mois.
Ce raisonnement paraît évidemment absurde dans le cas des femmes et des enfants. Il est pourtant extrêmement courant chez les managers lorsqu’il s’agit d’évaluer l’avancement d’un projet (en jours-hommes).
Le fond de la pensée de Brooks lorsqu’il écrit cette phrase (il la développe sur tout le chapitre 2, «The Man-Month», de son livre) est qu’utiliser le jour-homme, qui est une unité de coût, n’a absolument aucun sens lorsqu’il s’agit d’évaluer l’avancement d’une tâche ou d’un projet. Ce n’est pas juste que cette unité peut induire en erreur. Brooks va beaucoup plus loin : il dit bien que l’utiliser n’a absolument aucun sens. Il n’y a aucune équivalence entre nombre de personnes et temps passé.
Si je reprends les termes mêmes de Brooks (page 16 de la même édition, traduction de votre serviteur) :
«Le coût varie effectivement comme le produit du nombre d’hommes et du nombre de mois. Pas l’avancement d’une tâche ou d’un projet. Par conséquent, le mois-homme comme unité pour mesure la quantité de travail est un mythe à la fois dangereux et trompeur. Il laisse entendre qu’hommes et mois sont interchangeables.» («Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.»)
Et Brooks, ici, ne prend même pas en compte le fait que deux développeurs puissent avoir des productivités différentes sur tel ou tel type de tâche. Non : il prend juste en compte le fait que la communication entre membres de l’équipe est un poste-clé du temps consommé par les développeurs, et que, dans une équipe où les développeurs sont des pairs (ce qui, en pratique, est le cas sur, pour ainsi dire, tous les projets informatiques), ce temps de communication augmente avec le carré du nombre de développeurs.
Je précise d’ailleurs que Brooks mentionne aussi dans son livre The Mythical Man-Month que les développeurs n’ont pas tous la même productivité. Mais plus loin, au début du chapitre 3 (p.30 de la même édition). Il y mentionne même le fait que, d’après les études sur le sujet, la productivité entre développeurs varie d’un facteur 1 à 10 entre les plus rapides et les plus lents, et que les données ne montrent absolument aucune corrélation entre expérience (ou salaire) et performance…
@HollyDays : merci Olivier, excellent complément, et qui donne envie d’aller lire rapidement ce livre.