Pourquoi utilisons-nous des points d'histoire au lieu de jours-hommes lors de l'estimation des histoires d'utilisateurs?
Dans les méthodologies agiles (par exemple SCRUM), la complexité/l'effort requis pour les user stories sont mesurés en points Story. Les points d'histoire sont utilisés pour calculer le nombre d'histoires utilisateur qu'une équipe peut prendre dans une itération.
Quel est l'avantage d'introduire un concept abstrait (points d'histoire), où nous pouvons simplement utiliser une mesure concrète, comme les jours-hommes estimés? Nous pouvons également calculer la vitesse, estimer la couverture d'une itération, etc. en utilisant les jours-hommes estimés.
En revanche, les points d'histoire sont plus difficiles à utiliser (car le concept est abstrait), et aussi plus difficiles à expliquer aux parties prenantes. Quel avantage cela offre-t-il?
Je pense que l'un des principaux avantages est que les humains et les développeurs en particulier 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 "écrire 90% du code en 10 minutes puis arracher les cheveux en déboguant pendant 17 heures". C'est assez difficile à estimer dans le sens de la synchronisation d'horloge.
Mais l'utilisation d'une abstraction détourne l'attention du temps réel en heures ou en jours et met plutôt l'accent sur la description des dépenses relatives et de la complexité d'une tâche par rapport à d'autres tâches. Les humains/développeurs sont meilleurs dans ce domaine. Et puis, une fois que vous obtenez fredonner avec ces estimations ponctuelles et certains progrès réels, vous pouvez commencer à regarder le temps de façon plus empirique.
Je soupçonne qu'il y a aussi 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 à mettre en sac une estimation et à livrer "en avance sur le calendrier" va être mise en sourdine avec indirection dans un système basé sur des points.
Si vous utilisez des nombres de Fibonacci (ou quelque chose de similaire), cela limite le nombre d'options lors de l'estimation d'une histoire. J'ai travaillé avec un groupe qui n'utilisait que des nombres faibles: 1, 2, 3, 5, 8 et 13. Nous avions une histoire de référence qui était un 5. Cela nous a permis de prendre facilement des décisions instantanées sur la complexité d'une histoire tout en faisant Planning Poker . L'autre effet secondaire était que tout élément noté 13 ne disposait probablement pas d'informations suffisantes et devait être ventilé davantage. Je doute sérieusement que cela aurait été aussi simple et direct si nous avions utilisé des heures brutes.
Votre Product Owner parle la langue de vos parties prenantes et devrait être capable de traduire entre les points d'histoire et les heures de travail (ou d'autres unités) selon les besoins. Pendant mon mandat de PO, je disposais de données précises selon lesquelles 1 point d'histoire = 4 heures-homme, mais évidemment chaque équipe est différente.
Modifier:
Sachant qu'un point = 4 heures, vous pouvez théoriquement changer 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 pour revenir à quelque chose de simple, par exemple, "moins d'un jour", "plus d'une semaine", etc. Et si je vais le faire, je pourrais aussi bien m'en tenir à l'unité abstraite sans histoire.
C'est pour permettre à l'estimation de s'améliorer avec le temps, sans que les estimateurs aient tous à ajuster leur estimation.
Plutôt que tout le monde impliqué dans l'estimation devant penser comme "OK .. ressemble à 2 jours-homme .. mais le dernier sprint nous avons tout sous-estimé, alors peut-être que c'est vraiment 2,5 jours-homme. Ou 3?", Ils continuent comme toujours. "5 points d'histoire!"
Ensuite, vous ajustez votre estimation du nombre de points d'histoire que l'équipe peut franchir dans un sprint, en fonction de la réussite réelle mesurée lors des sprints précédents. "Nous avons déjà fait 90-110 points d'histoire par sprint!"
Je dirais que la théorie derrière cela est que les développeurs sont meilleurs pour estimer la complexité relative des différentes tâches de développement que pour estimer absolus . Surtout si plusieurs personnes estiment une tâche qui pourrait être effectuée par n'importe lequel d'entre eux (et que tout le monde ne travaille pas à la même vitesse que tout le monde).
Alternative cynique: J'ai vu qu'il était dit que les développeurs ne sont jamais soumis à des estimations de temps. Si quelque chose prend plus de temps que prévu, vous êtes passé. Mais si quelque chose prend moins de temps que prévu, les développeurs peuvent jouer avec, or-plaque, ou simplement ralentir et se détendre car ils ont été étant donné une affectation confortable. La suppression des unités de temps réelles d'une estimation peut freiner ces tendances. Fin de l'alternative cynique.
Les jours ou les heures sont, comme vous le dites, concrets. Ainsi, lorsqu'une tâche est estimée à 5 heures et prend 6 heures, c'est désormais une tâche tardive.
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, cela n'a pris que six heures. La mesure de la vitesse dépend plus du nombre de ces points que vous effectuez dans un sprint, et ce nombre peut fluctuer, car ce 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 sur chaque tâche, la tentation est là pour mesurer chaque tâche. Lorsque cela se produit, vous n'obtenez aucun avantage pour le sprint pour terminer sous le temps et 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. Un endroit où je travaillais avant même d'introduire des tailles de t-shirts agiles utilisé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'y a pas de controverse ou d'assignation arbitraire aux points. Nous avons des membres de notre équipe qui votent presque toujours le plus petit nombre, et se plaignent quand ils pensent qu'une tâche est un 1 et nous pensons que c'est un 3 que nous souffrons d'inflation ponctuelle.
L'abstraction est en quelque sorte le point. L'utilisation du "jour de l'homme" comme mesure présente un certain nombre d'embûches, notamment:
- Si l'équipe ne connaît pas la technologie qu'elle va utiliser, il peut être très difficile de donner des estimations 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 de temps que la tâche B".
- Différentes personnes travaillent à des taux différents! Si vous utilisez des "jours-homme", vous devez à peu près changer l'estimation du temps lorsqu'une tâche est passée d'un développeur à un autre. Qui définit de toute façon combien de travail constitue une "journée de l'homme"?
Si vous voulez estimer les jours-hommes, c'est un calcul simple:
user points in story / average user points per developer per day = estimated man days
Comme déjà mentionné, les points d'histoire sont une mesure relative de la complexité. On peut utiliser la 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 épousés sont tout à fait capables de dire quelque chose comme ceci:
La fonctionnalité A est presque deux fois plus difficile que la fonctionnalité B
Mais il est vraiment difficile de dire "combien de temps" cette fonctionnalité prendra-t-elle pour sa mise en œuvre. Vous laissez cela être équilibré par la vitesse. Donc, si quelque chose était estimé à 5 mais se révélait ê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, elle s'appelle les `` jours idéaux '' (certains ressemblent aux jours-hommes mais je ne sais pas si c'est ce que vous vouliez dire) et je connais pas mal d'équipes qui préfèrent cela. Les jours idéaux doivent être interprétés comme:
Si c'est tout ce que je fais après être arrivé au bureau et ne prendre que les pauses nécessaires, ne pas avoir d'interruptions et avoir tout ce dont j'ai besoin pour `` mettre en œuvre l'histoire '', c'est-à-dire pas d'activités périphériques comme les réunions, répondre aux mails, etc.,
Mike Cohn, l'un des nombreux évangélistes agiles bien connus fournit la comparaison suivante entre les points d'histoire et les jours idéaux
Points d'histoire
- Aide à stimuler le comportement interfonctionnel, c.-à-d. Que les équipes estiment les histoires sans poids. complexité totale de l'implémentation de l'interface utilisateur à la base de données et inversement.
- Les estimations de SP ne diminuent pas, c'est-à-dire que dans quelques mois, une histoire de 5 points est toujours susceptible d'être de 5 points, mais une estimation de jour idéal peut changer en fonction des compétences/vitesse de développement acquises de ce programmeur particulier
- Les SP sont une mesure pure de la taille, c'est-à-dire qu'ils reflètent uniquement la taille par rapport à la taille. complexité. Période. Pas de durée, etc., jeté. C'est le travail de la vitesse. Mais pas avec des jours idéaux. En fait, avec les jours idéaux, il y a une tendance à l'embrouiller avec les jours civils. Le garder abstrait alors que les SP combattent la tentation de comparer avec 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 difficile pour les deux premières histoires, mais une fois que vous avez compris, c'est plus rapide.
- Différents développeurs peuvent avoir une vision différente de leur estimation du jour idéal pour terminer une histoire. Je pourrais faire de même en 3 et vous pourriez en 5. Les SP sont plus ou moins uniformes à tous les niveaux. Ils égalisent les règles du jeu pour ainsi dire.
Jours idéaux
- Plus facile à expliquer en dehors de l'équipe; pour des raisons évidentes :)
- Plus facile à estimer dans un premier temps 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 jours idéaux n'ont pas vraiment beaucoup d'avantages sur les SP (et Mike Cohn préconise également SP avec de nombreux autres évangélistes agiles).
Les récits vous aident également à mesurer l'amélioration des performances de l'équipe au fil du temps. De plus, vous n'avez pas besoin de tout réévaluer à mesure que les performances s'améliorent.
Prenez cet exemple qui utilise les jours-hommes:
L'équipe estime différentes tâches avec des jours-hommes. Cela fonctionne pendant un certain temps, mais après un certain temps, vous voyez que l'équipe se fait plus rapidement avec de nombreuses tâches que prévu à l'origine. Donc l'équipe ré-estime 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 à nouveau. 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 le savez pas.
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 voyez que l'équipe a atteint plus de 60 points d'histoire, peut-être 70. Et l'équipe continue comme ça et tire plus d'histoires d'utilisateurs pour les prochains sprints et les livre.
Pourquoi? Parce que les performances ont augmenté. Et vous pouvez le mesurer. Et vous n'avez pas besoin de tout réévaluer une fois que les performances de votre équipe ont augmenté.
Premièrement, les gens sont meilleurs aux estimations relatives qu'aux estimations absolues. Les babyloniens cartographiant et évaluant la luminosité relative des étoiles en sont un excellent exemple. Ils n'ont pas obtenu les bons chiffres absolus, mais la commande était surtout sur place même pour des intensités très similaires.
Le deuxième avantage est qu'une des principales raisons de faire cet exercice est de conduire la conversation. Si vous commencez à discuter dans les jours exacts, la conversation peut rapidement dérailler.
Comme l'a dit Napoléon: le plan ne vaut rien, la planification est inestimable.
Troisièmement, le gestionnaire de projet n'a pas à modifier toutes les estimations, simplement parce qu'il s'avère que les estimations étaient faussées d'un facteur, par exemple, 130%.
jours-homme estimer 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 reproductibles sont estimables en jours-homme.
Par exemple, si un vendeur peut effectuer 20 appels clients par jour, en moyenne, nous pouvons calculer le temps nécessaire à chaque appel et à partir de cela, nous pouvons estimer le nombre de jours-homme nécessaires pour effectuer 1000 appels.
Dans cet exemple, on peut concrètement penser en termes statistiques à la durée médiane d'un appel car tous les appels peuvent être supposés être effectivement la même chose.
Points d'histoire déterminez quelle combinaison d'histoires peut être effectuée 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 fixe. Ils estiment la complexité des morceaux de travail les uns par rapport aux autres afin de pouvoir les additionner.
Par exemple, votre équipe a développé 5 histoires pour un total de 23 points dans l'itération 1, et 8 histoires pour 20 points dans l'itération 2. De cela, vous pouvez estimer que dans l'itération 2, votre équipe fera quelques histoires dont le total est d'environ 20 points dans l'itération 3.
Notez que nous n'avons pas besoin de déterminer la taille d'un point et en particulier il n'y a aucune hypothèse que chaque histoire de la même taille prendra le même temps pour être développée! Nous ne travaillons que sur des sommes et sur des points par itération. Je n'ai même pas mentionné la durée de l'itération.
Je suis surpris que personne n'ait mentionné loi de Parkinson pour l'instant.
Le travail se dilate de manière à remplir le temps disponible pour sa réalisation.
Fondamentalement, si vous effectuez une estimation 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 passer à autre chose. Lorsque vous estimez dans un temps nébuleux comme les points d'histoire ou les tailles de chemise, vous évitez cet écueil.
Les Story Points reflètent la complexité du problème et, par conséquent, reflètent la confiance (ou le risque) dans la précision de l'estimation.
Une histoire avec un point d'histoire élevé me dit qu'il se passe beaucoup de choses avec l'histoire utilisateur qui n'est pas concrète.
L'idée est de voir ce qui est un bon équilibre entre différents points d'histoire. Si on me montre un plan d'itération avec des histoires avec tous les points d'histoire élevés, cela me donne peu de confiance que l'itération sera exécutée comme prévu et que nous devons regarder d'autres histoires pour l'itération ou commencer à décomposer les histoires.
Lorsque vous communiquez avec un gestionnaire ou un propriétaire de produit, les points forts signifient qu'il sera extrêmement flou de savoir quand ils obtiendront une fonctionnalité particulière. L'une des solutions à cela est de décomposer l'histoire et, espérons-le, vous aurez une combinaison de points d'histoires bas et élevés pour travailler afin que vous puissiez démontrer de manière itérative les progrès au propriétaire du produit.
Si vous vous approchez d'un humain dans la rue et demandez "Quelle était la taille d'un T-rex?" les réponses fluctueraient même si la majorité des humains savent ce qu'est un T-rex, sa taille, mais personne ne sait vraiment avec certitude - parce que nous n'avons AUCUNE échelle relative par rapport à la référence.
C'est le comportement cognitif que vous essayez de comprendre avec les prévisions et de nombreuses méthodologies tournent les cycles avec " Je l'ai! .. j'ai le secret d'une prévision précise! "huile de serpent pour les masses. Lorsque vous effectuez des prévisions, vous dites en réalité à haute voix " JE PERMETTRE x jours/heures/points pour que cela se termine "- c'est en quelque sorte la création d'une" boîte de temps "pour que cet événement se déroule à l'intérieur.
Pour moi, Points ne fait que déplacer les limites, à la fin de la journée, sauf si vous êtes dans une équipe qui est heureuse de dire "* Eh bien, nous avons 3 semaines par sprint, et pouce sucé ... je pense que nous devrions viser 30 points pour terminer dans ce cycle! qui est avec moi! * "et c'est aussi profond que vous allez dans la modélisation des prévisions - bien! ..as réaliste vous fixez juste un budget arbitraire et c'est tout. Vous êtes également en train de regarder rétrospectivement le travail accompli avec un sentiment de "merde sacrée, nous avons fait 33pts ce sprint, c'était plutôt cool" et on ne peut pas faire grand-chose à ce sujet. Vous pouvez utiliser la vélocité pour déterminer au milieu du sprint que vous en avez pour votre budget en demandant à voix haute " Avons-nous déjà frappé 15pts? Allons-nous" mais ensuite revenez à l'ajout temps relatif à l'équation n'est-ce pas? "mais le danger ici est que vous utilisez maintenant Velocity pour mesurer la productivité et non la capacité qui, d'après ce que je comprends, lance la gestion des versions réactives ( points d'histoire) 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 standups quotidiens dans lesquels vous édictez une règle cachée autour de la durée + complexité = "( Max prend trop de temps avec cette tâche "instinct inné sentant le code d'équipe moment rouge?
Le cerveau humain ne peut pas prévoir car il implique beaucoup de mémoire de travail mélangée à un rappel à long/court terme, donc c'est comme demander à un étudiant en mathématiques novice de faire des fractions dans sa tête et non sur papier. C'est pourquoi les autres industries ne s'entendent jamais sur une prévision et valider constamment les prévisions en temps relatif (par exemple, le géologue n'arrête jamais de modéliser les prévisions tant que ce mètre cube n'a pas été extrait du sol, puis "terminé").
Je dirais que le système de points fonctionne si vous ne prévoyez pas. Vous acceptez un morceau de travail basé sur un algorithme de sous-segmentation, mais c'est vraiment votre approche la plus proche de la prévision que possible. En fait, votre gestion des versions rechercherait des ruptures naturelles dans la file d'attente "backlog" qui correspondent aux thèmes (par exemple, dans Silverlight, nous, les chefs de produit, attendrions après avoir terminé leur backlog et reconstituer les thèmes que nous avons initialement définis. Nous nous ne savions jamais ce que l'équipe d'ingénierie faisait précisément, nous avions juste un aperçu de base. Nous prenions ensuite ce travail et construisions notre événement marketing autour de lui (Microsoft Mix))
Lorsque vous commencez à verrouiller les attentes de vélocité dans les cycles de sprint qui dépendent de la vélocité + du temps, vous ne recommencez à prévoir les estimations que cette fois, votre situation est pire parce que vous jouez au jeu "ça dépend" ... Plus important encore '' tue également le potentiel de croissance d'équipe/de croissance de carrière.
La taxe que vous payez pour les points vs le temps est avec des points dont vous avez besoin pour rechercher des formules de mesure alternatives pour suivre le développement des compétences/le mentorat ou le comportement du développeur.
Comme vous aurez toujours besoin de considérer un "développeur médian" comme votre personne idéale pour attacher des compétences/efforts, vous pouvez ensuite basaliser d'autres développeurs avec cette personne pour déterminer comment ils se comportent dans leur croissance continue au sein de votre équipe. Il met également en évidence les situations où les développeurs "rapides" transportent la majeure partie de l'eau mais s'ennuient ou pire, ils travaillent plus d'heures et aucune reconnaissance/récompense en raison des délais concurrents, etc. Les standups ne révèlent pas cela en réalité, ils sont vraiment là pour détecter les mauvaises odeurs au sein de l'équipe, disons, comme dans "cette personne est en difficulté, permet d'aider"
Viennent ensuite les histoires de "report", des histoires qui ne sont pas fragmentées dans ce cycle de sprint mais qui se répercutent ensuite sur le cycle de sprint suivant. Ce qui peut alors facilement créer un effet d'entraînement si vous tenez compte du temps, mais au moment où vous tenez compte du temps relatif ... encore une fois, vous venez de revenir à la "prévision/estimation basée sur le temps" et encore une fois le système de points est juste brouiller les eaux.
Si vous allez des points, vous ignorez complètement le temps et je veux dire complètement comme le moment où vous laissez le temps glisser dans votre jeu l'idée/méthodologie.
Ayant voyagé à travers le monde en tant qu'évangéliste, j'ai vu beaucoup d'équipes jurer à tout ce qui leur tenait à cœur qu'elles avaient déchiffré le code Agile Forecast ... mais j'ai toujours cliqué sur ma langue, souri et je suis partie avec la pensée "- ouais ... tu l'as presque fait, mais cette maîtresse que nous appelons "le temps" ... elle est juste cruelle ... "