que sont les story points et comment les utiliser?

Les Story points sont un moyen courant d’estimer le travail en utilisant des frameworks agiles tels que Scrum et eXtreme Programming.

défis liés à l’estimation

lorsque les ingénieurs estiment le temps nécessaire pour accomplir une tâche, ils estiment souvent dans une journée d’ingénierie idéale. Malheureusement, les jours d’ingénierie idéaux n’existent pas. Si vous tenez compte du temps consacré à d’autres activités telles que Slack, e-mail, réunions et autres tâches administratives et non techniques s’ils ont de la chance, ils obtiendront 50% du temps productif.,

Parfois, le travail est facile à estimer. Les éléments qui ont un air de répétition, tels que la lecture de certaines données d’une base de données et leur affichage à l’écran, sont simples à comprendre et à estimer. Le travail répétitif ou similaire est également facile à estimer. Cependant, le développement de logiciels nécessite souvent des solutions sur mesure qui n’ont jamais été tentées auparavant (du moins pas par l’équipe qui effectue les estimations). Ils peuvent également avoir besoin de s’intégrer à des composants développés par d’autres groupes. À mesure que la complexité augmente, l’incertitude augmente également.,

lorsqu’on nous demande d’estimer quelque chose sur mesure ou complexe, nous sommes souvent trop confiants dans le temps qu’il faudra pour terminer la tâche. Un contributeur important à cela est le fait que nous ne pouvons pas prédire chaque étape qui pourrait être nécessaire. Les tâches apparaissent souvent au fur et à mesure que les travaux sont en cours, car des défis imprévus génèrent des étapes supplémentaires. Cet excès de confiance a pour conséquence de sous-estimer le temps et les efforts nécessaires pour faire le travail.

avantages de l’estimation

tout le monde n’aime pas l’estimation, et cela prend du temps et des efforts à faire. Compte tenu des coûts et des défis à relever pour bien le faire, pourquoi s’embêter?,
avantages pour les équipes de développement:

1. ils savent combien planifier dans un sprint pour pouvoir travailler à un rythme durable.
2. ils sont plus susceptibles de créer un incrément terminé en ne planifiant pas trop le sprint.
3. augmente la compréhension des exigences et de la stratégie de mise en œuvre par la discussion et l’élaboration

avantages pour les propriétaires de Produits:

1. ils doivent prévoir la livraison à long terme de leur produit.,
2. ils peuvent évaluer le « rapport qualité-prix » ou le « retour sur investissement » des articles
3. ils ont une visibilité sur les risques techniques associés aux gros articles

concepts critiques dans le story pointing

Le Story pointing rassemble plusieurs concepts

l’estimation Relative est plus facile que l’estimation absolue. Il est beaucoup plus facile de comparer deux éléments de backlog de produits et de dire que l’un est deux fois plus difficile que l’autre. Il est beaucoup plus difficile de penser combien de lignes de code une chose prend et donc combien de temps il faut pour coder et tester.,

L’utilisation de la diversité de toute l’équipe crée de meilleures estimations. Aussi connu comme la sagesse des foules. Les équipes apportent une diversité de pensées et d’opinions. Différents membres de l’équipe verront le même problème d’un point de vue différent, permettant une contribution plus large dans la discussion du problème. Un simple correctif de bogue peut ne prendre qu’une seule ligne de code à changer, mais de nombreuses heures de tests de régression. Si une seule opinion est prise en compte, la taille de l’article peut être très éloignée.

la précision et la compréhension diminuent à mesure que les éléments deviennent plus gros. La taille des diamants est mesurée en mm généralement à 1 décimale., La différence dans ce 0,1 mm supplémentaire peut être assez importante et mérite d’être discutée. En comparant cela à Jupiter, qui a un rayon moyen de 69911 km, il serait ridicule de discuter d’un 0,1 mm supplémentaire. les points D’histoire utilisent une échelle non linéaire telle que la séquence de Fibonacci, qui augmente les écarts entre les nombres à mesure qu’elle augmente. Il y a un 34 mais pas 33 ou 35.

Les points D’histoire ne concernent pas le temps qu’il faudra à tout individu pour faire le travail. Dans Scrum et XP, une personne n’est pas affectée au travail au point d’estimation., Toute l’équipe reste propriétaire de l’œuvre, ce qui signifie que tout membre de l’équipe peut la récupérer. Au lieu qu’un temps, histoire de points représentent une combinaison de taille, de complexité et de risque. Combien de travail peut être accompli dans le sprint est calculé en utilisant la vitesse de l’équipe (combien de points a-t-il terminé dans le sprint précédent).

approche

étalonnage

avant de commencer à estimer en points, toute l’équipe doit calibrer la valeur d’un point., Pour calibrer votre balance, choisissez un élément de l’arriéré qui est simple, et tout le monde dans l’équipe comprend et définit cela sur la balance. (par exemple 2 points). Pour améliorer encore votre étalonnage, trouvez un exemple plus haut sur l’échelle peut-être quatre fois plus grand et définissez-le comme un 8. L’étalonnage de l’échelle d’estimation améliorera considérablement votre succès avec l’estimation.

d’Accord sur la façon de gérer les différences

L’équipe de développement doivent s’entendre sur la façon dont ils vont gérer les différences dans les estimations. Combien de tours iront-ils et que devraient-ils faire si les estimations ne convergent pas., Pour obtenir les avantages de l’estimation de groupe, un minimum de deux tours fournira un dialogue pour démêler les hypothèses. L’animateur devra peut – être rappeler à l’équipe qu’il y a une valeur limitée dans de longs débats entre des estimations similaires-si l’équipe a du mal à s’entendre sur un 2 ou un 3, Choisissez-en un et passez à autre chose.

Réunion D’Estimation

La Réunion d’estimation se déroule comme suit:

1. Le Scrum Master, qui ne jouera pas, préside la réunion.
2. Le Product Owner fournit un bref aperçu d’un élément de backlog produit (PBI) à estimer., L’équipe de développement pose des questions et discute pour clarifier les hypothèses et les risques. Un résumé de la discussion est enregistré par l’équipe de développement.
3. chaque membre de l’équipe de développement compare la taille du PBI par rapport aux PBIs d’étalonnage et choisit leur estimation de taille. Au cours de la discussion, les nombres ne doivent pas être mentionnés du tout par rapport à la taille des entités pour éviter l’ancrage.
4. tout le monde appelle ses estimations simultanément. Seule l’équipe de développement peut estimer., Le propriétaire du produit est autorisé à demander pourquoi quelque chose est une certaine taille et peut entrer dans une négociation sur la portée qui peut affecter la taille d’un article.
5. Les personnes ayant des estimations élevées et des estimations basses offrent leur justification pour leur estimation, puis la discussion se poursuit. Au cours du débat, les hypothèses doivent être diffusées et le propriétaire du produit peut fournir des éclaircissements.
6. cette étape fait souvent apparaître une compréhension différente de la portée ou de la mise en œuvre, qui peut ensuite être clarifiée et convenue., La personne qui a donné un 2 peut connaître une solution facile, mais la personne qui a donné un 13 mai anticiper une difficulté à personne d’autre a pensé.
7. Répétez le processus d’estimation, jusqu’à ce qu’un consensus soit atteint. Ou une convergence suffisante est atteinte selon les propres règles des équipes de développement.

il ne s’agit pas des points

Le succès à la fin d’un sprint/itération n’est pas mesuré par le nombre de points terminés ou le ratio de points planifiés par rapport aux points réels obtenus. Le succès est mesuré par la valeur créée. Les Points sont un moyen d’aider à créer de la valeur, pas une fin en soi.