Quelle est la meilleure explication de ce que sont les Story Points?

Nous commençons à utiliser les points d’histoire ici pour notre développement Agile, mais j’ai du mal à expliquer et aussi à trouver une réponse définitive à ce qu’ils sont. La meilleure chose que je puisse faire est de pointer vers d'autres sites (tels que http://blog.mountaingoatsoftware.com/tag/story-points ) et de donner une vague généralisation de ce qu'ils sont. Je cherche une bonne explication avec quelques exemples d'utilisation qui pourraient être utiles à d'autres. Existe-t-il de bonnes ressources pour expliquer les points de l'histoire?

Cela peut aider en tant que démarreur: Mike Cohn sur les points d’histoire . Mais celui-ci est bien meilleur: Équipes de développement agiles: portée et échelle avec Mike Cohn

La solution de Mike aux métriques d'estimation logicielle est simple et efficace. Faits biologiques:

• Le cerveau humain est tout simplement incapable d'estimer à temps correctement. Surtout si plus que quelques heures.
• Ceci est grandement amplifié par le nombre d'incertitudes chez les développeurs de logiciels, les pressions psychologiques de la direction (lorsque vous estimez, vous vous engagez ...) et la différence de compétences dans l'équipe.
• Cependant, nous sommes assez bons pour comparer des choses. Nous sommes assez précis là-bas.

L'idée est de prendre une histoire d'utilisateur de référence , puis de lui attribuer un nombre arbitraire de points (histoire) . Les autres histoires obtiendront des points liés à cette référence.

Si votre histoire de référence est de 100 points et qu'une autre est trois fois plus grande, elle sera de 300 points.

Pour convertir des points d’histoire en temps pour votre planification, vous devez connaître votre vitesse .

Pour obtenir une vélocité précise, vous devez effectuer quelques itérations et calculer le nombre de points obtenus par votre équipe dans un laps de temps donné.

Ça marche .

Je suis d'accord avec tout @Pierre 303: dit ci-dessus: (à part le point de référence 100).

La seule chose que je voudrais ajouter (souligné) est que nous ne sommes pas doués pour estimer les tâches. Nous pouvons estimer les tâches par rapport à d'autres tâches tant qu'elles ont à peu près la même taille. Plus la différence entre les tâches est grande, plus la situation empire.

Je ne suis donc pas d'accord avec l'utilisation d'un point de départ de 100.

Ce n'est pas comme si vous estimeriez la tâche suivante à 42% de la tâche de référence. C'est soit la même moitié du travail, soit le double du travail, triple du travail, etc.

Notre équipe utilise Planing Poker : En cela, nous avons une tâche de référence de 2 points d’histoire. Nous utilisons ensuite la série de Fibonacci pour estimer les tâches: 1,2,3,5,8,13,21, Énorme ,? par rapport à la tâche de référence (plutôt que le Fibonacci, j’ai vu d’autres équipes utiliser des pouvoirs de 2. 1,2,4,8,16,32, énorme ,?) j’ai vu d’autres équipes utiliser (petite (1), moyenne ( 2), large (3), XLarge (4) quand ils calculaient la vitesse, cela fonctionnait toujours.).

Le fait est que, à mesure que la taille de la tâche augmente par rapport à la tâche de référence, nous devenons moins en mesure d’estimer avec précision son coût. Donc, il ne sert à rien d'essayer. Ceci est reflété par le plus grand gradient à la fin du chemin d’estimation.

Donc, si votre tâche de référence est 2SP. Il est relativement facile d'estimer le 1/2/3/5, car les tâches sont de taille similaire. Une fois que vous avez dépassé 3 fois la taille de la tâche de référence (5SP), l'estimation devient plus difficile (8/9 / 10SP importe-t-il)? Tout ce que vous pouvez dire, c'est que sa taille est supérieure à 5SP et inférieure à 13SP, alors que 8SP convient parfaitement.

Tout ce qui a une valeur SP de 13/21 / énorme est trop gros pour le backlog de sprint. Il s'agit d'estimations pour des tâches sur lesquelles vous n'êtes pas encore prêt à travailler (et ne sont donc pas décomposées en tâches plus petites (ne les décomposez pas jusqu'à ce que vous en ayez besoin aussi)). Mais ils vous donnent une estimation de la taille d'une tâche dans le backlog du produit (ce qui permet une planification future). Au moment où vous allez travailler sur eux, vous devriez avoir suffisamment de connaissances pour les diviser en tâches plus petites pour l'arriéré de sprint et les ré-estimer individuellement (Remarque: c'est une idée fausse commune que la somme de les parties sont égales à l'original).

• Tout ce que vous estimez énorme doit être divisé en tâches plus petites.
• Tout ce qui est estimé comme? signifie qu'il n'est pas assez bien défini pour estimer
  Vous devez ajouter une tâche spécifique pour la définir
  (c.-à-d. rédiger de la documentation ou une présentation).

Les points d'histoire sont une mesure relative de la difficulté d'une tâche. En effet, les humains sont en fait meilleurs en estimations relatives qu'en mesures précises.

La manière dont vous utilisez les points d’histoire consiste à prendre deux tâches du projet et à leur attribuer deux valeurs de points d’histoire différentes. Ensuite, vous estimez les autres tâches en vous servant de ces approximations de deux récits. Par exemple, la tâche C n’est pas beaucoup plus difficile que la tâche A, mais incroyablement plus facile que la tâche B, c’est donc environ 2 points d’histoire plus de travail que la tâche A.

Une fois que vous avez terminé d’estimer toutes les exigences que vous avez jusqu’à présent, vous estimez ensuite le nombre de tâches que vous pouvez accomplir dans un sprint. Au cours des prochains sprints, vous estimez combien vous avez terminés. Les points de récit d'une exigence ne sont considérés comme terminés que si l'exigence est remplie. Il n'y a pas "terminé à 80%" dans Scrum. C'est parce que les humains sont en fait mauvais pour estimer l'exhaustivité. Après quelques sprints, vous devriez avoir une idée du nombre de points d'histoire que vous pouvez faire par sprint.

Comment estimez-vous? Vous pouvez utiliser la planification du poker pour déterminer le travail que vos développeurs estiment nécessaire, par rapport à vos exigences de base.

Je recommanderais également de lire The Agile Samurai . À mon avis, il explique très bien ces concepts et d’autres concepts agiles.

Voici un lien avec plus de points d'histoire.

Voici un autre lien.

Ils sont une perte de temps.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Il est intéressant de noter que cette opinion vient maintenant du type qui a écrit Scrum et XP de The Trenches et dont le nom de société ( Crisp ) figure sur de nombreux jeux de cartes de planification utilisées par de nombreuses équipes du monde entier.

La dernière phrase du PO: "Existe-t-il de bonnes ressources pour expliquer les points de l'histoire?" Oui, ce livre est une bonne ressource. Nourriture pour la pensée.

L'explication la plus simple que je puisse trouver est d'utiliser un objet qui est tangible et qui peut fournir un exemple concret.

Prenez un mobil home. Si je travaillais dans le secteur des maisons mobiles, je saurais que construire un seul large nécessite généralement 5 (points, grenouilles, widgets ... la forme de mesure est arbitraire) et que, par conséquent, construire un double large devrait prendre environ le double de l'effort ou 10 (points). , grenouilles, widgets).

La mentalité des programmeurs commencera à parler d’une approche rationalisée; cela ne prend pas deux fois plus de temps en raison de l'infrastructure consommant la plus grande partie du temps et d'autres exemples similaires. C'est inévitable. Le fait de dire qu'il s'agit d'une estimation en (points, grenouilles, widgets) étant donné que nous ne pouvons JAMAIS effectuer une estimation précise dans le temps et que, par conséquent, l'estimation en (points, grenouilles, widgets) élimine la conviction que nous pouvons le faire.

Pour savoir combien de temps il faudra pour construire, nous utiliserons nos tendances au fil du temps; ainsi, avec le temps, nos estimations deviennent de plus en plus précises.

N'oubliez pas de planifier le poker lorsque l'équipe est prête à partir.

Comme d'autres l'ont mentionné, les points d'histoire constituent une mesure relative de la complexité d'une histoire d'utilisateur. Le véritable avantage des points d’histoire se réalise lorsque

1. Les points sont mesurés par l'unité responsable de la mise en œuvre (un individu ou l'équipe).
2. Les métriques sont conservées pour le nombre de points agrégés complétés par la même unité dans une durée constante (vélocité).

Après quelques itérations de mesure des points d’histoire et de vitesse de suivi, vous devriez être en mesure d’estimer avec précision le nombre de points d’histoire pouvant tenir dans un bloc de temps donné (itération ou sprint si vous utilisez Scrum). Notez que l'application de cette technique à un groupe et l'utilisation de ces métriques pour une autre équipe ne fonctionneront pas bien. C'est-à-dire que si une équipe peut compléter 120 points d'histoire en un sprint de deux semaines, s'attendre à ce que l'équipe b obtienne les mêmes résultats est irréaliste.

Comme quelqu'un l'a mentionné, la planification du poker est une aide précieuse lors de l'utilisation de cette méthode, car elle aidera à identifier les histoires qui doivent être encore affinées (s'il existe une divergence entre les votes, cela signifie qu'il y a une incertitude dans les exigences).