Points de récit pour les tâches de correction de bugs: Est-ce que cela convient à Scrum?

Je me demande simplement si nous devrions attribuer des points d’histoire à des tâches de correction de bugs ou non. JIRA, notre logiciel de suivi des problèmes, ne dispose pas de champ de points d’histoire pour les problèmes de type de bogue (il ne s’agit que des histoires et des épopées ).

Devrions-nous ajouter le type de problème Bug aux types de problème applicables du champ Points d'histoire ? Quels sont les avantages et inconvénients? Cela conviendrait-il à Scrum?

Idéalement, votre logiciel devrait être exempt de bogues après chaque itération, et la correction des bogues devrait faire partie de chaque sprint. Par conséquent, le travail requis pour corriger les bogues devrait être pris en compte lors de l'attribution de points de scénario (c.-à-d. avoir plus de points d’histoire qui lui sont attribués).

En réalité, cependant, les bogues apparaissent constamment après le déploiement, quelle que soit la rigidité de vos tests. lorsque cela se produit, supprimer le bogue n'est qu'un autre changement, une fonctionnalité si vous voulez. Il n'y a pas de différence fondamentale entre un rapport de bogue et une demande de fonctionnalité dans ce contexte: dans les deux cas, l'application présente un certain comportement et l'utilisateur (ou un autre intervenant) souhaite le voir modifié.

D'un point de vue commercial, les corrections de bugs et les fonctionnalités sont également les mêmes: en réalité, vous le faites (scénario B) ou vous ne le faites pas (scénario A); Les deux scénarios ont des coûts et des avantages, et un homme d’affaires digne de ce nom les soupesera et utilisera tout ce qui leur rapporte plus de profit (à long terme ou à court terme, en fonction de la stratégie commerciale).

Alors oui, bien sûr, attribuer des points d’histoire aux bugs. Sinon, comment allez-vous hiérarchiser les bogues par rapport aux fonctionnalités et les bogues par rapport aux bogues? Vous avez besoin d'une certaine mesure d'effort de développement pour les deux, et il vaut mieux être comparable.

Le plus gros problème avec ceci est que les corrections de bugs sont souvent plus difficiles à estimer: 90% ou plus des efforts réels consistent à trouver la cause; une fois que vous l'avez trouvée, vous pouvez obtenir une estimation précise, mais il est presque impossible de juger de la durée de la recherche. J'ai même vu un bon nombre de bugs où la plupart du temps était consacré à essayer de reproduire le bogue. D'autre part, en fonction de la nature du bogue, il est souvent possible d'affiner la recherche avec un minimum de recherche avant de faire une estimation.

Vous ne devriez pas donner de points à la résolution de bugs. Considérez le fait que le bogue provient d'une histoire où les développeurs ont déjà gagné des points pour avoir terminé l'histoire. Il ne devrait plus recevoir de points là où il n’aurait pas dû gagner les points pour commencer.

La correction des bugs devrait avoir un effet négatif sur la vélocité. Sinon, la qualité perdante finit par être récompensée par une vélocité inchangée, voire accrue!

Peut-être un lien utile:

http://www.infoq.com/news/2011/01/story-points-to-bugs

L'estimation des bogues avec des points est intrinsèquement difficile, comme cela a déjà été souligné dans d'autres réponses, et la solution idéale est que les bogues détectés dans une fonctionnalité APRÈS que le sprint ait été accepté soient considérés comme de nouvelles fonctionnalités .

Cette difficulté d’estimation ponctuelle des bogues est toutefois l’une des nombreuses raisons pour lesquelles les progiciels Agile PM permettent d’estimer les tâches et les bogues en heures, car il faut de la diligence et de l’expérience pour acquérir les compétences requises pour estimer ponctuellement. La détermination correcte de la vélocité pose de nombreux problèmes pour de nombreux projets Agile. Par conséquent, de nombreux projets Agile utilisent des points pour déterminer les histoires qui entrent dans le sprint. Cependant, ils utilisent des heures pour calculer le graphique de burndown .

Cela semble contre-intuitif, mais gérable tant que l'estimation du nombre d'heures n'est pas utilisée pour déterminer l'engagement du sprint. Les surcharges conduisent naturellement à des fonctionnalités manquantes ou incomplètes ou à des heures supplémentaires. Ainsi, avec le temps, toutes les personnes impliquées sont obligées de s’améliorer à l’estimation ponctuelle, point à partir duquel estimer le nombre d’heures consacrées aux tâches et bugs devient lentement une métrique dénuée de sens.

Je recommanderais de traiter le bogue comme une user story et de lui attribuer un certain nombre de points. Je ne l'écrirais pas nécessairement au format "En tant que X, je veux Y pour que Z", comme il est courant dans les user stories - je l'écrirais plutôt en tant que "En tant que X, quand IY, Z se produit, mais Z 'est le comportement attendu ".

L'avantage de cela est qu'il vous permet de hiérarchiser les correctifs de bogues en même temps que les nouvelles demandes de fonctionnalités. La vérité est que parfois, une nouvelle fonctionnalité est plus importante que la correction d'un bogue. Cependant, il vous permet également de dimensionner correctement le travail requis, ce qui vous permet de l'intégrer à un sprint lorsque vous en avez la possibilité.

Il ne faut pas oublier qu’il peut être difficile d’estimer l’effort requis pour corriger un bogue. Cela peut impliquer plusieurs composants qui interagissent les uns avec les autres, nécessitant que quelqu'un se familiarise avec les interactions de gros éléments du système ou que plusieurs personnes travaillent sur le correctif.

L’estimation d’histoires repose sur la notion qu’avec le temps, une équipe gagne de l’expérience pour les résoudre. Avec cela, la précision est améliorée et la vélocité peut être établie pour mesurer la vitesse d'une équipe. Une méthodologie parfaite pour établir des pronostics fiables pour les futurs sprints.

Les bugs sont une réalité de la vie d’une entreprise de développement de logiciels. Bien que je sois d’accord pour dire que les bugs doivent tous être capturés lors de l’élaboration d’une histoire, accepter que cela ne puisse pas être réalisé à tout moment, devrait être une tâche que chaque équipe devrait planifier. Au lieu de penser obstinément que le processus devrait gouverner l’équipe, ce devrait être l’inverse.

Bien sûr, bug ou histoire, du point de vue des affaires, peu importe ce que l'équipe traite. Les deux peuvent produire une valeur égale pour le propriétaire du produit.

Dans notre équipe, nous avons expérimenté quelques techniques d'estimation des bugs:

1. Estimation de bugs complètement inconnus
2. Estimer uniquement les bugs déjà analysés
3. Allouer du temps pour la correction des bogues sans en évaluer les bogues, mais les classer uniquement en fonction de la valeur commerciale

Avec 1. nous avons échoué à tort. Pour la plupart des bogues, nous avons trouvé que 90% du temps était consacré à l'analyse des bogues. Ensuite, le correctif peut être estimé de la même manière qu’un récit. En planifiant les bugs dans un sprint, nous avons commis l’erreur que la portée inconnue avait eu un impact sur la résolution de l’histoire jusqu’au point où presque tous les sprints que nous avons réalisés ont échoué.

Selon l'option 2 de la technique d'estimation du ratio 90/10 (analyse par correction de bugs), nous devions planifier une analyse qui n'était pas couverte par la planification du sprint (nous avions appris de l'option 1, mais nous n'avions pas de solution réelle. comment continuer avec les bugs analysés). Le résultat est que l'analyse des bogues n'a pas été effectuée car un sprint s'est concentré sur les éléments planifiés. L'équipe n'a pas eu le temps de se concentrer sur les bogues de l'arriéré. Donc finalement ils ne se sont pas fait non plus.

En acceptant l’incertitude, nous avons opté pour l’option 3. Nous avons divisé l’arriéré de produits en une partie récit / tâche régulière qui peut être estimée par l’équipe à l’aide de points d’histoire et d’un arriéré de bogues. Dans le carnet de bogues, le propriétaire du produit classe les bogues en fonction de la valeur commerciale et d'un jugement d'équipe très grossier. L’équipe permet d’allouer une partie du temps lors d’un sprint qu’elle peut consacrer à se concentrer sur les bugs. Le propriétaire du produit ne connaît pas le résultat exact, car il n’était pas possible de le planifier de toute façon auparavant. Le ratio de l'arriéré de bogues par rapport à l'arriéré normal peut être ajusté pour chaque sprint en fonction de l'état actuel de chaque arriéré et de l'importance et de la valeur commerciale du contenu.

En éliminant cette incertitude, l'équipe a de nouveau été libérée. Les sprints n'ont pas été compromis par des bugs inconnus. En séparant les bogues dans un arriéré différent, les équipes ont davantage focalisé leurs efforts sur le sprint et nous ont fait finir les bogues qui contenaient également une valeur commerciale importante.

Donc, cela dépend si les points d’histoire vous conviennent. J'essayerais d'estimer les bugs en utilisant les points d'histoire en premier. Si cela échoue, essayez mon option 3. Cela a permis à notre équipe (plus de 30 anciens sprint) de se concentrer à nouveau sur les bogues plus anciens, qui présentent une valeur ajoutée pour l'entreprise. Cela nous a également libéré d'essayer de livrer quelque chose que l'équipe ne peut tout simplement pas estimer. C’est embrasser l’inconnu qui nous a rapprochés de la réalité et nous a également permis de réussir nos sprints tout en offrant un gros morceau (basé sur le rapport entre les bogues) de valeur commerciale grâce à des corrections de bugs. Le rapport que nous avons utilisé récemment était de 50/50.

Je ne suis pas d'accord avec la première réponse d'attribution de points d'histoire à des bugs. Les points de scénario devraient être pour la nouvelle valeur livrée. Si vous souhaitez attribuer des points à des éléments de valeur et non-valeur, vous pouvez également estimer et suivre le nombre d'heures.

Les bugs sont la surcharge de ce que vous avez fait hier et n'indiquent pas la rapidité d'achèvement du produit, et ils ne créent pas non plus de nouvelle valeur de produit (réfléchissez-y). Les insectes sont un peu comme les interruptions et toutes les autres pâtés à la vache que vous devez traiter sur une base hebdomadaire. L’idée des points d’histoire est qu’elle suit / estime le moment où nous livrerons le produit (ou l’ensemble de fonctionnalités). Les points d’histoire sont arbitraires et c’est ainsi que l’on supprime tous les frais généraux sans valeur de l’estimation. Généralement, le travail sans valeur est constant semaine après semaine, il est donc intégré à la vélocité de l'équipe. L'équipe accélérera lorsqu'elle supprimera ou réduira ce travail sans valeur.

En d'autres termes, pourquoi même suivre les points aux bugs? Donc, au bout du compte, vous savez combien de "travail" chaque membre a fait? Arrête ça! Mauvais gestionnaire! :) Mesurer l'équipe, pas le joueur. Encouragez l'équipe à se gérer si une personne ne tire pas son poids. Beaucoup plus efficace. Faire des points d'histoire ne devrait pas aider une personne à se sentir mieux, mais l'équipe dans son ensemble devrait se sentir mieux lorsqu'elle prend son engagement à la fin du sprint. En sport, l’objectif est-il bon pour l’équipe ou pour l’individu? Si l'individu joue pour lui-même, l'équipe perd à long terme.

Vous savez, vous finirez par ne plus utiliser de points. L'estimation est le temps perdu du travail réel. Lorsqu'une équipe atteint le maximum de chi, elle n'utilise pas de points du tout, mais elle sait exactement combien d'éléments elle peut tirer dans un sprint. Ils ont maîtrisé l'art de casser des unités de travail que l'estimation est un gaspillage de processus.

Certaines tâches sont estimables, d'autres non. Pour les choses qui ne peuvent pas être estimées, utilisez un budget.

La réparation d’un défaut n’est pas une tâche facile à estimer, car elle comporte plusieurs composants inconnus. Quelle est la cause du défaut? Une fois la cause comprise, comment peut-on la réparer? Quel impact ce changement a-t-il sur le reste du système? Combien de nouveaux défauts avez-vous injectés en corrigeant ce défaut?

N'oubliez pas que la cause d'un défaut peut provenir de n'importe quel point du cycle de vie du logiciel: exigences mal comprises ou mal communiquées, conception médiocre ou hypothèses erronées, codage incorrect, tests incorrects, nouvelles connaissances du problème basées sur les informations tirées de la version actuelle. ...

La création d'un budget peut être effectuée de deux manières différentes pour les tâches de correction de bugs. Voici quelques idées que j'ai utilisées efficacement:

• Utilisez les données historiques (par exemple d'une itération précédente) pour vous aider à comprendre combien de temps vous devez consacrer à la résolution des bogues.
• Mettez des "blocs" de corrections de bugs (disons 5 points ou 20 heures) dans votre carnet de commandes et laissez le client choisir celui-ci au lieu d’histoires.
• Exigez que chaque membre de votre équipe consacre une période de temps spécifiée à chaque itération pour corriger les défauts.

Votre objectif est alors de corriger autant de défauts que possible dans les limites du budget alloué. Discutez avec votre client des stratégies pour hiérarchiser les défauts signalés. Par exemple, triez-vous les défauts par criticité, puis par priorité? Priorité stricte? Devriez-vous attaquer «les fruits les plus faciles» en premier? UI bugs en premier?

De plus, la correction des bugs ne rapporte rien. Les défauts de fixation sont une forme de gaspillage. Vous avez déjà gagné de la valeur avec cette fonctionnalité, vous ne devriez donc pas obtenir de "points bonus" pour la correction de bugs.

Avoir un budget aide à la planification et vous donne toujours une image précise de Velocity. Attribuez un budget à un nombre spécifique de points pour la correction des bogues, attribuez à votre budget une durée approximative en fonction de vos données historiques, puis supprimez autant de bogues que possible dans le temps imparti!

Au lieu de mettre l’accent sur les histoires, les bugs et les corvées et les points que chacun a, je trouve mieux de mettre l’accent sur la fourniture de fonctionnalités au client.

Les clients s'attendent à ce que le logiciel fonctionne et n'accordent qu'une valeur réelle au développement, aux améliorations et aux nouvelles fonctionnalités, car ils permettent à l'entreprise de progresser.

Les corrections de bogues, aussi importantes soient-elles, ne poussent pas l'entreprise vers de nouveaux domaines et de nouveaux clients (de manière tangentielle et éventuellement éventuellement, mais pas immédiatement, ce que la direction mesure actuellement).

Les points sont donc mieux vus du point de vue plus élevé de la vélocité et du nombre de points par semaine historiquement réalisés pour des récits marqués de la même manière.

Cela peut conduire à une gestion par historique des antécédents plutôt que de renforcer le besoin urgent que les récits de cette semaine soient complets et de constater fréquemment qu'ils ne le sont pas. Cependant, la perte de contrôle initial et la confiance accrue que cela nécessite engendreront certains gestionnaires qui se présenteront devant la porte avec horreur.

J'utilise Pivotal Tracker (je viens de JIRA, Trak, Trello et d'autres aussi) et Pivotal Tracker ne fait pas non plus de points pour les tâches ménagères ou les bugs. C’est fait pour les mêmes bonnes raisons que celles décrites ci-dessus, qui rendent JIRA aussi vrai que vous vous voyez.