Pouvons-nous mettre un terme à ce jeu de dupes "d'estimations" ?

SCRUM est là pour offrir une correction prédictive appelée "vélocité". C'est un facteur mesuré de relation entre difficulté et temps. On ne devrait plus lire des choses pareil : on devrait lire des articles du genre "Comment faire adopter la gestion des délais en Agilité par le management".

Sauf que la vélocité représente le nombre d’heures qu’est capable de traiter une équipe. Cette information permet de de savoir combien de fonctionnalités pourront être produites au prochain sprint, ce n’est en aucun cas un indicateur permettant de faire des estimations, loin de là !

Pour faire des estimations fiables, il faudrait que l’équipe soit en mesure de connaitre le temps approximatif qu’elle met à faire un ensemble de fonctionnalités. A partir de ça on pourrait prédire la deadline en divisant la vélocité réelle de l’équipe par le nombre d’heures estimées.

Malheureusement, on ne peut faire des estimations de temps fiables que si une personne a déjà effectué le même type de tâche au moins une fois. Et quand je dis le même type de tâche, c’est dans les mêmes conditions avec la même technologie. Combien de temps faut-il pour changer le rétroviseur d’une DACIA ? Environ 20mn. Donc il faut 20 mn pour changer le rétroviseur d’une Audit ?
Les développeurs sont toujours confrontés à de nouveaux sujets qui exploitent de nouvelles technologies. C’est un domaine où par essence il est très difficile de savoir combien de temps mettront les choses pour la simple et bonne raison qu’on ne fait pas toujours la même chose !

Le seul moyen qui permet d’avoir un peu de prédictibilité sur un projet consiste à travailler en Kanban pendant plusieurs mois afin de mesurer le temps moyen que mettent les fonctionnalités à traverser le pipeline de production. A partir de là, on peut éventuellement faire des projections en fonction du nombre de fonctionnalités prévues et de leurs poids respectifs, mais une fois de plus, la perdition n’est pas une date à la seconde près !

Les estimations doivent être des outils d’aide à la décision, et non des promesses, la loi des contraintes explique très clairement que les méthodes de planification traditionnelles ignores les capacités en déterminant le jalonnement des opérations ce qui donne évidemment des résultats étonnés.
Donc je suis plutôt d’accord avec l’auteur : NO ESTIMATES !

Je suis manager et j'aimerai quand même rappeler aux chers developpeurs contributeurs que l'argent ne tombe pas des arbres et que leur salaire est financé par les logiciels qu'ils livrent aux clients de leur employeur (sauf les start up qui trouvent des investisseurs qui financent des salaires alors qu'il n'y a pas encore de clients...).
Je pense que ce premier axiome sera accepté pas tous.

Viens ensuite le second axiome : le client qui va payer les salaires a besoin d'un delais de livraison. Ce client passe son temps a acheter des choses pour lesquelles ont lui prédit un delais de livraison : il sait que faire ses courses la samedi lui prendra plus temps qu'en semaine mais il sait que, s'il part faire ses courses hebdomadaires a 14h, il rentrera chez lui avant 23h. Il sait que s'il va chez son boulanger acheter du pain a 9h le dimanche il n'aura pas a attendre plus de 15mn (car on fait un peu la queue dans cette bonne boulangerie ) mais il sait aussi que s'il veut un gâteau d'anniversaire il doit le commander 3 jours avant et que, sous cette condition, il lui sera livré a temps.
Lorsque vous achetez une voiture neuve, sa construction est commencée au moment de commande et vous devez attendre plusieurs semaines ou plusieurs mois mais elle est livrée a temps.
Lorsque vous prennes le train ou l'avions et qu'il est retard vous êtes en colère (mais moins lorsqu'il s'agit d'un mort sur les voix que lorsque c'est a cause d'une grève).
Maintenant que je vous ait bien immergié dans le quotidien des clients qui paiements vos salaires... Vous admettrez j'espère qu'en tant que manager je ne peux admettre qu'un membre de mon équipe se refuse a toute tentative d'estimation.

Je peux entendre que c'est un exercice complexe, je peux entendre qu'à court terme il ne sera pas fiable, que si les équipes changent il le sera encore moins, que ceci, que cela MAIS faire de l'estimation est, pour moi une des missions d'une équipe de développement.
Le developpeur refactorise : l admet donc que :
- ce qu'il fait en première itération, même imparfait, a de la valeur
- ce qui motive la refactorisation est qu'il peut faire mieux, fort de sa première expérience
Pourquoi n'en serait il pas de même pour la qualité des estimations ?

Pourquoi mes premières estimations étaient fausses ?
- parce que j'avais la pression du management -> pour mieux estimer expliquons au management ce que leur intervention implique
- parce qu'on ne l'a jamais fais -> mais ne le refondra t on jamais ? Organisons donc la mémoire des projets.
- parce qu'on ne refais jamais la même chose -> même si les techno changent l'existence même du concept de refactorisation de code, de programmation orientée objet avec héritage,de librairies... Prouve qe cet argument est emprunt d'une dose non négligeable de mauvaise foi ;-)
- parce qu'on demande aux jeunes de faire aussi bien que les seniors -> quel est le con qui peut exiger ça ? Il doit exister mais cette expérience doit tout au plus inciter le developpeur a changer d'employeur mais ne justifie pas que l'estimation est impossible.

Se challenger pour faire mieux et progresser est passionnant : mieux coder peut y contribuer, mieux estimer aussi.

Aurélien,

On est d'accord, dans l'ensemble. Mais tant que tu n'est pas rentré dans des cycles permettant de comparer le temps estimé et le temps effectif passé pour réaliser un ensemble de fonctionnalités, alors tu n'as aucun moyen de connaitre ta capacité réelle, qui est appelée vélocité en AGILE.

En ce sens, il est évident qu'une estimation en jours-homme sur des années n'a que peu de sens : or, c'est précisément de cela dont parle l'article - c'est à dire les classiques estimations en jours homme divisée par le nombre de personne dans l'équipe pour planifier l'année entière, ce qui n'a aucune réalité pratique, mais qui est pourtant prise par le management comme un engagement ferme.

Et je suis complètement d'accord avec toi : quand bien même ce n'est pas un chef qui estime tout, mais les personnes qui vont développer les fonctionnalités, l'estimation en temps (et non en points de difficulté), ne doit être qu'un outil d'aide à la décision, juste pour savoir "ou on va à peu prêt", avec un taux d'erreur qui reste très important - mais toutefois bien inférieur à une estimation au doigt levé.

Ce qui motive ma réflexion, c'est que toute la difficulté est justement que le management a d'autres contraintes, des contraintes bien plus "dures" comme l'explique Alain. Les contraintes du management c'est le compte en banque de l'entreprise (sa solvabilité), la loi (se confronter à la loi sur les engagements, le bilan), le marché, alors que les contraintes du développeurs, c'est le bug, la qualité, les technos logicielles, prendre du skill, coder des heures, bref des limites physiques des hommes et du software. Ils ne parlent pas la même langue (encore et toujours) :
- l'un parle financier et légale (loi sur la faillite et normes comptables)
- l'autre qualité, gestion des hommes, production et technique.

Sur le plan temporel :
- d'un coté l'entreprise doit payer des salaires à une datte fixe (c'est le gros des dépenses), et doit livrer ses clients à une date prévisible, car pour être payer, faut livrer.
- de l'autre, on a des développeurs qui doivent respecter ces contraintes - du moins, tout faire pour les respecter : et c'est là que se joue le drame.

En développement, on se rends compte que respecter des délais, c'est difficile, et c'est d'autant plus difficile quand la livraison est dans 3 ans. L'article présent le dit assez clairement.

D'ou l'invention d'AGILE. En gros, on remplace le prédictif par de l'itératif et de l'empirique. Dans ce cadre, je trouve qu'avoir une vélocité stable, cela veut dire "je connais mon équipe, je sais de quoi elle est capable". Donc s'engager sur un périmètre, c'est connaitre sa vélocité... pour les deux semaines à venir + une petite marge d'erreur. Car tu peux faire de l'itératif sans vélocité : ce que tu fais, c'est que tu pleur toutes les 2 semaine en constatant que tu es systématiquement en retard...

Je résumes : "on avait mis 150 points de difficulté dans ce sprint. On en a réalisé 110. La prochaine fois, avec la même estimation en terme de point de difficulté, vous ne vous engagerez que sur 110 points. En avec le temps, on sera de plus en plus fiables sur nos estimations, et les variation de la vélocité de l'équipe seront le reflet de ses changements propres : meilleur skill, nouveaux devs, bugs, etc."

Qu'on rende le temps fixe (sprint de 2 semaines par exemple) et qu'on module par le périmètre, ou qu'on détermine un délais variable en fonction d'un périmètre, cela revient en apparence au même : dans les deux cas, il faut un moyen de savoir combien de points de difficulté on traite en combien de temps. La vélocité est une forme de productivité qui ne peut être qu'empirique, non prédictive et variable dans le temps (c'est la même chose en économie). C'est pour cela que faire une estimation pour livrer un logiciel dans 2 ans, cela n'a aucun sens pratique : la vélocité aura changée (l'équipe, les bug, la taille du code, les technos), les besoins auront changés, les clients aurons changés.

Les méthodes AGILE montrent simplement que rendre le développement itératif et le délais fixe (N semaines par itération) et jouer sur le périmètre invite à un processus d'avantage maîtrisable et pragmatique dans le cadre du développement logiciel - précisément ce que l'article démontre qu'il n'a pas en faisant des estimations globales !

C'est en cela que j'interpelle franchement dans mon commentaire, car cet article fait bien référence à des gestions de projet en V, planifiées sur des mois ou des années.

D'ou ma réflexion : "Comment faire adopter la gestion des délais en Agilité par le management ?". Car cet article ne parles pas de développement, il parle de management. Une estimation est un acte de management.

Dans l'équipe qui passe à SCRUM, là ou j'ai mon bureau, la difficulté qu'ils rencontrent est plus lié au management qui a du mal à se faire à l'idée de n'avoir pas un délais pour un produit donné, avec un périmètre donné, mais seulement comme information exploitable une capacité de l'équipe à livrer un certain nombre de points de difficulté abstraits toutes les 2 semaines, et qu'en plus cette capacité évolue.

Car au bout d'une semaine, la direction à chercher à contourner la méthode, et à demander des estimations, fonctionnalités, objectifs incohérents, à avoir une garantie sur des délais dans 6 mois, à négocier les délais, à dire "ca ce fait en deux fois moins de temps, ça..." etc. Bref, la direction a du mal a se dire : "Ok, je défini des fonctionnalités, les devs évaluent en points de difficulté, ensuite je trie mes US, puis je constitue le Backlog du Sprint en fonction de la vélocité, et j'aurais une démo a la fin qui me permettra de redéfinir les priorités..." - C'est irrationnel pour le développeur, mais c'est rationnel pour la direction, car la direction a des échéances fixes, des murs en béton.

Donc de mon point de vue, l'article montre très bien le problème : le problème est une inadéquation entre la nécessité d'avoir des délais coté direction, et l'incapacité à en fournir coté développement. Je penses qu'on peut aussi exprimer les choses de cette façon : il s'agit, pour le management (la direction), de s'adapter à la vélocité de son équipe de développement, ce qui implique de totalement changer d'attitude, et fournir un travail sur le backlog qui sort très largement de ses habitudes.

Voila, pour préciser ma pensé.

Je vais essayer d’être bref.

Lorsque l’on part sur un projet à RISQUE, dont le déroulement est incertain, on fixe le cout et les délais, puis on discute des possibilités en fonction des résultats obtenus. A partir de là, on peut effectivement demander des projections basées sur l’expérience acquise à partir du moment où cette information sera utilisée comme un élément permettant de décider si oui ou non ont réinvesti des ressources sur le projet.

Si l’on fait le contraire, c’est-à-dire fixer le périmètre et rendre variable cout et délai (c’est bien à sa que servent les estimations non ?), on est comme un joueur de casino qui pense éternellement qu’il pourra se refaire. Toute demande d’estimation dans ce cas n’est qu’un moyen psychologique d’atteindre un but utopique qui ne mène qu’à une chose : Mettre en danger soi-même et les autres.

Aller chercher son pain, commander une voiture, prendre le train, l’avion ou faire un petit logiciel ne sont pas des projets à risque. Dans ces cas, raisonner en fonction d’un périmètre fixe pour aller demander du fric au banquier est tout à fait légitime.

Jouer au loto, investir dans des actions, innover dans un domaine ou créer un logiciel dont le périmètre est très conséquent sont des projets à risque.

La sagesse veut dans ces cas que l’on s’astreigne à se fixer des limites, et à raisonner de façon empirique.
Après, chacun gère ses projets comme il l’entend.

J'insiste : de quoi parle-t-on ?
Je réagissais à un article qui explique qu'un développeur NE PEUT PAS, donc NE DOIT PAS estimer.
Ta réponse traite d’une sous partie de ce vaste sujet : l’estimation d'un projet à risque au début de ce dernier.
Je suis d'accord pour admettre que certains aspects d'un projet sont techniquement impossibles à estimer.
J'espère que tout le monde admettra que certaines autres peuvent l'être.
J'espère que tout le monde admettra aussi que si tout pouvait être estimé gratuitement avec une parfaite justesse (et mieux, si on pouvait lire l'avenir), le management responsable de la stratégie et du financement ne s'en porterait pas plus mal.
Le problème posé dans notre échange est que l'estimation a un coût et que plus cette estimation doit être fiable plus elle coute cher (au point que dans certains cas l’estimation fiable coute l’infini –c’est elle que l’on qualifie d’impossible ;-)
Où se trouve l'intersection entre les courbes de coût et de fiabilité d'une estimation ?
Répondre "a priori" à cette question, sans savoir de quel projet on parle, de quelle partie du sous projet on parle, de quelle tâche on parle... est une erreur.
La réponse n'est pas toujours la même : rien que cet état de fait impose de faire une estimation, même grossière.
En tant que manager :
- s'accepte l'idée selon laquelle l'évaluation est difficile.
- je n'accepte pas en revanche que le développeur décrète que rien n'est estimable et qu'il s'agit d'un sujet sans intérêt, ce qui me semblait être le sujet de l'article.
L'important est le dialogue entre les deux pour trouver le compromis.
- la manager qui exige de respecter les estimations des seniors par les junior fait une erreur car il coupe le dialogue
- le développeur qui prétend que rien n'est estimable et qu'il est sans intérêt de s'intéresser à cette question fait lui aussi une erreur en coupant lui aussi le dialogue.
N'oublions pas que dans le génie logiciel, si la ressource est une constate (et cette dernière étant la plus complexe, elle n'est en aucun cas une variable d'ajustement) le délai est très généralement intimement lié coût.
Normalement une équipe Agile m'explique "notre responsabilité c'est la qualité du développement sur le plan technique, ta responsabilité est de nous dire ce qu'on doit faire. A la rigueur si tu veux qu'on peigne la girafe, on le fera (ce qu'on te garantit c'est qu'on le fera bien)".
En tant qu'acheteur de qualité, si j'ai plusieurs choses (de qualité) à acheter, je vais devoir faire un choix (en priorisant). Dites-moi alors comment je peux faire ça si on ne me donne pas au moins une estimation "relatives" entre les choses que j'ai à acheter ?
Le but d'un développeur c'est de faire du code "propre maintenable" ou du code "déployée vendable" ?
Si personne n'est là pour rappeler qu'un logiciel doit être déployé "à un moment ou à un autre" bon nombre de développeurs pourraient se complaire dans le code "propre maintenable, non déployé et non vendu" (et après tout je ne les en blâme pas car leur cerveau reptilien sait que dès qu'on va déployer c'est là que les problèmes vont réellement commencer ;-)
Rien qu'à cause de ce biais psychologique, la pression des délais et des coûts, maintenue par le management est évidement nécessaire.

Je ne suis pas d'accord avec la phrase bon nombre de développeurs pourraient se complaire dans le code "propre maintenable, non déployé et non vendu". Il est malheureusement fréquent que des projets tombent à l'eau, ou soient complètement refondus avant même la première utilisation, et cela entraîne beaucoup de frustration pour les développeurs. Pourtant, même si le produit n'est pas utilisé, après tout les développeurs sont payés, et comme ils ne sont pas utilisateurs, cela ne change rien à leur vie. Cependant, quand on bichonne un produit, une interface, qu'on fait des efforts pour avoir un code maintenable... on aime que ça serve à quelque chose. Donc c'est peu probable que les développeurs se complaisent dans un code non déployé et non vendu.

Le problème de l'estimation, c'est qu'elle est considérée très vite comme un engagement, alors qu'elle devrait rester au stade de l'indication...

J'ai dit "bon nombre", pas "tous les développeurs" ;-)

"Le problème de l'estimation, c'est qu'elle est considérée très vite comme un engagement, alors qu'elle devrait rester au stade de l'indication... " : là on commence à être d'accord ;-)

Tout est dit.

je confirme, le tour est fait :)