Estimation Agile dans Scrum ? Story Point et Planning Poker

Pour le propriétaire du projet ou du produit, il s’agit d’une information très importante pour leur mesure des ressources et des délais du projet, mais la pratique Cela a causé de nombreux problèmes.

De nombreux développeurs ont toujours l’impression que PM utilise la date limite pour faire des allers-retours. Ils ne se soucient pas de savoir si la fonctionnalité peut être finie en qualité.

Le « faites-le d’abord, puis cherchez mieux » circule donc depuis longtemps dans l’industrie du logiciel.

De nombreux chefs de projet ont toujours le sentiment que les développeurs ont le plus tendance à « exagérer » lorsqu’ils évaluent leur travail. Il semble qu’ils utilisent tous la méthode typique d’estimation du travail : « Estimer un triple du temps réel comme tampon » «

En fait, les heures de travail ne peuvent pas être estimées comme étant « absolument précises », mais il existe des moyens d’estimer « relativement objectivement ». En raison de la complexité des heures de travail et des exigences, il existe souvent une corrélation positive. Par conséquent, cet article expliquera d’abord les problèmes courants en réponse à la complexité des exigences, proposera une solution proposée et expliquera le but de nombreuses conceptions dans la solution.

Problèmes

Mine du développeur

« C’est très simple. Ça ne devrait pas prendre trop de temps pour le faire ?
PM vous a dit aujourd’hui : « Je dois le remettre avant demain. « Faites-le avant de rechercher la qualité »
PM vous a dit après-demain : « Pourquoi la qualité du programme est-elle si mauvaise ? »
Lorsqu’il a été retardé, d’autres collègues : « Comment avez-vous besoin de passer autant de temps ? Cela a un code prêt à l’emploi pour référence. Cela a une bonne couche inférieure à utiliser. Pourquoi ne m’as-tu pas demandé ?
D’autres collègues : « Je n’ai besoin que d’une journée, pourquoi avez-vous passé tant de jours ? »
« C’est du bon sens ! Si nous ne mentionnons pas l’exigence, vous devriez savoir quoi faire.

Mine de PM/PO

« Pourquoi est-ce si simple ? Ça prend tellement de temps ?
« Pourquoi voyez-vous que vous visitez Facebook, mais vous n’avez pas le temps de le faire? »
« Pourquoi la qualité des choses qui sont faites est-elle si mauvaise? »
« Pourquoi a-t-il réussi la dernière fois, combien de jours avez-vous à faire? »
Étant donné que les spécifications ou les exigences ne sont pas clairement écrites, le développeur est décrit comme un changement d’exigence.

Résultat

Hostilité de rôle : L’unité demande et l’unité développement ne sont plus là pour livrer un produit qui peut apporter des bénéfices à l’utilisateur, mais pour s’attaquer à leurs propres fins, afin d’éviter d’avoir à supporter des responsabilités supplémentaires. Par conséquent, la situation selon laquelle l’unité de la demande et l’unité de développement ne forment pas du tout une seule équipe.
Responsabilité : L’équipe pense que « je ne me trompe pas, donc le retard n’est pas de ma responsabilité », au lieu de prioriser les besoins des utilisateurs.
Gel de la demande : les développeurs sont obligés de modifier leurs exigences en raison de la pression des délais, sinon ils seront retardés et la responsabilité en incombera au développeur. Par conséquent, soit obligé de faire des heures supplémentaires pour produire quelque chose qui cache beaucoup de bugs, soit pour faire une sorte de fonctionnalité qui ne répond pas aux besoins des utilisateurs ; et les deux réduiront la satisfaction des utilisateurs.
Qualité médiocre : le statut des PM est souvent supérieur à celui des développeurs. Ainsi, afin de respecter l’échéance du contrat ou d’éviter des pénalités, etc., il sera demandé à l’équipe de « faire d’abord, puis chercher mieux », mais finalement c’est souvent « d’abord, il n’y a pas le temps de chercher bien .” L’accumulation de la dette technique augmente, et le résultat est le modèle de chaîne de responsabilité du monde réel, qui a la plus grande responsabilité et le plus grand coût à la toute fin de la chaîne. Ainsi, l’équipe est comme une pile, les développeurs ne peuvent pas se maintenir un par un, ce qui est l’un des facteurs pour lesquels les ingénieurs des sociétés de projet ont souvent des taux de rotation élevés.
Augmenter le poids du code : afin d’optimiser l’efficacité, la position de la personne la plus familière est toujours utilisée pour estimer les heures de travail, de sorte que la personne la plus familière avec le module et le processus sera toujours concernée par les exigences pertinentes . En fin de compte, seules ces personnes peuvent maintenir leur propre code, c’est comme une boîte de Pandore, on ne sait jamais quelles vaches et quels fantômes s’épuiseront après l’ouverture. Parce que la boîte noire est souvent sale, mais l’entreprise n’avait aucune idée de comment résoudre ce problème. Vous espérez également qu’il ne partira pas, sinon une partie du code ne sera pas comprise.

Solutions

La solution proposée ici est un moyen courant d’estimer la complexité des exigences dans Scrum, mais même s’il ne s’agit pas d’une équipe Scrum, il est recommandé que les lecteurs soient en mesure d’identifier la meilleure façon d’estimer votre équipe en fonction des principes et des objectifs de conception. .

Gardez à l’esprit que sans solution miracle, les meilleures pratiques de quelqu’un d’autre ne s’appliquent pas nécessairement à votre équipe, alors comprenez d’abord quel est le problème que votre équipe rencontre actuellement, puis découvrez ce qui vous convient pour résoudre le problème à partir de la pratique de quelqu’un d’autre. , tant qu’il n’engendre pas de nouveaux problèmes ou que le risque de coût d’un nouveau problème est acceptable.

L’unité utilisée ici pour estimer la complexité des exigences est le story point (unité relative), et non les heures de travail (unités absolues).

L’unité utilisée pour estimer la complexité de la demande est ici le story point (unité relative), et non le temps de travail (unité absolue). Il y a plusieurs raisons à cela :

1. Les comparaisons ne varient pas d’une personne à l’autre : la complexité des exigences ne varie souvent pas d’une personne à l’autre et le temps requis pour la pratique varie d’une personne à l’autre.

2. « Relatif » est plus facile à évaluer que « Absolu » : si vous examinez les heures de travail, vous devrez estimer le nombre absolu et vous devrez réfléchir aux détails de mise en œuvre dans le processus d’estimation. Pour utiliser le story point pour estimer la complexité, il vous suffit de comparer la taille avec d’autres exigences.

Par exemple, il est difficile de dire clairement qu’« Une tour mesure quelques mètres de haut », mais il est plus facile de préciser que « Cette tour est environ 2 fois plus haute que ce bâtiment ».

3. La pression pour estimer le story point d’une user story est moindre que l’estimation de son temps de travail : concentrez-vous sur l’exigence elle-même, sans vous soucier de ses propres ressources et des ressources du projet, évaluez simplement la complexité de l’exigence. Pendant le processus d’estimation, les membres de l’équipe sont moins stressés et jouent un rôle dans le développement logiciel comme un jeu.

Bien que la complexité de la demande soit souvent positivement liée aux heures de travail, en raison des conditions de mise en œuvre différentes, il est toujours possible d’avoir une fonctionnalité avec un point d’histoire élevé, et la demande d’heures de travail est inférieure au point d’histoire. Mais dans Scrum, vous pouvez utiliser le sprint d’itération pour évaluer la complexité que chaque équipe de sprint peut assimiler. Pour les PO/PM, au lieu d’estimer un parcours temporel infructueux, il est préférable d’estimer un parcours temporel plus précis et objectif afin qu’ils puissent comprendre dès la première fois, à quelle distance du parcours temporel prévu du projet. Si les ressources sont limitées, comment hiérarchiser les besoins ou rechercher un autre soutien.

Ensuite, expliquez les différents aspects de la solution.

Lorsque

Effectuez une évaluation avant de décider qui doit le faire : l’avantage de le faire est de minimiser les facteurs personnels du développeur. Parce que vous ne savez pas qui va le faire, il n’est pas nécessaire de surestimer l’ajout de tampon en raison de la tâche ou du délai qui vous est propre.

OMS

Seules les personnes qui font des choses à évaluer ensemble : deux points clés :

Seules les personnes qui font des choses peuvent être estimées. Le temps ou la complexité estimés par l’unité d’exigence ne sont pas objectifs, car ce n’est pas la personne qui fait le travail, et il n’y a aucun pouvoir d’influencer l’estimation de l’équipe de développement basée sur l’évaluation des moyens de travail. Cela permet également d’éviter plus facilement l’évaluation de la complexité des exigences à partir de la date limite.
Les gens qui font des choses ensemble estiment. Parce que vous ne savez pas qui va le faire, les chiffres que chacun estime ensemble sont faciles à faire consensus après discussion et ré-estimation. Tout le monde a la participation, ils auront un sentiment de participation, et parce que tout le monde a la participation, le résultat de l’estimation est décidé par tout le monde, donc qui le fera à l’avenir ne se plaindra pas.

Quoi

Utilisez le Planning Poker pour estimer le point de l’histoire.

Carte de poker et suite de Fibonacci

La série Fischer a une caractéristique intéressante, et chaque nombre est les deux premiers nombres ajoutés. D’autre part, plus la différence entre le nombre et le suivant est grande, plus la différence est grande.

Comme indiqué ci-dessus, l’écart entre 8 et 13 est de 5, et la différence entre 13 et 20 est de 7. Cependant, comment cela se rapporte-t-il à l’estimation de la complexité de la demande ? Nous ne sommes pas en cours de maths.

Caractéristiques de l’estimation liée à la suite de Fibonacci

Les estimations ont également une caractéristique, c’est-à-dire que plus la demande ou la tâche est grande, plus la précision est grande, plus la demande ou la tâche est réduite à une granularité plus fine, elle est souvent estimée plus précise. Tout comme si un gros morceau de pierre irrégulier est installé dans une tasse, il y aura plus d’espaces au milieu, qui est la partie qui n’est pas alignée ou gaspillée. Si vous installez une pierre avec une taille plus fine et la même irrégularité, l’écart sera relativement petit, et il est facile à régler, et il peut combler l’écart plus facilement.

Même si la différence avec les chiffres précédents est relativement faible, cela n’a pas d’importance car le nombre est petit, ce qui signifie que le mouvement est flexible et que le risque est faible. Si l’estimation du temps est inexacte en raison de certains facteurs, la tâche du petit nombre devant est d’environ 20 minutes de temps supplémentaire. Au lieu de faire des heures supplémentaires pendant 2 ou 5 jours.

Comme le grand écart numérique est grand (le rapport de différence des deux valeurs avant et arrière de la série de Fermi est proche de 1,618), il est possible d’éviter l’estimation de « si cette complexité est de 20 ou 21 ». « Si vous en voulez 13, vous en voulez 20, vous en voulez 40.

Un tel écart peut mettre en évidence la différence d’estimations d’un même besoin, car presque tous sont plus de 1,5 fois pires. Ce rapport est assez facile pour les humains à juger de la taille relative, et peut donc réduire de nombreuses nuances et des coûts de processus de réestimation inutiles.

Numéros spéciaux dans la carte de poker

De plus, l’image ci-dessus peut être vue avec quelques nombres spéciaux, qui sont 0, l’infini et le point d’interrogation.

0 peut signifier que cette exigence n’a pas du tout besoin d’être faite, ou qu’elle a déjà été remplie.
L’infini signifie que la demande est claire, mais celle qui dépasse le nombre maximum indique que la demande doit être subdivisée en plusieurs exigences de plus petite taille.
Le point d’interrogation indique que la demande n’est pas claire et nécessite que PO/PM explique ou clarifie.

Comment

1. Définissez d’abord l’unité de complexité 1 , telle que la fonction d’une requête complète sur une seule table. Étant donné que notre processus d’estimation est basé sur la taille relative, nous définissons d’abord l’unité de référence de comparaison, et il existe une base de comparaison après les estimations de l’équipe.

2. L’hôte parle à haute voix des exigences (telles que la User Story Card) pour s’assurer que tout le monde comprend les exigences et que chaque personne présente sa propre complexité estimée. La raison d’utiliser le planning poker est que les chiffres que vous évaluez peuvent être présentés en même temps, au lieu de faire tourner les chiffres que vous avez évalués. Il est facile de tourner les chiffres et de faire en sorte que les résultats des personnes derrière eux soient affectés par les chiffres précédents.

3. S’il y a des estimations différentes dans l’équipe, les deux sont estimées être la plus petite et la plus grande, et ils évalueront pourquoi elles sont compliquées ou simples. Dans l’exemple ci-dessus, dans le processus d’estimation, si une personne estime que le point d’histoire est 13, la plupart des gens estiment 20 et une autre personne estime 40. 13 et 40 sont presque 3 fois pires, donc fondamentalement, il doit y avoir des informations importantes qui ont pas été synchronisé.

Par exemple, les personnes qui estiment 13 pensent que cette demande est presque la même qu’une exigence dans le passé, et cette exigence n’est pas aussi compliquée qu’on l’imagine. La personne qui estime 40 peut se sentir relativement compliquée car elle ne connaît pas assez cette exigence ou ce processus.

4. Chiffres minimum et maximum, les motifs de l’évaluation sont complétés et un nouveau vote a lieu. S’il y a encore des nombres de votes différents, et que la grande majorité des gens ont un consensus, et qu’il n’y a pas de consensus sur le fait que la complexité estimée n’est qu’à un niveau de la complexité consensuelle, vous pouvez demander aux membres qui estiment les différents nombres s’ils peut accepter les chiffres que vous avez évalués.

5. Si le nombre a encore un écart au-dessus d’un niveau, ou si un consensus ne peut pas être obtenu, répétez les étapes 3 à 5 jusqu’à ce qu’un consensus soit atteint.

Encore une fois, seuls ceux qui effectuent réellement des tâches ou satisfont aux exigences peuvent participer au processus de vote, et PO/PM ne peut pas interférer.

Pourquoi

Il y a plusieurs avantages à cette méthode d’estimation :

La personne qui travaille ensemble décide d’un résultat d’estimation raisonnable et objectif, a le sens de la participation et ne se plaint pas.
Le résultat de la décision est le consensus entre le PO et l’équipe, ce qui réduira l’occurrence de situations de tit-for-tat à l’avenir.
Tout le monde peut comprendre l’exigence. À l’avenir, tout le monde pourra agir en tant que personne pour répondre à l’exigence. Lorsque le besoin de soutien est nécessaire, les personnes peuvent également s’entraider ou se soutenir mutuellement.
Avant de le faire, vous pouvez clarifier la partie de l’exigence qui n’est pas claire et la partie qui a des doutes.
Avant de pouvoir le faire, vous pouvez trouver la meilleure et la plus efficace façon de travailler en équipe.
À moins que toute l’équipe ne soit une personne non fiable, ce nombre reflète le fait que l’estimation est partagée par l’équipe, et le PO peut comprendre l’écart entre la demande et l’évaluation.
En comparant la taille relative de la complexité entre les exigences, le futur PO sera en mesure de promettre la quantité de travail pouvant être accomplie dans une itération, et il y aura une base de comparaison.

Conclusion

Grâce au processus d’estimation ci-dessus, une telle décision est ouverte, transparente, objective et consensuelle. Pour deux rôles :

Pour PO/MP :

Ne vous inquiétez pas d’être surestimé une tâche pour un tampon par certains membres.
Comprendre la difficulté sous-jacente de la mise en œuvre des exigences ou des tâches dans le processus d’évaluation.
Comprendre s’il y a des parties de l’exigence qui doivent être clairement énoncées ou mal comprises.

Pour l’équipe :

Les personnes qui ne font plus les choses se voient accorder un délai déraisonnable conformément à la date limite.
Échange de connaissances entre les développeurs avant qu’ils ne commencent à travailler sur la tâche. Que le nombre estimé soit augmenté ou diminué, la demande est plus claire et l’estimation est plus objective.
Parce que vous ne savez toujours pas qui revendique cette tâche, de sorte que le processus d’estimation peut être réalisé de manière objective et avec le consensus de l’équipe, vous savez qui est familier avec cette tâche tout au long du processus. Lorsque vous le faites réellement, vous pouvez programmer en binôme ou savoir à qui demander de l’aide.

La solution proposée dans cet article est une solution commune. L’accent n’est pas mis sur la forme, mais sur l’objectif de conception de chaque lien dans le processus d’estimation agile, afin de résoudre quel type de problème.