Points d'histoire pour les tâches de correction de bogues: convient-il à Scrum?
Je me demande simplement si nous devrions attribuer des points d'histoire aux tâches de correction de bogues ou non. JIRA, notre logiciel de suivi des problèmes, n'a pas de champ de point d'histoire pour les problèmes de type Bug (c'est uniquement pour Story s et Epic s).
Devrions-nous ajouter le type de problème Bug aux types de problèmes applicables du champ Story Points? Quels sont les avantages et inconvénients? 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, donc le travail requis pour corriger les bogues devrait être pris en compte lors de l'attribution des points d'histoire (c.-à-d., Une tâche qui est plus susceptible de produire des bogues devrait avoir plus de points d'histoire affectés).
En réalité, cependant, les bogues font surface tout le temps après le déploiement, quelle que soit la rigidité de vos tests; lorsque cela se produit, la suppression du 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 affiche un certain comportement, et l'utilisateur (ou une autre partie prenante) aimerait le voir modifié.
D'un point de vue commercial, les corrections de bogues et les fonctionnalités sont également les mêmes, vraiment: soit vous le faites (scénario B), soit vous ne le faites pas (scénario A); les deux scénarios ont des coûts et des avantages attachés, et un homme d'affaires décent les évaluera et ira avec tout ce qui leur rapporte plus de bénéfices (à long terme ou à court terme selon la stratégie commerciale).
Alors oui, certes, attribuez des points d'histoire aux bugs. Sinon, comment allez-vous hiérarchiser les bogues par rapport aux fonctionnalités et les bogues contre les 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 est que les corrections de bogues sont souvent plus difficiles à estimer: 90% ou plus de l'effort réel réside dans la recherche de la cause; une fois que vous l'avez trouvé, vous pouvez arriver à une estimation précise, mais il est presque impossible de juger de la durée de la recherche. J'ai même vu une bonne partie des bogues où la plupart du temps était consacré à essayer de reproduire le bogue. En revanche, selon la nature du bug, il est souvent possible d'affiner la recherche avec un minimum de recherche avant de faire une estimation.
Vous ne devez pas donner des points à la résolution des bogues. 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 de bogues devrait avoir un effet négatif sur la vitesse. Sinon, la baisse de qualité finit par être récompensée par une vitesse non affectée ou même augmentée!
Peut-être un lien utile:
Estimer les bogues avec des points est intrinsèquement difficile comme déjà souligné dans d'autres réponses et oui, la solution idéale est que les bogues trouvés dans une fonctionnalité APRÈS que le sprint a été accepté devraient être considérés comme de nouvelles fonctionnalités.
Cette difficulté dans l'estimation ponctuelle des bogues est cependant 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 devenir compétent en estimation ponctuelle. De nombreux projets rencontrent des problèmes importants pour déterminer correctement la vélocité, de nombreux projets Agiles utilisent donc des points pour déterminer les histoires qui entrent dans le sprint, mais ils utilisent des heures lors du calcul de la Burndown Chart.
Cela semble contre-intuitif mais gérable tant que l'estimation des heures n'est pas utilisée comme facteur pour déterminer l'engagement de sprint. Le surengagement entraînera naturellement des fonctionnalités ou des heures supplémentaires manquées ou incomplètes, de sorte qu'au fil du temps, toutes les personnes impliquées sont obligées de s'améliorer à l'estimation ponctuelle, moment auquel l'estimation des heures sur les tâches et les bogues devient lentement une métrique sans signification.
Je recommanderais de traiter le bug comme une user story et de lui attribuer un certain nombre de points. Je ne l'écrirais pas nécessairement au format "Comme un X, je veux Y pour que Z" comme cela est courant avec les user stories - je l'écrirais plus comme "Comme un X, quand IY, Z arrive, mais Z 'est le comportement attendu ".
L'avantage de ceci est qu'il vous permet de prioriser les corrections de bugs juste à côté des nouvelles demandes de fonctionnalités. La vérité est que parfois, une nouvelle fonctionnalité est plus importante que la correction d'un bug. Cependant, il vous permet également de dimensionner correctement le travail requis, ce qui vous permet de l'intégrer dans un sprint lorsque vous en avez la possibilité.
Une chose à garder à l'esprit 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, obligeant quelqu'un à se familiariser avec les interactions de gros morceaux du système ou à plusieurs personnes pour travailler sur le correctif.
L'estimation des histoires repose sur la notion qu'avec le temps, une équipe acquiert de l'expérience pour les résoudre. Avec elle, la précision est améliorée et la vitesse peut être établie pour mesurer la vitesse d'une équipe. Une méthodologie parfaite pour établir des pronostics fiables pour les futurs sprints.
Les bogues sont une réalité pour une entreprise de développement de logiciels. Bien que je convienne que tous les bugs devraient être détectés lors du développement d'une histoire, accepter que cela ne puisse pas être réalisé à tout moment devrait être quelque chose 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 côté des affaires, peu importe ce que l'équipe doit gérer. Les deux peuvent produire une valeur égale pour le propriétaire du produit.
Dans notre équipe, nous avons expérimenté certaines techniques d'estimation de bugs:
- Estimer des bugs complètement inconnus
- Estimer uniquement les bugs déjà analysés
- Allouer du temps pour corriger les bogues et ne pas estimer les bogues, mais les classer à la place uniquement en fonction de la valeur commerciale
Avec 1. nous avons échoué de façon lamentable. Pour la plupart des bogues, 90% du temps est consacré à l'analyse des bogues. Après cela, la correction de bogue peut être estimée de la même manière qu'une histoire. En planifiant les bugs dans un sprint, nous avons fait l'erreur que la portée inconnue affectait la résolution de l'histoire jusqu'au point où presque chaque sprint que nous avons fait de cette façon a échoué.
Sur la base de la méthode d'estimation du rapport 90/10 (analyse sur correction de bogues), l'option 2. signifiait que 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 vraie solution comment continuer avec les bogues analysés). Le résultat a été que l'analyse des bogues n'a pas été effectuée, car un sprint s'est concentré sur les éléments planifiés à la place. L'équipe n'a pas eu le temps de se concentrer sur les bugs du backlog. Finalement, ils ne se sont pas fait non plus.
En adoptant l'incertitude, nous avons maintenant opté pour l'option 3. Nous avons divisé le backlog de produit en une partie histoire/tâche régulière qui peut être estimée par l'équipe à l'aide de points d'histoire et d'un backlog de bogue. Dans le carnet de bogues, le propriétaire du produit classe les bogues en fonction de la valeur commerciale et du jugement d'équipe très approximatif. L'équipe permet d'allouer une partie du temps pendant 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'a pas été possible de planifier cela de toute façon auparavant. Le rapport entre le backlog de bogue et le backlog régulier peut être ajusté pour chaque sprint en fonction de l'état actuel de chaque backlog et de l'importance et de la valeur commerciale du contenu.
En supprimant l'incertitude, cela a de nouveau libéré l'équipe. Les sprints n'ont pas été compromis par des bugs inconnus. En séparant les bogues dans un carnet de commandes différent, nous avons à la fois augmenté la concentration sur le sprint régulier de l'équipe et nous avons fait terminer les bogues qui contenaient également une valeur commerciale importante.
Cela dépend donc si les points d'histoire vous conviennent. J'essaierais d'abord d'estimer les bogues en utilisant des points d'histoire. Si cela échoue, essayez mon option 3. Cela a fait que notre équipe (âgée de plus de 30 sprints) se concentre à nouveau sur les anciens bogues qui contiennent une grande valeur commerciale. Cela nous a également libérés d'essayer de livrer quelque chose que l'équipe ne peut tout simplement pas estimer. Il embrassait l'inconnu qui nous a rapprochés de la réalité et a également rendu nos sprints réussis tandis que fournissant un gros morceau (basé sur le rapport bogue/histoire) de valeur commerciale grâce à des corrections de bogues. Le rapport que nous avons utilisé récemment était de 50/50.
Je dois être en désaccord avec la meilleure réponse d'attribution de points d'histoire aux bogues. Les points d'histoire devraient être pour la nouvelle valeur livrée. Si vous allez attribuer des points à des articles de valeur et de non-valeur, vous pourriez tout aussi bien estimer et suivre les heures.
Les bogues sont la surcharge de ce que vous avez fait hier et n'indiquent pas la vitesse d'achèvement du produit, et ils ne créent pas non plus de nouvelle valeur de produit (pensez-y). Les insectes sont un peu comme les interruptions et tous les autres tartes aux vaches avec lesquelles vous devez faire face chaque semaine. L'idée générale des points d'histoire est qu'elle permet de suivre/d'estimer le moment où nous livrerons le produit (ou l'ensemble de fonctionnalités). Les points d'histoire sont arbitraires et c'est ainsi que cela supprime tous les frais généraux non liés à la valeur de l'estimation. Généralement, le travail sans valeur est constant d'une semaine à l'autre, il est donc intégré à la vitesse de l'équipe. L'équipe accélérera lorsqu'elle supprimera ou réduira ce travail sans valeur.
Autrement dit, pourquoi même suivre les points des bugs? Pour qu'à la fin de la journée, vous sachiez combien de "travail" chaque membre a fait? Arrête ça! Mauvais manager! :) Mesurez 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 faire en sorte qu'un individu se sente mieux, mais l'équipe dans son ensemble devrait se sentir mieux lorsqu'elle prend son engagement à la fin du sprint. Dans le 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, finalement, vous ne voulez pas du tout utiliser de points. L'estimation est du temps pris à un travail réel. Lorsqu'une équipe atteint chi maximum, elle n'utilise pas du tout de points, mais sait exactement combien d'éléments elle peut tirer dans un sprint. Ils ont maîtrisé l'art de diviser les unités de travail que l'estimation est un déchet de processus.
Certaines tâches sont estimables, d'autres non. Pour les choses qui ne peuvent pas être estimées, utilisez un budget.
La correction d'un défaut n'est pas une tâche facilement estimable car elle comporte plusieurs composants inconnus. Quelle est la cause du défaut? Une fois la cause comprise, comment la résoudre? Quel impact ce changement a-t-il sur le reste du système? Combien de nouveaux défauts avez-vous injecté pour réparer ce défaut?
Gardez à l'esprit 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, mauvaise conception ou hypothèses erronées, mauvais codage, mauvais tests, nouvelles connaissances sur le problème sur la base des informations tirées de la version actuelle ...
La création d'un budget peut se faire de différentes manières pour les tâches de correction de bogues. Voici quelques idées que j'ai utilisées efficacement:
- Utilisez les données historiques (disons d'une itération précédente) pour vous aider à comprendre combien de temps à réserver pour la correction des bogues.
- Mettez des "blocs" de correction de bogues (disons 5 points ou 20 heures) dans votre carnet de commandes et laissez le client choisir cela au lieu d'histoires.
- Exigez que chaque membre de votre équipe consacre un temps spécifié à chaque itération pour corriger les défauts.
Votre objectif est alors de corriger autant de défauts que possible dans le cadre du budget alloué. Discutez avec vos stratégies client pour prioriser les défauts signalés. Par exemple, triez-vous les défauts par criticité puis par priorité? Priorité stricte? Devez-vous d'abord attaquer les "fruits à faible pendaison"? Bugs UI d'abord?
En outre, la correction des bogues ne gagne pas de valeur. La réparation des défauts est une forme de gaspillage. Vous avez déjà gagné de la valeur sur la fonctionnalité, vous ne devriez donc pas obtenir de "points bonus" pour corriger des bugs.
Avoir un budget aide à la planification et vous donne toujours une image précise de Velocity. Budget un nombre spécifique de points pour la correction de bugs, donnez au budget un temps approximatif basé sur vos données historiques, puis écrasez autant de bugs que vous le pouvez dans le temps prévu!
Au lieu de se concentrer sur les histoires et les bugs et les tâches et les points que chacun a, je trouve préférable de se concentrer sur la fourniture de fonctionnalités pour le client.
Les clients s'attendent à ce que le logiciel fonctionne et n'accorde une réelle valeur au développement, aux améliorations et aux nouvelles fonctionnalités que pour faire avancer l'entreprise.
Les corrections de bogues, aussi importantes soient-elles, ne font pas avancer l'entreprise dans de nouveaux domaines et de nouveaux clients (tangentiellement et éventuellement peut-être oui, mais pas immédiatement, ce que la direction mesure).
Ainsi, les points sont mieux vus du point de vue le plus élevé de la vitesse et du nombre de points par semaine historiquement réalisés pour des histoires notées de manière similaire.
Cela peut conduire à une gestion par l'historique des antécédents plutôt que de pousser le besoin urgent que les histoires de cette semaine soient complètes et de constater fréquemment qu'elles ne le sont pas. Cependant, la perte de contrôle initial et la confiance accrue que cela nécessite auront certains gestionnaires en cours d'exécution avec horreur.
J'utilise Pivotal Tracker (j'ai juste JIRA, Trak, Trello et d'autres aussi) et Pivotal Tracker ne fait pas non plus de points pour les tâches ou les bugs. C'est fait pour les mêmes bonnes raisons ci-dessus qui le rendent aussi vrai dans JIRA que vous vous voyez.