Bonjour les gens,
Pensez-vous les estimations de projet utiles ou bien êtes vous plutôt un partisan du « no-estimate » ?
Dans quels contextes les estimations peuvent-être utiles et d’autres pas ?
Comment réalisez-vous vos estimations ?
Avec une équipe, je suis passé un Poker Planning classique, sauf qu’on faisait des moyennes à la Uncle Bob plutôt qu’un consensus mou pour gagner du temps, à un Poker Planning hyper simple : 1, Infini, ?.
En gros, de faire une abstraction basé sur une sorte de SLE : si notre ticket faisait moins de 10 jours, on vote 1.
Quand on fait du NoEstimate, l’effort le plus important est ciblé sur la fonctionnalité la plus importante, de la découper, et de l’attaquer direct. De l’affiner, quoi.
Le soucis de l’estimation, c’est le grossissement du Backlog : on va estimer et on le place dans le Backlog et on verra bien un jour si on le fera. Sauf que YAGNI : You Ain’t Gonna Need It !
J’ai rien contre l’estimation, si c’est :
- très court
- collaboratif et fait par celles et ceux qui font
- que ce soit fait quand il y a besoin réellement
EDIT : le « que ce soit fait quand il y a réellement besoin », ça vaut pour le « Compliqué » ou le « Clair » de Cynefin. Quand c’est complexe, ça n’a pas de sens d’estimer, ou tout du moins l’erreur va être tellement grande que l’estimation n’a donc plus de sens…
3 « J'aime »
Actuellement je prends l’illustration d’Amazon vs Kickstarter (ou e-commerce vs projet à financement participatif). Quand on achète quelque chose sur un site internet, on nous communique une estimation du délai de livraison. S’il s’agit d’un site e-commerce bien rôdé et un article commun, on peut s’attendre à un délai court, précis et majoritairement respecté. A l’inverse, s’il s’agit d’un projet à financement participatif qui n’a jamais été réalisé, c’est normal de voir des délais de plusieurs mois voire années. L’estimation est floue et pas toujours respectée.
L’inverse serait complètement débile, non ?
Alors, le sujet est-ce plutôt Amazon ou Kickstarter ? Je m’appuie sur Cynefin pour m’aider à répondre à cette question :
- Si le sujet est complexe alors l’estimation n’a pas de sens.
- Si le sujet est clair il faut estimer en s’appuyant sur le passé.
Liz Keogh offre une échelle rapide pour d’abord estimer la complexité du sujet sur la base de 5 affirmations possibles : Estimating Complexity | Liz Keogh, lunivore
Sur le comment estimer, il est important de s’appuyer sur le passé, de vérifier continuellement que le contexte présent est représentatif des situations passées et faire des backtests.
Victor Lambret a fait une présentation très intéressante sur le sujet à Touraine Tech 2024. La vidéo n’est pas encore publiée.
4 « J'aime »
Je suis partisan du « il n’est humainement pas possible de ne pas estimer »
Par contre, il est possible de ne pas prendre compte des estimations ou de ne pas les communiquer hors de l’équipe.
L’important, c’est ce qu’on fait des estimations quand on les utilise. Et comment on les utilise. (C’est pareil avec SAFe, Scrum, l’énergie atomique, les métaphores ou les statistiques… )
J’aime les utiliser, mais avec une vigilance sur 2 points.
1 - Une estimation, c’est imprécis par nature. Donc toute discussion pour essayer d’être plus précis va suivre une courbe du genre ‹ 2x plus de temps, pour une précision à 1/2 plus précise ›
==> attention ce point est contradictoire avec une des activités les plus riches de la session d’estimation => provoquer la discussion qui va aligner l’équipe sur ce qu’on peut imaginer, faire et livrer, que le tout soit cohérent.
2 - On veut « chiffrer » l’estimation pour faire des « calculs », ça laisse des traces, ces « sommes » qui n’ont pas de sens. Et ces sommes, ces « nombres » sont souvent « vus » par des externes à l’équipe… et qui perçoivent ces chiffres comme des vérités, des promesses, ou des « indicateurs » précis. Ça les transforme en vanity kpi.
Une règle simple pour ca, les estimations appartiennent à l’équipe qui les fait.
Ce sont des estimations relatives à la perception des membres de l’équipe. Il n’y a pas d’unité (pas des heures, pas des calories,…)
Toute modification de l’équipe (même l’ajout ou le retrait d’un membre effectif) annihile l’échelle d’estimation. Il faut tout recommencer (ça s’établit vite en 3-4 sprint, j’avais des estimations cohérentes). Et donc, si c’est déjà comme ça avec un membre de l’équipe, c’est encore pire si un externe entre dans le cercle de perception de l’estimation.
2 « J'aime »
Ce qui me chagrine avec cette réponse, @Moosh, est que tu préconises une stratégie unique à appliquer partout et ainsi elle a le risque d’être adaptée nulle part.
Bonjour,
Effectivement ca dépend du contexte et du but recherché.
Si je prend le contexte d’une ESN, on va avoir différent modèles en fonction du contrat (je crois qu’il y avait un post sur ce sujet dans le forum).
Actuellement je fais des estimations en points sur tous les PBI que ca soit des évolutions ou anomalies. J’utilise ces points pour estimer la capacité. Cette capacité est grosse maille et est ajustable avec le client en fonction du contexte, le but recherché n’étant pas de mettre l’équipe sous l’eau mais bien qu’on arrive a produire de la manière la plus optimale en maximisant la valeur. Ces points servent aussi à la facturation pour les évolutions et pour les anomalies on va être sur un nombre de ticket ou de points « idéal » mais rien de figé encore pour répondre au besoin du produit avant tout.
Si j’avais le choix je partirai sur des estimations en point sur les évolutions et sur du no estimate pour les anomalies.
Car l’estimation en point est rapide et provoque le débat.
Car le temps passé à l’analyse d’une anomalie correspond à la majeure partie du temps pour la corriger.
La question importante à laquelle il faut revenir :
Les estimations, est-ce utile au développement / aux développeurs ?
Posez la question à vos développeurs, ils répondront tous la même chose.
Si on leur donne le pouvoir, c’est probablement le premier truc qu’ils voudront enlever.
Tous les développeurs vous expliqueront que ça ne les aide absolument pas à développer, au contraire. Ils se sentent fliqués, mis en compétition, et souvent leur évaluation de « performance » s’appuie sur leur capacité à estimer ou à respecter ces estimations plutôt que sur leur compétences techniques.
Les experts du domaine vous diront qu’une « bonne » estimation c’est quand le coût réel se situe dans une fourchette un rateau [estimation / 4 ; estimation x 4]. Donc si un expert estime un développement à 40 jours, la réalité se situe « probablement » entre 10 et 160 jours. Je ne sais pas pour vous, mais pour moi cette information n’est pas assez précise pour avoir de la valeur.
A qui le crime profite-t-il vraiment ?
La plupart du temps, cette estimation sert à permettre à un tiers d’organiser le travail.
C’est donc le moyen numéro un pour priver l’équipe d’autonomie. En outre, cet outil est généralement utilisé pour occuper l’équipe parce qu’on a peur de la rupture de charge. On a beau chercher des stratagèmes fumeux pour « essayer de compter en points et pas en jours » afin d’éviter que le management s’ingère dans l’équipe, ça ne change rien parce que le mal est fait autrement, par des indicateurs qui « fonctionnent » même à un lambda près :
- estimation / coût réel
- Σ(estimations) < capacité
Bref, on est dans la culture du bourrage de sprint. Pourtant, il suffit que l’équipe entame un sujet subséquent si l’objectif initial est atteint avant la fin de sprint pour rendre toute cette culture caduque. Alors plutôt que de payer un mauvais chef de projet à les fliquer, on peut juste leur demander d’adopter cette attitude.
Par contre, ça nécessite de résoudre quelques points managériaux qui fâchent :
- « à quoi sert le management ? »
- reconnaissance réelle de la qualité du travail de développement
- comment on gagne de l’argent avec les fonctionnalités applicatives ?
L’estimation est un exercice fondamentalement éphémère
Une ligne de code déjà écrite n’a pas besoin d’être réécrite, il suffit de la référencer. Donc un développeur passe normalement son temps à écrire du code nouveau qui n’a jamais été écrit, dans un contexte qu’il n’a jamais connu. Il tombe, normalement, en permanence sur des cas de figure avec des problèmes qu’il n’a jamais rencontré et n’a donc pas pu complètement anticiper. Le développement permet donc d’apprendre des choses au fur et à mesure, et cela remet en permanence en question, non seulement les estimations, mais aussi potentiellement la solution à implémenter. On se retrouve donc potentiellement à comparer des pommes et des poires.
Pour estimer une charge de travail, le développeur fait des hypothèses. Or, la plupart du temps, estimer une charge de travail par rapport à des hypothèses est nettement plus long et compliqué que de vérifier lesdites hypothèses. C’est la raison fondamentale derrière la loi de Hofstadter.
La mauvaise solution adoptée per certains c’est d’estimer en permanence. Mais si vous demandez aux développeurs de mettre à jours les estimations tous les jours avant le daily vous pouvez installer des pièges à loup dans votre bureau : les développeurs sont très imaginatifs et il ne faudra pas longtemps pour qu’ils aient un envie de transformer votre diplôme PSM en poupée vaudou. En fait vous êtes juste revenu à un rôle de (mauvais) chef de projet.
Le problème de fond avec l’estimation, c’est qu’elle réfléchit à périmètre fixe.
Dans une organisation agile, on pense budget fixe et périmètre variable.
A mon sens l’erreur courante c’est qu’on cherche à estimer au niveau ticket/story/item.
Ce qu’il faut changer dans la mentalité c’est de partir du sprint et non pas de la fonctionnalité.
La magie doit s’opérer en commençant par le sprint planning. Bien sûr, il est nécessaire de faire un plan et d’imaginer une solution pour savoir par quel bout prendre le problème, par quelle action commencer, comment se répartir le travail. Mais trop d’organisations réfléchissent à faire rentrer des ronds dans des carrés en se demandant « combien à coûte ? » pour répondre en fait à la question « est-ce que ça rentre ? » ou « que peut-on faire ? ».
Ce n’est pas la bonne question à se poser.
L’approche agile consiste précisément à se lancer à corps perdu dans le sujet « pour voir » et pour apprendre. « Nous avons 10 jours pour faire un prototype de la fonctionnalité A ». On pose donc un premier jalon temporel, et on regarde ce qu’on a réussi à implémenter jusque là. C’est le rôle de la mêlée quotidienne :
« Nous sommes au jour 3 du sprint, voilà ce qu’on a produit pour l’instant, est-ce qu’on continue ? »
Attention, la question porte sur le quoi, pas sur le combien.
Est-ce utile dans certains cas ?
En revanche, les estimations sont des outils utiles dans certains cas.
Par exemple, en cas d’urgence du style incident bloquant. Dans ce cas, on va avoir besoin d’optimiser le temps de résolution. Il est donc important de se répartir efficacement les tâches pour aller vite. Dans ce cas de figure, revenir à une organisation top-down où on est capables de paralléliser et d’optimiser un chemin critique me semble une approche pertinente. Dans ce cas de figure, l’estimation de la durée des tâches est un outil utile à mon avis.
On peut aussi l’utiliser, mais par une estimation différentielle, pour trancher si on hésite entre plusieurs solutions : on veut savoir si la solution A nécessite plus d’effort que la solution B, pas combien de temps il faut pour l’une ou l’autre.
Je l’utilise aussi pour évaluer la qualité d’un backlog.
Je fais 4 colonnes et je classe les items entre :
- ~5j ou moins
- ~50j
- ~500j ou plus
- wtf ?
50 jours représente environ le travail de toute l’équipe pendant 1 sprint. S’il y a beaucoup de WTF, il y a probablement un problème de communication et de culture entre devs/PO. Ensuite le reste c’est une histoire de cycle de vie et de maturité du produit. En fonction de l’équilibre, on peut détecter un problème avec la posture du PO, ou remettre en question Scrum.
1 « J'aime »
Je ne préconise rien.
Je dis que « moi » je suis partisan des estimations.
Mais que je me méfie de leur détournement et je décris les 2 qui m’interpellent le plus.
Que je préfère qu’elles soit utilisées pour ce à quoi elles servent.
Estimer, qu’est-ce que c’est ?
Si on n’estime plus autant ne plus faire de sprint planning, demandons juste au PO « dit » tu vois quelle story pour ton backlog, donne moi ton et on verra bien (de toute façon on ne fera pas tout)
Je ne préconise rien.
Je constate que quand on utilise des chiffres on a envie de « calculer » et non « comparer »
1 « J'aime »
j’applique plutôt le principe exposé par @BenjaminF soit c’est assez petit pour dire que c’est une carte
et en gros, tant que l’on ne peut pas dire que c’est assez petit, on découpe pour arriver à cet étalon
le tout est de définir ce que veut dire assez petit, pour nous, c’est 5j entre le moment que tu tires la carte et elle est pair testée.
par contre, si les estimations servent à piloter l’avancement et estimer un atterrissage, juste découper ne suffit pas, la réponse quand on n’estime pas, c’est de mesurer, les temps, le débit pour devenir prédictible.
ce n’est jamais efficace à 100% mais quand tu utilises une courbe avec une vitesse à -10% de la vitesse moyenne et + 10% de la vitesse moyenne ça te donne une idée d’atterrissage, et jusque là, en 8 ans, c’est assez fiable
ça fait 8 ans que nous avons mis EazyBI en place sur JIRA pour ne pas faire les indicateurs à la main avec un export dans Excel ou travailler avec la base JIRA utilisée en PROD
le rapport que nous avons tunné est celui ci Project Prediction report - Issues - Jira Demo - eazyBI
il permet de calculer une date d’atterrissage en se basant sur le débit moyen de l’équipe
on peut du coup se projeter sur une version, sur une fonctionnalité sur tout type de regroupement
vous l’avez compris, le mot d’ordre est « arrêtez d’estimer, découpez et mesurez »
Cela fait un moment sans participation.
Mais vous suis et la dernière phrase me pousse à répondre oui à la comparaison type poker planning. J’aime le poker certe mais apprécié surtout l’idee du concept sans chiffre mais Valeurs.
Justement, je ne suis pas d’accord sur le « tous les développeurs » même si je peux entendre que ce soit le cas chez vous.
Quand les estimations restent dans le cercle fermé de l’équipe, non ils ne se sentent pas fliqués.
I’s ne se sentent pas en concurrence ils sont dans la même équipe.
L’équipe est stable, il n’y a pas de compétition interne.
On estime des User Story pas des tâches on estime pas en temps on estime pas en argent on estime un effort j’ai presque envie de dire qu’on estime aussi une charge mentale et c’est ça qu’il faut faire mettre à plat au sein des membres de l’équipe pour qu’il puisse s’aligner se comprendre et chercher la construction commune.
On ne gère pas un chantier on ne gère pas un projet on gère des gens des faiseurs des développeurs.
1 « J'aime »
Oh mince, je suis pas développeur ? :0
2 « J'aime »
Je vois dans la discussion que vous parlez régulièrement d’estimation.
De mon point de vue, je préfère parler d’évaluation. Voici pourquoi.
Les estimations concernent le sujet à estimer dans son propre périmètre ; on perd probablement l’aspect ‹ relatif › si cher à Scrum. Souvent les managers entendent jours ou heures et souvent c’est eux qui le demandent au grand damne de l’équipe qui ne s’en sert pas la plupart du temps.
Avez vous tenté de faire un état de vérité entre l’estimation et le réel ? sincèrement ?
Quand on évalue, on regarde le sujet ensemble avec les yeux de chacun et on évalue l’effort à fournir par rapport à un sujet ‹ étalon › ; soit c’est plus soit c’est moins. On utilise la suite de Fibonacci et ce qu’il y a de bien, c’est que cette évaluation n’est utilisée que par l’équipe ; elle se dit :
Voilà, on a l’habitude de réaliser n points, nous sommes au complet alors planifions notre sprint autour de n points ; ce ne sera pas toujours juste mais ce sera plus proche de la vraie vie.
De toute manière, dès que ça sort de l’équipe ils ne comprennent pas cette valorisation.
Autre point intéressant dans l’évaluation de l’effort c’est l’évaluation de la valeur commerciale de l’item, basée sur la même suite de Fibonacci.
Ainsi, en faisant le ratio valeur / effort, on a un indice qui permet de prioriser de telle sorte qu’il est préférable de faire les choses de grandes valeurs et de peu d’effort (une forme abrégée de " Weighted Shortest Job First").
S’il y a trop d’item de même « poids » alors ajouter le critère MoSCoW puis la matrice d’Eisenhower.
1 « J'aime »
Bonjour à tous,
Après avoir été un adepte des estimations, je suis devenu plutôt contre - on passe beaucoup de temps à faire des compte d’épiciers au détriment de cadrer et de découper
J’avais lu dans certaines études au niveau des estimations que l’être humain est mauvais pour estimer au delà de 3/4jours de travail
Du coup mon parti pris actuel est plus « DEVOPS » : on découpe en items pas plus gros que 3/4 jours et utile pour recevoir du feedback ( d’un utilisateur ou d’un équipier)
De quelques heures à 3 jours ( on s’en fiche de la précision si l’ordre de grandeur est respecté) c’est bon ça peut partir en réa sinon on doit passer plus de temps à cadrer/découper
Du coup on limite les risques, on gagne en dynamisme, en priorisation et les items ont des tailles similaires c’est utile pour exploiter les métrique Kanban
Voilà mon point de vu, découpage découpage c’est la clé
1 « J'aime »
@ArwynFr Je n’ai pas très bien compris ce paragraphe. Pourrais-tu clarifier ?
Comme tu le dis Agile consiste à avoir un périmètre Variable pour un Cout/Délais donné. (triangle de fer)
Les estimations ne permettent-elles pas d’aller dans ce sens. En estimant nous allons nous rendre compte que nous allons dépasser le budget si on implémente cette fonctionnalité par exemple. Ainsi nous avons bien un périmètre variable (e.g. ne pas faire cette fonctionnalité) car nous avons un budget fixe.
L’estimation va donc dans le sens d’un périmètre variable, en choisissant quelles fonctionnalités faire en fonction de leur coût ?
Le seul problème que je vois avec ceci c’est la notion de valeur, Agile vise la valeur hors avec mes dires on élimine une tâche car elle coute trop cher et non car elle n’apporte pas de valeur
Pour estimer les charges de travail, il faut au préalable être d’accord sur les tâches à estimer. C’est pour cette raison que, dans une approche traditionnelle, on commence par lister exhaustivement les tâches à accomplir (conception, spécification), et en estimer la charge. Cela s’appelle une proposition. Ensuite on va avoir une phase de négociation par rapport au budget disponible. Mais à un moment, on décide d’un engagement qui associe un coût/délai (le budget) et un lot de tâches à accomplir (le périmètre).
A partir de là, budget et périmètre sont fixes. On attend du développeur qu’il se conforme au plan qui a été établi au départ. S’il y a un changement, alors il est légitime d’interroger l’estimation puisqu’on ne va pas faire certaines tâches et qu’on va leur en substituer d’autre, sans garantie que les complexités soient équivalentes. Donc, on repart sur un tour de table pour négocier un nouveau périmètre / budget.
Mais négocier le périmètre n’est pas ce qu’on appelle un fonctionnement à périmètre variable.
Dans une approche agile/scrum, on fonctionne différemment : on démarre le sprint avec un objectif et un budget fixe (la capacité de travail de l’équipe). Partant de là, si à un moment on se rend compte qu’on doit faire les choses différemment de ce qui était prévu, bah on enlève des tâches et on en rajoute, à loisir. Ca ne change pas la durée du sprint, ni l’objectif de départ. A la fin du sprint, on regarde ce qu’on a fait et si ça fonctionne ou pas. Au final, les tâches réalisées peuvent être très différentes de ce qui était convenu au départ (périmètre variable), mais on a gardé la durée du sprint (budget fixe).