Quelle est la meilleure explication de ce que sont les Story Points?
Nous commençons à utiliser les Story Points ici pour notre développement Agile, mais je trouve cela difficile à expliquer et je ne trouve pas non plus de réponse définitive à ce qu'ils sont. La meilleure chose que je puisse faire est de pointer vers d'autres sites (comme 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 entrée: Mike Cohn sur les points d'histoire . Mais celui-ci est bien meilleur: Équipes de développement Agile: portée et échelle avec Mike Cohn
La solution de Mike aux mesures d'estimation logicielle est simple et efficace. Faits biologiques:
- Le cerveau humain est tout simplement incapable d'estimer correctement le temps. Surtout si plus de quelques heures.
- Ceci est grandement amplifié par la quantité d'incertitudes chez les développeurs de logiciels, les pressions psychologiques de la direction (lorsque vous estimez, vous vous engagez ...) et les différences de compétences au sein de 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 user story de référence , puis de lui donner un nombre arbitraire de (story) points , alors d'autres histoires obtiendront des points liés à cette référence.
Si votre histoire de référence est de 100 points, et une autre histoire est trois fois plus grande, alors ce sera 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 accumulés par votre équipe dans un laps de temps donné.
Cela fonctionne .
Je suis d'accord avec tout @Pierre 303: dit ci-dessus: (à part le point de référence 100).
La seule chose que j'aimerais ajouter (souligné), c'est que nous ne sommes pas bons pour estimer les tâches. Nous pouvons estimer les tâches par rapport à d'autres tâches tant qu'elles sont à peu près de la même taille. Plus la différence entre les tâches est grande, pire nous obtenons.
Je suis donc en désaccord avec l'utilisation d'un point de départ de 100.
Ce n'est pas comme si vous estimiez la tâche suivante à 42% de la tâche de référence. C'est soit la même moitié du travail double le travail triple le 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 les 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 (petit (1), moyen ( 2), grand (3), XLarge (4) quand ils ont calculé la vitesse, cela fonctionnait toujours.).
Le fait est qu'à mesure que la taille de la tâche augmente par rapport à la tâche de référence, nous devenons moins capables d'estimer avec précision son coût. Il est donc inutile d'essayer. Cela se traduit par le gradient plus important à la fin de la piste d'estimation.
Donc, si votre tâche de référence est 2SP. Faire une estimation de 1/2/3/5 est alors relativement facile 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 (Is 8/9/10SP importe-t-il) Tout ce que vous pouvez dire est que sa taille est supérieure à 5SP et inférieure à 13SP, puis 8SP correspond à la facture.
Tout ce qui a une valeur SP 13/21/Énorme est trop grand pour le backlog de sprint. Ce sont des estimations pour des choses sur lesquelles vous n'êtes pas encore prêt à travailler (et qui ne sont donc pas décomposées en tâches plus petites (ne les décomposez pas tant que vous n'en avez pas besoin)). Mais elles vous donnent une estimation de la taille d'une tâche dans le backlog de produit (ce qui permet une planification future). Au moment où vous arrivez au point où vous allez travailler dessus, vous devez avoir suffisamment de connaissances pour les diviser en tâches plus petites pour le backlog de sprint et les réestimer individuellement (Remarque: c'est une idée fausse courante que la somme des parties est égale à l'original).
- Tout ce que vous estimez énorme doit être décomposé en tâches plus petites.
- Quelque chose qui est estimé comme? signifie qu'il n'est pas suffisamment bien défini pour estimer
Vous devez ajouter une tâche spécifiquement pour aller définir la tâche
(c'est-à-dire rédiger de la documentation ou une présentation).
Ils sont une perte de temps.
http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/
Intéressant que cette opinion vienne maintenant du gars qui a écrit Scrum et XP des tranchées et dont le nom de l'entreprise ( Crisp ) peut être trouvé sur tant de decks de planification de cartes de poker utilisées par tant d'équipes à travers le monde.
La dernière phrase du PO: "Existe-t-il de bonnes ressources pour expliquer les points d'histoire?" Oui, ce livre est une bonne ressource. Nourriture pour la pensée.
Les points d'histoire sont une mesure relative de la difficulté d'une tâche. En effet, les humains sont en fait meilleurs aux estimations relatives qu'aux mesures précises.
La façon dont vous utilisez les récits consiste à effectuer environ deux tâches sur le projet et à leur affecter deux valeurs de récit différentes. Ensuite, vous estimez les autres tâches en utilisant ces deux approximations de points d'histoire comme base pour votre estimation. C'est à dire. La tâche C n'est pas beaucoup plus difficile que la tâche A, mais incroyablement plus facile que la tâche B, ce n'est donc que 2 points d'histoire de plus que la tâche A.
Lorsque vous avez terminé d'estimer toutes les exigences que vous avez jusqu'à présent, vous estimez ensuite combien vous pouvez en faire dans un sprint. Au cours des prochains sprints, vous estimez combien vous en avez terminé. Les points d'histoire d'une exigence ne sont comptés comme achevés que si l'exigence est remplie. Il n'y a pas de "80% terminé" dans Scrum. En effet, les humains sont en fait mal à 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 planning poker pour déterminer le travail que vos développeurs estiment qu'une exigence exigera par rapport à vos exigences de base.
Je recommanderais également de lire The Agile Samurai . À mon avis, il explique bien ces concepts et d'autres concepts Agiles.
Comme d'autres l'ont mentionné, les points d'histoire sont une mesure relative de la complexité d'une histoire d'utilisateur. Le véritable avantage des points d'histoire est réalisé lorsque
- Les points sont mesurés par l'unité responsable de la mise en œuvre (soit un individu, soit l'équipe).
- Les mesures sont conservées pour le nombre de points agrégés terminés par la même unité dans une durée constante (vitesse).
Après quelques itérations de mesure des points d'histoire et de suivi de la vitesse, vous devriez être en mesure d'estimer avec précision le nombre de points d'histoire pouvant tenir dans un intervalle de temps donné (itération ou sprint si vous utilisez Scrum). Notez qu'appliquer cette technique à un groupe et essayer d'utiliser ces métriques pour une autre équipe ne fonctionnera pas bien. C'est si l'équipe a peut compléter 120 points d'histoire dans un sprint de deux semaines, il n'est pas réaliste de s'attendre à ce que l'équipe b ait les mêmes résultats.
Comme quelqu'un d'autre l'a mentionné, la planification du poker est d'une grande aide lors de l'utilisation de cette méthode, car elle aidera à identifier les histoires qui doivent être affinées (s'il y a un écart entre les votes, cela signifie qu'il y a une incertitude dans les exigences).
L'explication la plus simple que je peux trouver est d'utiliser un objet tangible et qui peut fournir un exemple concret.
Prenez une maison mobile. Si j'étais dans l'entreprise de mobil-home, je saurais que la construction d'un seul large prend généralement 5 (points, grenouilles, widgets ... la forme de mesure est arbitraire) et donc la construction d'un double large devrait prendre environ le double de l'effort ou 10 (points , grenouilles, widgets).
La mentalité des programmeurs interviendra à ce stade et parlera 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. Harp sur le fait qu'il s'agit d'une estimation en (points, grenouilles, widgets) car nous ne pouvons JAMAIS estimer avec précision dans le temps et donc estimer en (points, grenouilles, widgets) enlève la croyance que nous le pouvons.
Pour savoir combien de temps il faudra pour construire, nous utiliserons nos tendances au fil du temps; ainsi au fil du temps de plus en plus précis dans nos estimations.
N'oubliez pas planifier le poker quand l'équipe est prête à partir.