Points
On demande de justifier des ecarts entre les jh constatés et ceux estimés. Pas dans le cas des points. Les jh sont pris comme un engagement et pas comme une estimation.

pierre-grigoletto

013

j.h
Je n'aime pas le Jour.Homme mais c'est une unité de mesure qui parle facilement aux gens.

C'est comme dire "je suis à 20 minutes de Lyon". On utilise une unité de temps pour qualifier de la distance... Physiquement, ça n'a aucun sens mais par abus de langage, tout le monde comprend ce que cela veut dire.

Donc définitivement J.H même si j'aurai préféré parler en points.

a-nary

29

Points
Points ou jours, ce n'est pas tant ça la question que d'utiliser des temps idéaux_ et surtout une _vélocité pour faire le lien entre point/temps idéal et temps réel.

Le point essentiel : la vélocité est mesurée, factuelle, simplement une mesure du volume de travail accompli lors de chaque sprint précédent, on va ensuite faire la moyenne sur N sprints pour rendre cette vélocité d'autant plus faible.

La vélocité a aussi cette vertu de simplement indiquer la vitesse réelle à laquelle on avance. On n'est jamais trop lent : c'est notre vitesse, voilà tout. Il faut faire face à la réalité et assumer. On peut peut-être l'améliorer avec des actions de fond (passer au TDD, automatiser le processus de build) mais on ne pourra jamais magiquement aller à une autre vitesse que la vitesse nécessaire pour faire les choses. Pour bien faire les choses.

Pour revenir au débat d'origine : bien entendu les points, car étant plus "abstrait" que le temps (même idéal) cette unité pour estimer force plus naturellement à estimer en relatif plutôt qu'en décomposant le travail à faire et en se projetant. Aussi justement parce que de manipuler des unités qui ne parlent pas de temps rappelle à tout le monde la nécessité d'utiliser la vélocité pour avoir le temps réel.

Je conclurai en parlant de CURSE : les points ne sont pas juste de la complexité... Mais tout un tas d'éléments qu'on aggrège : Complexity Uncertainty Risk Scope Effort

jplambert

19

j.h
Pour ma part, je préfère -et de loin- les J.H. Dans notre métier, le concept de livraison et de deadline est tout de même primordial, et savoir ou l'on se situe dans le temps (parce que tout est question de temps), est une mesure concrète et utile (si l'on part du principe que l'on livre de la qualité, et qu'on ne transige pas sur le code au profit du temps). Tous les acteurs d'un projet savent compter en jour, pas forcément en complexité.

Il y a deux utilités aux estimations : prioriser les features (choisir ce que l'on fait, ce qui est rentable, et ce que l'on laisse pour plus tard), et savoir ou l'on va et quand est ce qu'on livre.

Au niveau de la priorisation -en amont-, le plus correct, à mon sens est de prendre en compte les deux facteurs (les J.H et la complexité), mais également l’intérêt que peux avoir l'utilisateur pour une feature. Donc dans tous les cas, on doit faire plusieurs estimations et les mettre en concurrence.

Au niveau du suivi d'avancement, je n'arrive pas a me figurer la possibilité de suivre autrement qu'en J.H. Alors oui, parce que je suis tech, ça me parle et ça me fait plaisir de savoir que l'étape super compliquée de l'upload des photos est terminée et que le pool de point de complexité a baissé de moitié, mais je suis le seul qui comprend les enjeux (et je ne sais pas non plus quand est ce que je peux espérer voir le projet terminé). Quasi tous les gens impliqués veulent juste savoir quand est ce qu'il pourront jouer avec le produit final.

On pourra rétorquer :

- Qu'en tant que tech, les points de complexité sont plus parlant. Peut-être, mais je défie quiconque d'estimer en J.H avant d'évaluer la complexité technique. L'un ne va pas sans l'autre. Les J.H sont un human_readable de la complexité (entre autre chose).

- Qu'il est difficile (impossible?) de tomber juste à la première estimation. Oui! Mais rien n'est figé, et les estimations sont vouées à évoluer afin de suivre. On peux avancer plus vite ou plus lentement, et revoir l'estimation en fonction jusqu'au dernier jour. C'est également le cas avec les points de complexité, on est jamais a l'abri de découvertes qui font pas plaisir.

Alors oui, je comprends que certains d'entres nous considèrent les J.H comme un infâme outil de tracking capitaliste, ou que ses aspects "comptable" peuvent nuire à notre art. Ça c'est dans un monde idéal sans deadline, sans client, sans obligations. Quand je vais voir un entrepreneur pour qu'il me construise une maison, ce qui m’intéresse en priorité, en partant du principe qu'il va me livrer une maison conforme, c'est de savoir a quelle période je vais pouvoir m'installer. Quand je suis sur la table d'opération, ce qui m'importe plus (en partant du principe que je vais guérir) c'est de savoir quand est ce que je vais me réveiller, je sais que l'intervention est complexe mais ça ne m'apporte rien.

marc

16

Points
Le point n’est pas individualisé et journalisé, il s’agit d’un point pour une équipe et pour un Sprint entier. C’est une chouette unité si elle est bien utilisée pour savoir combien faire rentrer dans un sprint. Le j/h c’est ridicule car deux jours peuvent etre totalement différents et deux hommes/femmes aussi, sans parler des absences en plus ya ce coté productivité journalière malsain. La vélocité prend en compte tout ca, une équipe fait X points dans un sprint c’est tout, c’est top, et suffisant comme info.

philippe-peter

08

j.h
Les deux ne s'adressent pas aux memes populations selon moi. Pour une réponse à CDC ou une estimation (ou quoi que ce soit dédié à un client), le JH s'applique plus. C'est simple, concret.
Le point en pré-vente, en dehors de faire du bullshit-o-web (a ranger avec le mot "cloud", "agile", ou autre mot magique à la mode) n'est pas très compris par un client (mon opinion n'engage que moi :) ).

Donc :
- JH pour parler aux clients/devis ou autre profil non tech...
- point pour la planification des sprints et affectation des taches de l'équipe.

stfr

13

Points
Je naime pas les estimés.
pour moi quand tu vas au medecin et que tu vas faire une opération il va te dire au début que c’est probablement un peu complexe, mais quand il est sir le tas il peur avoir des surprises, il peut y avoir des complications donc il va rester le temps qu’il faut pour te fixer correctement.

a mon avis en development ca devrait etre la meme chose,
la santé du code est super importante peu importe les prédictions initiales de complexité ou de jour homme

khaldoun-aissaoui

03

j.h
Mon super argument

lefevre-benjamin50

02

Points
Les estimations ne sont pas des prédictions et sont de toute façon fausses ! L'effort nécessaire à l'implémentation d'une fonctionnalité peut dépendre de qui la traite, quand, comment, etc... L'estimation en jour.homme donne trop une fausse idée du temps exact qu'il faudra pour réaliser cette tâche. C'est pourquoi je n'utilise que des estimations en points depuis très longtemps, en gros avec la suite 1, 2, 3, 5, éventuellement 8, mais à 8 ou plus, l'incertitude est trop grande, il faut préciser et redécouper plus finement. Sans oublier que ces estimations sont surtout l'opportunité nécessaire pour échanger au sein de l'équipe, estimer les efforts pour chaque fonctionnalité par rapport aux autres, et permettre au Product Owner et à l'équipe de mettre en balance valeur/effort pour prioriser les développements.

xnopre

03

j.h
les jours hommes sont beaucoup plus concrets !

pomeh13

01

Points
L'estimation en jour est un piège à...euh développeur même si c'est plus rassurant(parlant pour le management) elle force à un engagement "ferme" et "implicite" de la part des développeurs donc contraire à l'agilité(le terme forcast n'est pas préféré à commitment pour rien dans Scrum).
L'engagement reste dans l'incrément(produit qui fonctionne et qui peut être déployé) en fin de sprint et non dans les délais au niveau individuel(ls délais étant encadrés par la durée du sprint et/ou des releases).

ibmdiouf

03

j.h
La complexité c'est cool mais bon, soyons clairs, on n'en fait jamais rien à la fin. Alors hop, les JH.

olivier

01

Points
J.H. ce n'est qu'un leak d'implémentation comptable dans le monde du développement. Les points ne sont la que pour estimer la complexité et donc donné une idée à la personne qui va l'implémenter. En général cela prendra du temps, mais un senior peut arriver au même résultat plus vite qu'un junior.

lenargit

24

j.h
Plus facile à comprendre pour les clients

sebastien

01

Points
Un junior et un senior n'auront pas la même vélocité pour la même complexité. Parler en Jour.Homme n'a pas de sens dans une équipe car elle dépend de l'Homme qu'il y a derrière. La complexité sera la même pour tous.

mathieutu

13

j.h
Oui les jours hommes ne veulent rien dire. Oui l'estimation sera fausse.

Mais un point ça parle difficilement aux gens. Un point ça ne veut pas dire la même chose pour un UX et pour un dev, ou même pour un dev et un autre dev. Quand on essaie d'estimer en points, le premier réflexe, que ce soit côté développeur ou côté client, c'est d'essayer de convertir ça dans une unité de temps, et de calculer quand ce sera terminé. Alors autant utiliser directement des unités de temps. Ce sera faux, mais le temps a au moins l'avantage d'être une unité universelle qui parle a tout le monde et qui a la même valeur pour tout le monde. Alors tant qu'à faire de mauvaises estimations, autant qu'on se comprenne un peu. Et puis on vit pas chez les bisounours, le temps (et donc l'argent), c'est ça qui définit par mal de choses...

bmc

55

Points
Chuck Norris estime en 👊

fallet-ju

02

j.h
Aucune estimation. Ni en point, ni en jour.

Arrêter de jouer les grands sorciers en essayant de prédire l'avenir. Arrêter de mentir au client de lui annonçant des chiffres. Arrêter de se mentir à soi-même en essayant de s'auto-persuader que c'est possible (quand bien même la réalité quotidienne démontre le contraire, parfois depuis des années). Oui, les faits sont têtus.

Juridiquement basculer d'une obligation de résultat (qui ne peut être défini en amont puisque développer c'est... concevoir) à une obligation de moyens. Et donc permettre au client de changer d'avis, de réfléchir, de faire évoluer en permanence son expression de besoin. Ne jamais chercher à figer. Être... agile ?

Respecter à l'Euro près le budget d'un client, avec un très haut niveau de qualité, une réactivité sans faille. Une utopie ? Sauf à accepter de faire varier le périmètre fonctionnel. Et donc logiquement à commencer par les fonctionnalités prioritaires. Parce que nous avons compris que LE logiciel, unité insécable et éternelle, n'est qu'une vue de l'esprit. Un logiciel est ensemble de fonctionnalité qui évolue en permanence. Un organisme vivant. Et s'il n'évolue plus ? Il est mort.

Arrêter de vouloir prendre des décisions à partir des estimations. Si nous prenons des décisions à partir d'éléments faux, alors ces décisions ne seront-elles pas... fausses ? Est-ce que l'on se décide de se marier en consultant une voyante ? Non. Nous décidons de nous marier à partir des éléments passés. Après avoir expérimenté. Fiançailles, POC, même combat.

Arrêt de communiquer sur l'avenir. Développer, c'est concevoir, donc c'est une activité de R&D. Or les laboratoires de R&D ne communiquent sur ce qu'ils découvriront à l'avenir. Communiquer sur ce qui est terminé, lorsque c'est terminé. Besoin de communiquer souvent ? Alors découper finement les fonctionnalités. Et lorsque nous communiquons sur ce qui est terminé, la communication devient à 100 % fiable. D'où un gain de confiance considérable vis-à-vis des clients, des managers et autres décideurs.

Et surtout s'extraire d'une tradition, d'un embrigadement intellectuel où les estimations sont considérées comme un impératif. Si en tant que professionnel nous n'arrivons pas à franchir ce cap, alors il est impossible d'éduquer nos clients.

Ajouter un troisième bouton, en plus de "J.H." et "Points" : #NoEstimates.

frederic-leguedois

00

Points
"What one programmer can do in one month, two programmers can do in two months."
www.defprogramming.com/...

yohm31

02

j.h
Estimer en points revient souvent à faire une convertion entre le temps qu'on estime et un tableau de points.
Et si ce n'est pas le cas, on va quand même demander de traduire en temps homme à la fin.

rlittolff

00

Points
#noestimate. Dans tous les cas le JH est à bannir, que veut dire un "jour homme" quand la tâche est réalisée en pair programming ? Que fait on de la revue de code ? doit-elle être comptée ?

L'argument qui prévaut par dessus tout, on construit des logiciels, pas des maisons phoenix. Chaque logiciel est différent et possède son propre degré d'incertitude.
On ne compte pas de l'incertitude en JH.

seb-quenet

02

j.h
J/h

L'argument "les jh c'est un engagement, pas une estimation", je ne le comprends pas.
Comme s'il suffisait de parler "points" pour que l'engagement s'évapore...

Les points, c'est très souvent un changement d'étiquettes. Le "mindset" est très joli, mais le ratio point/vélocité, c'est trop souvent une estimation j.h déguisée.

Donc, à défaut d'un référentiel partagé de la complexité, autant rester honnête et parler j.h

En j.h, il est aisé de justifier et comprendre l'écart entre estimation et réalité. En points de complexité, c'est plus délicat.

Des impondérables peuvent justifier un écart de charges (serveurs en rade, arrêt maladie, etc.) en ayant une incidence directe sur la production.
Un serveur inaccessible n'augmente pas la complexité d'une us... Par contre, elle augmente le temps de traitement.
Le principe est de figer le temps d'un sprint, pas sa complexité. Donc à la fin, si le sprint n'est pas bouclé, c'est par manque de temps, pas d'intelligence ;)

jordan-mariani

00

Points
Personnellement, nous faisons les deux :

- Points pour l'organisation et les échanges avec la team tech / produit
- JH pour la communication avec la direction / clients

Mais je préfère tout de męme l'estimation en points

jerome-pissis

01

j.h
en J.H, cette unité est comprise par tout le monde. Le poids d'un point dépend de l'équipe.

recup-tt

00

Points
Bien utilisés, les points permettent de lisser les écarts de productivité d'une personne à l'autre et de lisser les erreurs d'estimation.

Pour que a fonctionne, il ne faut pas oublier que:
- la "valeur" d'un point est propre à une équipe, comparer les points d'une équipe à l'autre n'a pas de sens.
- la vélocité d'une équipe varie au cours du temps.
- la vélocité ne peut pas se comparer d'une équipe à l'autre

Dans mon expérience, les sprints estimés en JH sont utilisés quand le management cherche plutôt à faire du waterfall. Le stand-up meeting se transforme souvent en compte-rendu d'avancement. Par exemple, on justifie une absence de progrès par une réunion. Une dérive possible est que les estimations soient gonflées pour éviter un porte-à-faux en fin de sprint.

Bref, pour moi, estimer en points permet de mesurer la vélocité d'une équipe et de prédire les livraisons à partir de cette mesure.

dod38fr

01

j.h
Bonjour,

A mon avis ça dépend de la taille de l’equipe.
Si un équipe est composée de plusieurs squads (plus que 4-6 devs), j’opterai plutôt pour du j.h, parce qu’il est très difficile d’avoir la même vision de ce que c’est un point avec une très grande équipe (on a même essayé taille de t-shirt, animaux ça marchait pas)
Pour une équipe réduite, on aura tendance à chiffrer de la même manière, donc plutôt en point.

abdouni-souhayl

00

Points
L'estimation en jh devient rapidement un engagement de temps et d'efforts. Et c'est parce que ça parle à tous que justement ce glissement est rapide pour ne pas dire inné. On tue dans l'oeuf toute tentative d'estimation en valeur relative.
Autre avantage de l'estimation en point, elle appartient à l'équipe. On ne peut donc faire de raccourcis dangereux entre l'équipe A et l'équipe B. C'est aussi l'objectif.
Alors oui, ça demande de sortir de l'envie de pondre des dates pour tout et souvent n'importe quoi au point que la date en devienne l'objectif et le centre de toute l'attention.
Et enfin, l'estimation en point a un rôle de «trigger» pour amener les bonnes discussions. Ça ne sert pas à faire du capacity planning.

yusthegrizzly

01

j.h
Je ne préfère pas estimer du tout, mais s’il le faut je préfère estimer par jour homme, c’est bcp plus accessible et moins accessible que les points. En général même si on estime par les points dans la tête des gens ils convertissent ça en jour homme.

diamamadouamadou

00

Points
Je préfère de loin estimer l'effort nécessaire relativement à la complexité supposée.

Jour/homme ça ne veut strictement rien dire. Entre en tech/Lead et un petit nouveau, ça ne va pas mettre le même temps. Et si celui qui connait mieux le sujet est malade ou en vacances ou constamment en réunion, laissant les plus néophytes en galère ?

La complexité quant à elle estime la part d'inconnue systémique.

Du coup logiquement, la chose à estimer est l'effort que devra fournir un groupe de personnes aux connaissances hétérogènes nécessaires pour finir le récit compte tenu de sa complexité supposée.

Ça me rappelle d'ailleurs ce qu'en dit un certain framework 🤔

vinzjobard

01

j.h
Les personnes en charge des développement doivent partager leurs avis pour déterminer un nombre de points mais si l'équipe n'est pas au même niveau il faut bien s'accorder avec une "unité d'analyse commune" qui ne peut être que le jour homme : "combien de temps je pense dépenser pour réaliser cette tâche ?"
Quand un nouveau arrive dans une équipe je ne vois pas comment il peut comprendre la valeur d'un "point" qui est une unité de temps spécifique à l'équipe au final.

francoiskasjan

10

Points
Mon super argument est là : www.soagile.eu/...

contact-2

01

j.h
Je dirais en J.H, je ne crois pas dans les estimation (trop vague et rarement exact). Des points sont souvent mal compris par tout le monde. Donc autant utiliser des J.H mais en ne s'en servant que dans de l'estimation larges (a la semaine/mois pour des planning macro)

eusebio-xavier

10

Points
#noestimate and over all not men.days or J.H In the case you need to give a probable release date uses Story points or event T-Shirt size (including risk evaluation, testing effort, ...)

frederic-dehin

01

j.h
En fonction de qui va traiter la tâche, le nombre de points de complexité change. Le top est le jh en connaissant la ou les personnes qui vont exécuter la tâche

fbarjon

40

Points
Dans le jour/homme, c'est qui l'homme ? Est-ce que chaque homme (ou femme) fait le même boulot dans le même temps imparti ?
Je préfère le point pour une équipe qui permet de connaitre la vélocité sur une période donnée et donc pouvoir connaitre le travail potentiellement faisable sur la prochaine période.

cyril-vacavant

01

Points
estimation plus correcte

asma-khemiri

01

Points
J'ai une grande préférence pour le point de complexité, notamment parce que c'est non genré.
En 2019, le 'jour.homme' devrait plutôt s'appeler ‘jour.homme.femme’ ou ‘jour.humain’, non ?

camilleroux

66

Points
Utilisation de façon plus intuitive de la Suite de Fibonacci avec les points. Plus c'est gros, moins on a besoin de précision. Plus facile à faire avec des points que des jh

elise

00

Points
À condition de ne jamais oublier qu'un point n'est comparable qu'à un autre point que si il parle du même projet.
Et pour ça il faut faire preuve de beaucoup de pédagogie.

tominardi

00

Points
moi j'aime bien les J.H-points :)

c'est a dire :
- plutôt une philosophie "points", qui donne une idée de la complexité / durée gros grain
- mais exprimée en pseudo-jours paske c'est plus facile

woofer-jones

00

Points
Ben tant qu'à estimer autant estimer en points ! je ne sais pas ce qu'est un jour.homme, c'est du temps ou de la charge ? et pour qui ? tous les hommes ne sont pas aussi productifs !!!

l-bouhier

00

Points
Estimer en points peut être plus (+) fin qu'estimer en J/H

thierry-pericard

00

Points
pour de l'evaluation commerciale, JH, pour de l’évaluation technique points

stephane

00

Points
Encore du booléen. A force, tu vas faire croire que les développeurs sont très manichéens, hein !

En vrai, ça dépend du contexte et de ton apprentissage :
- un junior par exemple n'arrive en rien à estimer en complexité : tout est complexe pour lui-pour elle)
- un senior : souvent ce qui est complexe pour lui c'est son expérience: il sait trop de choses donc il prévoit trop de cas, trop de difficultés.

Or les heures vont aider. Non pas pour savoir où tu en es, simplement pour te connaître.
Mais les heures sont trop dangereuses : elles sont utilisées dans la facturation (ce qui est très très mauvais).
Ce n'est pas le nombre d'heures qui justifier un prix ... Je peux passez 3 heures à ne rien faire et les deux dernières minutes finir le travail, impeccable (j'exagère hein, mais tu vois l'idée).

La notion de points de complexité, de l'autre côté est très intéressante, quand on a déjà de l'expérience. Mais pareil, ça n'apporte rien.

Puisqu'il faut choisir, partons sur les points.

Cependant, je pense plutôt qu'il faut apporter une nouvelle notion : la notion de valeur.

Est-ce que je fais à de la valeur ? Et surtout est-ce que ça a de la valeur pour le client ?
Comment alors facturer ? Et bien, tu enlèves la feature développée, le client pert combien d'argent ? ça lui coute combien en plus ?
Et volà c'est tout, et ça suffit à justifier les paiements, et le bon travail.
Incluons aussi : est-ce buggué ou non (pénalité sur le prix à facturer au client).

Enfin n'oublions pas que : Prix bas + Qualité haute = impossible si on veut aller vite.
Vous connnaissez la suite ... :)

evan

00

Points
Les jours hommes sont un engagement vis a vis du management. Dans notre cas un point = 1 jh donc est ce une vraie estimation

lrntbs

00

Points
Pour de la prédictibilité, le point est plus rapide et plus naturel pour notre cerveau.
Par contre, pour parler budget, cela ne me dérange pas de parler en jour.
Tous mes arguments sur mon blog :
myleanexperience.blog/...

nico

00

Points
Voici pourquoi je suis pour "pas d'estimation" mais que je vais quand meme choisir "points de complexité":
1- Le principal problème des estimations et qu'elles sont toujours fausses et empiler des trucs faux sur des trucs faux donne de la merde.
2- des estimations ne sont que des estimations et doivent le rester. le problème c'est que le management les reprend toujours pour essayer d'en tirer des choses, des planification etc...
3- les estimations contraignent le dev dans des timebox et ces devs deviennent prêts à prendre tous les raccourcis pour pouvoir faire rentrer le boulot dans les clous (cf commitstrip: www.commitstrip.com/... ). Cela, quitte à mettre en péril la suite du projet. Tout ca pour pouvoir dire devant le management "regardez c'est bon j'ai fini ma story dans le temps imparti" !
3- Quoil de mieux que de particiuper à des débats inutiles mais interminables pour savoir si une story doit etre estimée à 3 ou 5 unités ? => On s'en fiche c'est l'ordre de grandeur qui importe et les discussions préalables pour lever les loups.
4- ceci dit le point positif des estimations et de forcer les dev à parler de ce qui va être réalisé pendant la story. Ca permet de mettre tout le monde au même niveau de compréhension et de lever certains loups avant la réalisation
5- mais au final a-t-on vraiment besoin de faire ça pour se comprendre ? Toutes ces heures perdues dans le but d'estimer ? alors qu'on pourrait passer un peu moins de temps avec juste pour but de se comprendre techniquement et fonctionnellement...

Conclusion: donc bref, idéalement je suis pour pas d'estimations (au sens ou je les ai toujours vu pratiquées). Mais comme on est dans l’Arène, je me vois contraint de choisir "point de complexité". Car honnêtement, "jours homme", c'est une unité de mesure qui fait croire aux non-devs qu'il suffit d'ajouter toutes les estimations en jour-homme, diviser par le nombre de devs et hop on arrive à une date de release! Magique, non ?! Au moins, "point de complexité" ça permet de mentir un peu moins, de faire passer le message que "ben oui en fait on n'en sait rien, ca prendra peut etre 2 jours, peut etre 3 ou 4".
Ah oui aussi, pour finir j'ai une mauvaise expérience en SSII où l'on vendait des jours-homme au client en trafiquant et bidonnant tous les chiffres...

francois-marot

00

Points
Ni l'un ni l'autre.
Si c'est suffisamment affiné et indépendant alors pas besoin de ce genre de mesure.
On ne livre pas un avion ou une maison ... On livre quelque chose de complexe et d'incertain.
Mais s'il faut choisir ... Alors le point évidemment.
Il peut rassurer l'équipe sur sa capacité à livrer de manière stable si elle en ressent le besoin.

eirianlegoux

00

Points
De toutes façons on sait pas estimer ! On. Se trompe tout le temps. Au moins la suite de Fibonacci nous aide à prendre cela en compte.

npascaud

00

Points
Le Jour/Homme est risqué car il s'agit de s'engager sur un délai. C'est bien au delà de l'estimation contrairement aux points. Évaluer la difficulté d'une tâche n'est pas si difficile, dire combien de temps il faudra pour la développer c'est tout autre chose.

Le problème c'est que le Jour/Homme est une unité pour managers et chefs de projets alors que les points sont une unité de développeurs.

jason-benedetti

00

Points
Les j.h représentent du temps disponible, ce qui est très soumis à des aléas. Les points représentent de l'effort pour résoudre une complexité, cette complexité est (normalement) invariante.

omassol

00

Points
Le jour/homme est une notion trop vague, quel homme? Quel jour? ....
Il n'y a pas assez de rigueur, et une abstraction faite des disparités techniques entre membres d'une même équipe, etc...

imad-bougataya

00

Points
Les J.H. sont beaucoup trop contraignants et ne tiennent jamais en compte tout ce qui se passe pendant la journée.
De plus les JH poussent une deadline ferme, ce qui génère de la frustration dans une équipe autogérée et mure.

apoletti

00

Points
Plus stable dans le temps et plus neutre vis à vis du contexte de réalisation (compétence de chacun vis à vis d’une tâche, âge du capitaine, accord des personnalités, forme de collaboration, etc), donc meilleur support destination.
+ prouvé que la mesure individuelle décourage la coopération, dont on a cruellement besoin dans nos métier. C’est une mesure qui nivelle par le bas: utile si on envisage de rester médiocre

Par contre: le point ou la notion de complexité fonctionnelle sont trop abstraits.

Proposition: mesurer en JH de test, ou effort de test! Ou chienlit à tester. C’est un proxy indicator de complexité (inclut intégration, complexité cyclomatique, etc). Mais les gens peuvent se projeter mentalement et concrètement, donc la réponse est aussi facile sinon plus que pour des JH de « dev »

giom

00

Points
JH=engagement vs Points=estimation.
On peut estimer le temps que l’équipe mettra grâce aux points et à la mesure de la vélocité. En jours/homme, il faut en plus se poser la question de qui fera dans l’équipe car ce ne sera pas le même jh selon qui réalise

s-decaix

00

Points
Je préfère les points. Dans les deux cas, ce sont des estimations donc peu de chance que cela soit juste...Je préfère les points mais il faut expliquer à l'équipe ce que cela réprésente (effort, complexité, incertitude...). La vélocité est donc plus vivante que les J.H. qui eux, restent fixes (sauf si vacances). Cela permets de mieux appréhender la capacité de l'équipe. Je trouve que c'est aussi la bonne voie pour faire passer une société qui estime en J.H vers du noEstimate. Néanmoins, les points sont peut-être plus compliqués à utiliser avec des équipes en forfait avec des clients qui ont une enveloppe budgetaire. Ce qui peut se comprendre.

chocnroll81

00

Points
Vous avez surtout parlé des J.H comme permettant de calculer des budget, il me semble qu'il manque un point primordial :
Communiquer sur des J.H permet aux autres équipes (commerciaux, support client, marketing) de communiquer sur des deadline.

La première chose est de savoir quand le client sera servi et quand les communications doivent partir.

Je parie sur les points on verra si ça tient ses promesses.

edouard-artisandeveloppeur

00

Points
Les points bien sur... Dans une équipe stable et un peu mature, les points permettent de planifier des versions d'un logiciel de manière précise, grâce à la mesure de la vélocité. Au bout de 20 ans dans le logiciel je n'ai jamais connu un projet avec des estimation jh qui tienne la route. S'acharner dans cette voie est une perte de temps et d'énergie...

ricovitch

00

Points
L'estimation en points de complexité permet d'aligner l'équipe sur une valeur commune, peu importe qui le fait dans l'équipe, la valeur reste la même.

florian-faribault

00

Points
L'avantage d'estimer en points de complexité avec une échelle qui les différencie bien des jours hommes, c'est qu'on ne sera pas tenté de les considérer comme un engagement ferme qui servira de base pour la gestion de projet, voire de les communiquer au client !

christophe-sc

00

Points
L'estimation en jour Homme est peut être plus simple à comprendre mais elle est malheureusement couplée à trop de facteur externe connue et inconnue et la rend extrêmement peu fiable. On est obligé de mentir et parfois faire de la politique pour se protéger.

Je n'ai pas encore eu l'occasion d'utiliser une estimation par point mais je pense cela permet d'établir une sorte de barème de complexité sur les concepts et la maturité de l'équipe sur ce dernier.
Au delà de permettre le planning des sprints, je pense que ça permet aussi de tirer vers le haut le niveau global, en poussant chacun à apprendre et à partager.
(j'espère ne pas être le seul à le penser :O)

Aussi n'oublions pas qu'après plusieurs itérations et par apprentissage il est possible de convertir les points en Jour Homme et cela de manière beaucoup plus fiable qu'une estimation donner directement en Jour Homme.

conanjahh

00

Points
Points score par ce qu'il s'agit d'une estimation relative contrairement au jour homme qui est obsolète.

abdellah-mannioui

00

Points
En parlant de points, cela permet aussi d'estimer plus facilement dans une équipe de développeurs ayant une expérience différente.
En général, le point correspond à une journée idéale pour le plus expérimenté des développeurs.
Et la vélocité est là pour ensuite savoir combien de points sont à embarquer dans un sprint.

marec-yann

30