Pourquoi utilisons-nous des points d’histoire plutôt que des jours de travail pour estimer les user stories?

132

Dans les méthodologies agiles (par exemple SCRUM), la complexité / les efforts nécessaires pour les user stories sont mesurés en points d'histoire. Les points d'histoire permettent de calculer le nombre d'histoires utilisateur qu'une équipe peut accepter dans une itération.

Quel est l’avantage d’introduire un concept abstrait (points d’histoire), dans lequel on peut simplement utiliser une mesure concrète, telle que l’homme-jours estimée? Nous pouvons également calculer la vitesse, estimer la couverture d'une itération, etc. en utilisant des jours-hommes estimés.

En revanche, les points de récits sont plus difficiles à utiliser (car le concept est abstrait), mais aussi plus difficiles à expliquer aux parties prenantes. Quel avantage offre-t-il?

Louis Rhys
la source
16
pourquoi supposez-vous que la journée des hommes est plus concrète que l'histoire, ce n'est pas le cas.
Ryathal
4
Est-il plus facile d'expliquer que votre estimation de 5 jours-hommes signifie qu'il vous faudra 1 mois pour terminer, car votre vitesse est de 0,25 jour-hommes / jour-calendrier?
Patrick
3
@ Izkata, ce n'est vrai que si votre vélocité est toujours exactement 1
Patrick
4
@Patrick Lorsque vous utilisez man-days (voir man-hours sur Wikipedia), il n'y a pas de concept de vitesse. C'est une chose agile / scrum.
Izkata
3
La chose intéressante est que dès que la vitesse se stabilise, les points de récit ont tendance à être identifiés avec un certain nombre d'heures ou de jours. Par exemple, 1 point d'histoire = 1 jour. Si je pense que cela prendra 2 jours, je vais estimer 2 points d'histoire.
Giorgio

Réponses:

126

Je pense que l'un des principaux avantages est que les humains et les développeurs sont en fait assez mauvais pour estimer le temps. Pensez aussi à la nature du développement - ce n'est pas une progression linéaire du début à la fin. C’est souvent «écris 90% du code en 10 minutes, puis arrache tes cheveux pour 17 heures de débogage». C'est assez difficile à estimer dans le sens du minutage.

Mais utiliser une abstraction élimine le temps réel en heures ou en jours et se concentre plutôt sur la description de la dépense relative et de la complexité d'une tâche par rapport à d'autres tâches. Les humains / développeurs sont meilleurs à cela. Et puis, une fois que vous aurez fredonné avec ces estimations ponctuelles et quelques progrès réels, vous pourrez commencer à regarder le temps plus empiriquement.

Je soupçonne qu’il existe également un effet d’observateur qui se produit avec des estimations de temps qui ne se produirait pas avec des estimations ponctuelles. Par exemple, l'incitation à donner au client une estimation et à la livrer "à l'avance" va être atténuée avec l'indirection dans un système basé sur des points.

Erik Dietrich
la source
28
+1 pour l'accent mis sur la complexité , pas le temps. Traduire en heures crues sera facile une fois que vous aurez suffisamment de sprints à votre actif. J'ai trouvé que la variabilité entre les histoires s'estompe avec le temps.
Kristo
14
Donc, vraiment, les points de complexité peuvent être un terme plus clair que les points d’histoire, et toute tâche comportant trop de points de complexité est trop complexe et comporte probablement trop de risques et d’inconnues pour qu’elle soit traitée en une seule fois. La complexité a un coût exponentiel, et le pauvre nid qui est coincé dans cette tâche creuse un trou si profond qu'il ne sera plus revu avant des semaines, voire des mois. Mieux vaut commencer par comprendre plus facilement une tâche complexe et la diviser en tâches plus petites, avec une complexité moins risquée et mieux comprise.
Supr
4
Le temps et le coût sont des effets, la complexité en est la cause et vous ne pouvez pas comprendre le temps sans comprendre la complexité.
Supr
8
Points d'histoire = Points de complexité - 2 syllabes. :-D
Kristo
5
Est-ce que quelqu'un a déjà envisagé d'appeler des points de l'histoire "coût de casting"? => ballot
Aaron Gibralter
59

Si vous utilisez des nombres de Fibonacci (ou quelque chose de similaire), cela limite le nombre d’options lors de l’estimation d’un récit. J'ai travaillé avec un groupe qui n'utilisait que de faibles nombres: 1, 2, 3, 5, 8 et 13. Nous avions une histoire de référence qui était un 5. Cela nous permettait de prendre facilement des décisions rapides sur la complexité d'une histoire tout en faisant Planning Poker . L’autre effet secondaire était que tout ce qui était noté 13 avait probablement des informations insuffisantes et devait être décomposé plus avant. Je doute sérieusement que cela aurait été aussi simple et facile si nous utilisions des heures brutes.

Votre responsable de produit parle la langue de vos parties prenantes et devrait être en mesure de faire la traduction entre les points de scénario et les heures-personnes (ou d'autres unités) selon les besoins. Au cours de ma carrière en tant que bon de commande, j'avais des données précises selon lesquelles 1 point d'histoire = 4 heures-homme, mais chaque équipe est évidemment différente.

Modifier:

Sachant qu'un point = 4 heures, vous pourriez théoriquement modifier votre deck Planning Poker en 4, 8, 12, 20, 32 et 52. Mais ces chiffres sont plus difficiles à gérer. Je pense que je résumerais mentalement les valeurs en quelque chose de simple, par exemple, "moins d'un jour", "plus d'une semaine", etc. points d'histoire sans

Kristo
la source
Nous utilisons la même méthode, et notre tableau de planification a des chiffres plus élevés, mais nous avons défini un 20 comme signifiant qu’il doit être ventilé ou mieux défini. Pour nous, un 13 est notre tâche la plus importante et il s’agit généralement de tâches qui prennent jusqu’à une semaine.
Bill Leeper
"L’autre effet secondaire était que tout ce qui était noté 13 avait probablement des informations insuffisantes et devait être décomposé davantage." Et je suppose que si elle est décomposée davantage, elle sera décomposée en parties équivalentes de Fibonacci?
Joe Z.
@ JoeZeng, oui, ceux-ci sont souvent devenus 8 + 5 ou 5 + 5 + 3. C'est une mesure abstraite cependant, donc si les nouvelles histoires sont suffisamment proches, je ne m'inquiétais pas trop. L'équipe pouvait normalement absorber un 13 devenant deux 8 ou trois 5, mais trois 8 signifiait que je devais avoir un entretien de clarification avec les parties prenantes. Idéalement, nous avions estimé assez tôt que cela n'aurait pas d'impact sur le sprint actuel.
Kristo
1
Pas nécessairement. Nous avions supposé que les histoires étaient de 5 points, et une somme plus détaillée et ventilée est de l'ordre de 15 points. Ça arrive.
cendres999
24

Cela permet d'améliorer les estimations avec le temps, sans que les estimateurs aient tous à ajuster leur estimation.

Au lieu que toutes les personnes impliquées dans l'estimation aient à penser comme "OK ... ça ressemble à 2 jours homme ... mais le dernier sprint, nous avons tout sous-estimé, alors peut-être que c'est vraiment 2,5 jours-hommes. Ou 3?", Ils continuent comme avant. "5 points d'histoire!"

Ensuite, vous ajustez votre estimation du nombre de points d’histoire que l’équipe peut obtenir lors d’un sprint, en fonction des résultats réels mesurés lors des sprints précédents. "Nous avions fait 90-110 points d'histoire par sprint auparavant!"

Je dirais que la théorie derrière cela est que les développeurs sont mieux à même d’estimer la complexité relative de différentes tâches de développement que d’estimer les absolus . Surtout si plusieurs personnes estiment une tâche qui pourrait être effectuée par l'une d'entre elles (et que tout le monde ne travaille pas à la même vitesse que tout le monde).

Alternative cynique: j'ai déjà vu qu'il était dit que les développeurs ne venaient jamais en dessous des estimations de temps. Si quelque chose prend plus de temps que prévu, vous êtes passé au dessus. Mais si quelque chose prend moins de temps que prévu, les développeurs peuvent la manipuler, la plaquer au doré, ou tout simplement ralentir et ralentir et se détendre, puisqu’ils se voient confier une tâche difficile. Prendre les unités de temps réelles dans une estimation peut enrayer ces tendances. Fin de l'alternative cynique.

Carson63000
la source
13
Ce n'est même pas cynique. C'est le principe de "rapide ou bon marché ou bon". Je peux vous donner une version de FizzBuzz essentiellement stable et qui fonctionne, qui vous donnera ce que vous voulez généralement en quelques minutes, mais si vous voulez une interaction utilisateur, cela prendra plus de temps et si vous voulez des tests de régression, cela prendra plus longtemps, et si vous ne voulez pas que cela échoue lorsque vous appuyez sur MAX_INT, cela prendra plus de temps. Dis-moi de donner la priorité à la vitesse et je commencerai à décharger les req. Dis-moi de donner la priorité à tout le reste, et je vais utiliser tout le temps qui m'est donné.
deworde
17

Les jours-hommes ou les heures-hommes sont, comme vous le dites, concrets. Donc, quand une tâche est estimée à 5 heures et prend 6, c'est maintenant une tâche en retard.

Lorsque vous avez une histoire qui est un 3 points et cela prend 6 heures, cela a pris 6 heures, il n'est pas tard, il a juste pris six heures. La mesure de la vitesse est plus qu'un facteur du nombre de points obtenus lors d'un sprint, et ce nombre peut fluctuer, car il n'est pas concret. Vous ne mesurez pas non plus chaque tâche, mais le total de toutes les tâches. Lorsque vous avez des heures pour chaque tâche, la tentation est là de mesurer chaque tâche. Lorsque cela se produit, vous n’obtenez aucun avantage pour le sprint si vous terminez en deçà du temps imparti. C’est une conséquence pour terminer au fil du temps d’une tâche donnée.

Cela peut être une transition vers une réflexion en termes de points. A un endroit où j'ai travaillé avant même d'introduire des tailles de t-shirts agiles usagés, juste pour avoir une idée du niveau d'effort. Les points ne sont qu'une extension de cela.

Cela ne veut pas dire qu’il n’ya pas de controverse, ni d’assignation arbitraire aux points. Nous avons des membres de notre équipe qui votent presque toujours le nombre le plus bas et se plaignent quand ils pensent qu’une tâche est un 1 et que nous pensons que c’est un 3 qui souffre de l’inflation de points.

Bill Leeper
la source
13

L'abstraction est en quelque sorte le but. L’utilisation de la «journée de travail» comme mesure comporte un certain nombre de pièges, notamment:

  1. Si l'équipe ne connaît pas bien la technologie qu'elle utilisera, il peut être très difficile de donner une estimation en temps réel de la durée d'une tâche. Ils sont beaucoup plus susceptibles de pouvoir donner de bonnes estimations relatives - par exemple, "la tâche A prendra probablement deux fois plus longtemps que la tâche B".
  2. Différentes personnes travaillent à des taux différents! Si vous utilisez "jours ouvrés", vous devez pratiquement changer le temps estimé lorsqu'une tâche est passée d'un développeur à un autre. Qui définit combien de travail constitue de toute façon une journée-homme?

Si vous voulez estimer homme-jours c'est un calcul simple:

user points in story / average user points per developer per day = estimated man days
vaughandroid
la source
En ce qui concerne le point 2: comment le point d'histoire résout-il cela? Vous estimez une histoire en 4 points. Vous le donnez à un programmeur plus rapide et cela prend 4 jours. Vous le donnez à un programmeur lent et cela prend 8 jours. Il me semble que le problème n’est pas résolu mais qu’il vient d’être déplacé.
Giorgio
En ce qui concerne le point 1. L’idée est que si l’équipe se familiarise davantage avec les technologies nécessaires au projet, leur vitesse augmentera et la taille relative des histoires, mesurée en points, restera la même. Mais que se passe-t-il si deux histoires d'utilisateurs nécessitent des connaissances différentes? Par exemple, vous avez une histoire d'utilisateur frontale à exécuter en Javascript / HTML et une histoire d'utilisateur principale à réaliser en Java. Au fur et à mesure que l'équipe en apprend plus sur les langages Javascript, HTML et Java, ils découvrent que la partie front-end est beaucoup plus simple que la partie back-end et que les estimations relatives des récits sont à nouveau fausses.
Giorgio
@Giorgio Re. Point 2: Votre programmeur plus rapide a un taux de travail de 1 point d'histoire / jour et votre programmeur plus lent a un taux de travail de 0,5 point d'histoire / jour. Si vous le faites en quelques heures, soit votre programmeur le plus rapide va se mettre à mort, soit votre programmeur le plus lent a besoin d'être renvoyé. La réponse de Bill Leeper montre très bien ce point.
Vaughandroid
1
Ré. Point 1: Pour mon argent, si vous parlez de 2 ensembles de technologie différents et de 2 domaines différents du produit, vous avez deux équipes.
Vaughandroid
Plus loin. point 2: les user stories sont développées par l' équipe et non par des développeurs individuels. C'est le taux de travail de l'équipe qui est la partie importante. N'oubliez pas que lorsque vous implémentez des user stories, vous devez d'abord les décomposer en tâches. Donnez plus de tâches au développeur le plus rapide!
Vaughandroid
6

Comme déjà mentionné, les points de récits sont une mesure relative de la complexité. On peut utiliser une puissance de 2 séries (1,2,4,8,16 ...) ou une échelle de Fibonacci (1,2,3,5,8,13,20 ...) pour l'estimation. En tant que développeurs, ils sont tout à fait habiles à dire quelque chose comme ceci:

La fonctionnalité A est presque deux fois plus dure que la fonctionnalité B

Mais il est vraiment difficile de dire «combien de temps» cette fonctionnalité prendra pour être mise en œuvre. Vous laissez cela être équilibré par la vélocité. Donc, si quelque chose est estimé à 5 mais se révèle être un 13, une vitesse plus lente normaliserait cela pour l'itération (ou vous pourriez ré-estimer).

Maintenant, il y a une autre alternative, ça s'appelle 'des jours idéaux' (certains ressemblent à des hommes-jours mais je ne sais pas si c'est ce que vous vouliez dire) et je connais pas mal d'équipes qui préfèrent ça. Les jours idéaux doivent être interprétés comme:

Si c'est tout ce que je fais après mon arrivée au bureau et que je ne prends que les pauses nécessaires, je ne subis aucune interruption et je disposerai de tout ce dont j'ai besoin pour "mettre en œuvre le récit", c.-à-d.

Mike Cohn, l'un des nombreux évangélistes agiles bien connus, offre la comparaison suivante entre les points d'histoire et les jours idéaux

Points d'histoire

  • Permet de générer un comportement interfonctionnel, c'est-à-dire que les équipes évaluent les histoires en fonction de la complexité totale de la mise en œuvre, de l'interface utilisateur à la base de données
  • Les estimations de SP ne se détériorent pas, c’est-à-dire que dans quelques mois une histoire à 5 points est toujours susceptible d’être de 5 points, mais une estimation du jour idéal peut changer en fonction de la compétence / vitesse de développement acquise de ce programmeur particulier
  • Les SP sont une mesure pure de la taille, c’est-à-dire qu’elles ne reflètent que la complexité de la taille. Période. Aucune durée, etc. C'est le travail de vélocité. Mais pas si avec des jours idéaux. En fait, avec les jours idéaux, on a tendance à le confondre avec les jours calendaires. Le garder abstrait alors que les SP combattent la tentation de se comparer à la réalité. Juste une mesure de taille. Pas de bêtises.
  • Est généralement plus rapide que les jours idéaux. Cela peut être délicat pour les deux premières histoires, mais une fois que vous avez compris, c'est plus rapide.
  • Différents développeurs peuvent avoir une idée différente de l’évaluation de leur journée idéale pour compléter une histoire. Je pourrais faire la même chose en 3 et vous pouvez en 5. Les PS sont plus ou moins uniformes. Ils nivellent le terrain de jeu pour ainsi dire.

Jours idéaux

  • Plus facile à expliquer en dehors de l'équipe; pour des raisons évidentes :)
  • Plus facile à estimer au début comme mentionné ci-dessus. Mais une fois que vous maîtrisez les SP, cela vient naturellement

Maintenant, lequel choisir est à l'équipe. Cependant, comme la plupart des réponses ici et mon expérience personnelle, je préfère les points d’histoire. Les journées idéales n'ont pas vraiment d'avantages sur les SP (et Mike Cohn préconise également les SP ainsi que de nombreux autres évangélistes agiles).

Doctorat
la source
Le prochain numéro de Fibonacci est le 21, pas le 20.
Joe Z.
4
21 ou 20 n'a pas d'importance lors de l'estimation. Les SP arrondissent le nombre de fibonacci suivant pour éliminer le sentiment de fausse précision. Le nombre suivant dans la séquence n'est pas 34 mais 40 (double de 20) et ensuite 100. Les chiffres représentent une «incertitude» en termes de complexité et non de précision. Ce n'est qu'une approximation.
PhD
1
C'est vrai, je cueillais juste des lentes (et je plaisante).
Joe Z.
1
@PhD: "Les estimations de SP ne se détériorent pas, c’est-à-dire que dans quelques mois, une histoire à 5 points sera toujours de 5 points, mais une estimation du jour idéal peut changer en fonction des compétences / de la vitesse de développement acquises par ce programmeur particulier": suppose implicitement que l'équipe améliorera ses compétences de manière uniforme dans tous les domaines du projet. Je ne vois pas pourquoi cela devrait toujours être le cas: certaines parties d'un projet (et les technologies requises pour celles-ci) pourraient s'avérer plus difficiles que d'autres, rendant invalide l'estimation initiale de la complexité relative des points de scénario.
Giorgio
3

Les points d'histoire vous aident également à mesurer l'amélioration des performances de l'équipe au fil du temps. De plus, il n'est pas nécessaire de tout réestimer à mesure que les performances s'améliorent.

Prenons cet exemple qui utilise les jours-hommes:

L'équipe estime différentes tâches en hommes-jours. Cela fonctionne pendant un certain temps, mais après un certain temps, vous constaterez que l’équipe se fait plus rapidement avec de nombreuses tâches que ce qui avait été prévu au départ. L'équipe réévalue donc les tâches. Cela fonctionne pendant un certain temps, et après un certain temps, vous voyez à nouveau la même chose: l’équipe se fait plus rapidement avec de nombreuses tâches. Donc, vous ré-estimez encore, et cette histoire se répète encore, et encore et encore ...

Pourquoi? Parce que les performances de votre équipe ont augmenté. Mais vous ne savez pas à ce sujet.

Le même exemple avec des points d'histoire:

L'équipe estime la taille des user stories. Après quelques sprints, vous voyez que l’équipe peut faire environ 60 points d’histoire par sprint. Plus tard, vous constaterez que l’équipe a atteint plus de 60 points d’histoire, peut-être 70. Et l’équipe continue de la même manière.

Pourquoi? Parce que la performance a augmenté. Et vous pouvez le mesurer. Et vous n'avez pas besoin de tout réestimer une fois que les performances de votre équipe ont augmenté.

Uooo
la source
3
"Pourquoi? Parce que les performances de votre équipe ont augmenté.": Une autre explication est qu’après un certain temps, l’équipe commence à donner des estimations de temps plus précises / plus réalistes estimation des histoires pour les sprints ultérieurs).
Giorgio
2

Premièrement, les gens sont meilleurs aux estimations relatives qu’aux estimations absolues. La cartographie et l'évaluation de la luminosité relative des étoiles par les babyloniens en sont un excellent exemple. Ils n’ont pas obtenu les chiffres absolus exacts, mais l’ordre était généralement parfait, même pour des intensités très similaires.

Le deuxième avantage est que l’un des principaux objectifs de cet exercice est de stimuler la conversation. Si vous commencez à discuter les jours exacts, la conversation risque de dérailler rapidement.

Comme le disait Napoléon: le plan ne vaut rien, la planification est inestimable.

Troisièmement, le chef de projet n'a pas à éditer toutes les estimations, simplement parce qu'il s'avère que les estimations ont été décalées d'un facteur, par exemple, de 130%.

Tormod
la source
0

Les points de récit reflètent la complexité du problème et, par conséquent, la confiance (ou le risque) quant à la précision de l'estimation.

Une histoire avec un point d'histoire élevé me dit qu'il y a beaucoup de choses qui ne sont pas concrètes dans l'histoire de l'utilisateur.

L'idée est de voir quel est le bon équilibre entre les différents points de l'histoire. Si on me présente un plan d'itération avec des histoires avec tous les points forts de l'histoire, cela ne me donne aucune assurance que l'itération sera exécutée comme prévu et que nous devons examiner d'autres histoires pour l'itération ou commencer à décomposer les histoires.

Lorsque vous communiquez avec un responsable ou un responsable de produit, des points d'histoire élevés signifient qu'il sera extrêmement difficile de savoir quand ils obtiendront une fonctionnalité particulière. Une des solutions consiste à décomposer l’histoire et à espérer que vous disposerez d’une combinaison de points d’histoire faibles et élevés afin que vous puissiez démontrer de façon itérative les progrès réalisés au Product Owner.

grumpasaurus
la source
0

Les jours-hommes estiment le temps qu'il faut pour faire quelque chose. Ils sont mieux utilisés lorsque les éléments que vous estimez sont très précis et mesurables. Des tâches spécifiques, bien connues et pouvant être répétées sont estimables en nombre de jours-homme.

Par exemple, si un vendeur peut passer 20 appels client par jour, en moyenne, nous pouvons calculer le temps que prend chaque appel et à partir de cela, nous pouvons estimer le nombre de jours-hommes nécessaires pour passer 1000 appels.

Dans cet exemple, on peut penser concrètement en termes statistiques à la longueur médiane d’un appel, car on peut supposer que tous les appels sont effectivement la même chose.

Les points d’histoire déterminent quelle combinaison d’histoires peut être faite dans une itération. Ils sont utilisés pour combiner des objectifs hétérogènes avec des limites floues et pour mesurer combien peuvent être réalisés dans un laps de temps déterminé. Ils estiment la complexité des morceaux de travail les uns par rapport aux autres afin de pouvoir les additionner.

Par exemple, votre équipe a créé 5 histoires pour un total de 23 points en itération 1 et 8 histoires pour 20 points en itération 2. À partir de là, vous pouvez estimer qu’en itération deux, votre équipe fera quelques histoires dont le total est d’environ 20 points. dans l'itération 3.

Notez qu'il n'est pas nécessaire de déterminer la taille d'un point et en particulier, il n'est pas supposé que chaque histoire de la même taille prendra le même temps pour être développée! Nous travaillons uniquement sur des sommes et sur des points par itération. Je n'ai même pas mentionné la longueur de l'itération.

Sklivvz
la source
0

Si vous vous approchez d'un humain dans la rue et demandez "Quelle était la taille d'un T-rex?" les réponses varieraient même si la majorité des humains savent ce qu'est un T-rex, quelle en est sa taille, mais personne ne le sait vraiment - car nous n'avons AUCUNE échelle relative entre nous.

C’est le comportement cognitif que vous essayez de comprendre avec les prévisions et de nombreuses méthodologies qui font tourner les cycles avec " je les ai! .. j'ai le secret pour des prévisions précises! " De l’huile de serpent aux masses. Lorsque vous prévoyez réellement, vous dites vraiment que vous laisserez entendre « Je vais permettre x jours / heures / points pour que cela soit terminé » - c'est en quelque sorte créer une «boîte de temps» pour que l'événement se déroule à l'intérieur.

Pour moi, Points ne fait que déplacer les limites, à la fin de la journée, à moins que vous ne soyez dans une équipe heureuse de dire " * Eh bien, nous avons 3 semaines par sprint et le pouce est nul ... je pense que nous devrions viser Qui est avec moi! * "Et qui est aussi profond que vous allez dans la modélisation des prévisions - bien! ..as réaliste que vous venez de fixer un budget arbitraire et c'est tout. Vous êtes également ensuite en train de regarder rétrospectivement le travail effectué avec le sentiment de "merde sacrée, nous avons lancé 33 points ce sprint, c'était plutôt cool" et rien ne peut être fait à ce sujet. Vous pouvez utiliser la vélocité pour déterminer si votre budget est correct à mi-course en demandant à voix haute " Avons-nous déjà atteint 15 pts? Allons-nous""mais le danger ici est que vous utilisez maintenant Velocity pour mesurer la productivité et non la capacité, ce qui, si j'ai bien compris, donne un coup de fouet à la gestion de la version réactive (Story Points) dans la tête ..

Le système de points est presque trop intelligent pour ne pas remarquer que vous attachez toujours du temps relatif à l'équation, de vos "cycles de sprint" convenus à vos relevés quotidiens dans lesquels vous incarnez une règle cachée autour de la durée + complexité = " Max prend trop de temps avec cette tâche "instinct inné sentiment code rouge moment?

Le cerveau humain ne peut pas prévoir parce qu'il implique beaucoup de mémoire de travail mélangée à un rappel à long / court terme, c'est donc comme demander à un étudiant en mathématiques novice de faire des fractions dans sa tête, pas sur papier. C'est pourquoi les autres industries ne sont jamais d'accord sur une prévision et Validez constamment les prévisions en temps relatif (par exemple, les géologues ne cessent jamais de modéliser les prévisions tant que le mètre cube n’a pas été extrait du sol, puis c’est fait).

Je dirais que le système de points fonctionne si vous ne faites pas de prévisions . Vous acceptez une partie du travail qui repose sur un algorithme de sous-segmentation, mais qui constitue votre approche de prévision la plus proche possible. En fait, votre responsable de la publication chercherait des ruptures naturelles dans la file d’arrière-plan qui correspond à un ou plusieurs thèmes (c’est-à-dire que dans Silverlight, les chefs de produits attendaient qu’ils aient terminé leur arriéré pour reconstituer les thèmes que nous avions initialement définis. Je ne savais jamais ce que l'équipe d'ingénieurs faisait spécifiquement, nous avions juste un aperçu de base. Nous prenions ensuite ce travail et organisions notre événement marketing autour de celui-ci (Microsoft Mix).

Lorsque vous commencez à fixer des prévisions de vélocité à l'intérieur de cycles de sprint qui reposent sur la vélocité + le temps, vous êtes de nouveau en mesure de prévoir des estimations, mais cette fois-ci vous êtes moins bien loti parce que vous jouez au jeu "ça dépend" ... Plus important encore, vous Nous éliminons également le potentiel de croissance d’équipe / de carrière.

La taxe que vous payez pour Points vs Time correspond aux points dont vous avez besoin pour rechercher des formules de mesure alternatives permettant de suivre le développement des compétences en ligne / le mentorat ou le comportement du développeur.

Dans la mesure où vous aurez toujours besoin de rechercher un "développeur médian" comme personne idéale avec laquelle vous souhaitez associer compétences / efforts, vous pouvez ensuite contacter d’autres développeurs avec cette personne pour déterminer dans quelle mesure elle tient compte de sa croissance continue au sein de votre équipe. Il met également en évidence les situations dans lesquelles les développeurs "rapides" transportent la majeure partie de l'eau mais s'ennuient ou empirent, travaillent plus longtemps et ne sont pas reconnus / récompensés en raison d'échéances concurrentes, etc. il détecte les mauvaises odeurs au sein de l'équipe, comme dans "cette personne a des difficultés, aide"

Viennent ensuite les histoires de "report", des histoires qui ne sont pas incluses dans ce cycle de sprint mais qui se propagent ensuite au cycle de sprint suivant. Ce qui peut alors facilement créer un effet d'entraînement si vous prenez en compte le temps, mais dès que vous prenez en compte le temps relatif..en outre, vous venez de revenir à la "prévision / estimation basée sur le temps" et encore une fois, le système de points est juste. brouillant les eaux.

Si vous marquez des points, vous aurez totalement ignoré le temps et je veux dire complètement, au moment où vous laissez le temps s'infiltrer, vous jouez l'idée / la méthodologie.

Ayant voyagé à travers le monde en tant qu'évangéliste, j'ai vu beaucoup d'équipes assermenter tout ce qui leur tient à coeur qu'elles ont déchiffré le code Agile Forecast ... mais j'ai toujours cliqué sur ma langue, souris et suis repartie avec la pensée " ouais ... tu as failli le faire, mais cette maîtresse que nous appelons "le temps" ... elle est juste cruelle ... "

Scott Barnes
la source
-1

Le livre "Estimation et planification agiles" de Mike Cohn décrit les avantages et les inconvénients de l'estimation avec des "jours idéaux" ou des points d'histoire. La réponse rapide à votre question est qu'il n'est pas nécessaire d'estimer avec des points d'histoire. S'il est plus naturel d'estimer le nombre de jours idéaux, continuez.

David M
la source
1
Cela ne répond pas nécessairement à la question. il fournit simplement une référence de livre à la place. Vous pouvez renforcer votre réponse en fournissant un résumé des avantages et des inconvénients.
-1

Je pense que la méthode Story Point présente au moins deux avantages importants par rapport à la méthode des jours ouvrables: Premièrement, elle est plus facile à estimer dans SP. La SP est relative et les humains comme nous valent mieux que l'estimation absolue comme la méthode du nombre de jours-hommes.

Deuxièmement, lorsque vous estimez en SP, vous obtenez "Team SP" et non pas "Individual Manday". Lorsque vous demandez "Combien de temps cela va prendre?", Le développeur senior peut vous donner 1 jour mais 5 jours pour un junior. C'est le jour de l'homme qui décide qui va s'en charger. Si le propriétaire est forcé de changer (et ce sera le cas!), Vous devez tout planifier à nouveau. Avec SP, c'est toujours le même qui prend la tâche.

Amp Tanawat
la source
-1

Je suis surpris que personne n'ait encore mentionné la loi de Parkinson .

Les travaux se développent de manière à occuper le temps disponible pour les terminer.

Fondamentalement, si vous estimez dans n'importe quel type d'unité de temps pour de grandes tâches, les développeurs auront tendance à prendre le temps estimé pour le terminer ou le dépasser. Lorsque vous estimez en une période nébuleuse comme les points d’histoire ou les tailles de chemise, vous évitez ce piège.

Vadim
la source
1
"Lorsque vous estimez à un moment aussi nébuleux que les points de scénario ou les tailles de maillots, vous évitez cet écueil." deux semaines entières et réglez la vélocité à 5 points d’histoire par semaine. Je pense que l'augmentation de la productivité a plus à voir avec la motivation de l'équipe et les conditions de travail qu'avec l'unité utilisée pour mesurer la complexité des tâches.
Giorgio
Je ne parlais pas d'augmentation de la productivité, mais plutôt du fait que si une estimation pour une histoire sortait à 3 jours. Un développeur est beaucoup plus susceptible de prendre 3 jours ou plus pour le terminer, que de se plier à l'estimation.
Vadim
Existe-t-il de bonnes preuves pour la loi de Parkinson? La page Wikipedia ne semble pas en mentionner.
bdsl
-2

L'estimation du point de l'histoire suit la série de fibonacci 1,2,3,5,8,13,21 ...

Un cerveau humain peut facilement cartographier les choses en fonction de leurs tailles. Par exemple: nous avons une carte postale et lui attribuons un point d'histoire 2 et la taille de trois cartes postales signifierait 2 * 3 = 6 points d'histoire.

Le point de récit 6 se situe entre les séries 5 et 8 de fibonacci, 5 étant le nombre le plus proche et, par conséquent, le point de stockage serait 5.

ecoGreen
la source
1
Nous ne mappons pas les objets en fonction de leur taille, nous utilisons en fait la mémoire de travail pour les traiter comme des "schémas" à partir desquels travailler. Un peu comme si notre cerveau avait une petite quantité de mémoire RAM que lorsque nous introduisions dans de petits motifs perceptibles (Fibonacci, A000079, tailles de t-shirts, etc.), ceux-ci peuvent faire appel à nos pouvoirs cognitifs intrinsèques pour ensuite aider à se projeter dans ce cas - une réponse. . qui est vraiment un modèle de "prévision relative".
Scott Barnes