Pontos de história para tarefas de correção de bugs: É adequado para Scrum?

Idealmente, o seu software deve ficar livre de bugs após cada iteração, e corrigir bugs deve fazer parte de cada sprint, portanto o trabalho necessário para corrigir bugs deve ser considerado ao atribuir pontos de história (ou seja, uma tarefa mais provável produzir bugs deve ter mais pontos de história atribuídos a ele).

Na realidade, no entanto, os bugs surgem na pós-implementação o tempo todo, não importa o quão rígido seja seu teste; quando isso acontece, remover o bug é apenas outra mudança, um recurso se você quiser. Não há diferença fundamental entre um relatório de bug e uma solicitação de recurso neste contexto: em ambos os casos, o aplicativo mostra um certo comportamento, e o usuário (ou algum outro stakeholder) gostaria de vê-lo alterado.

Do ponto de vista comercial, as correções de bugs e os recursos também são os mesmos: você faz isso (cenário B) ou não (cenário A); ambos os cenários têm custos e benefícios associados, e uma pessoa de negócios decente pesa-os e os leva a lucrar mais (a longo ou a curto prazo, dependendo da estratégia de negócios).

Então, sim, por todos os meios, atribua pontos de história a bugs. De que outra forma você priorizará bugs vs. recursos e bugs contra bugs? Você precisa de alguma medida de esforço de desenvolvimento para ambos, e é melhor que seja comparável.

Estimar bugs com pontos é inerentemente difícil, como já foi apontado em outras respostas e, sim, a solução ideal é que os bugs encontrados em um recurso APÓS o sprint ser aceito sejam considerados novos recursos . p>

Essa dificuldade na estimativa pontual de bugs, no entanto, é uma das muitas razões pelas quais os pacotes de software Agile PM permitem que tarefas e bugs sejam estimados em horas, porque é preciso ter competência e experiência para se tornar hábil na estimativa de ponto. Muitos projetos têm problemas significativos ao determinar a velocidade corretamente, portanto, muitos projetos Agile usam pontos para determinar quais histórias são incluídas na sprint. No entanto, eles usam horas ao calcular o diagrama de burndown .

Parece contra-intuitivo, mas gerenciável, desde que a estimativa de horas não seja usada como fator na determinação do compromisso de sprint. O comprometimento excessivo naturalmente levará a características ou horas extras perdidas ou incompletas, de modo que, com o tempo, todos os envolvidos são forçados a melhorar na estimativa de pontos, quando as horas estimadas em tarefas e bugs se tornam lentamente uma métrica sem sentido.

Você não deve dar pontos à resolução de erros. Considere o fato de que o erro surge de uma história na qual os desenvolvedores já conquistaram pontos para concluir a história. Ele não deve receber pontos novamente onde realmente não deveria ter ganho os pontos para começar.

A correção de erros deve ter um efeito negativo na velocidade. Caso contrário, a queda de qualidade acaba sendo recompensada com uma velocidade não afetada ou até aumentada!

Talvez um link útil:

link

Eu recomendaria tratar o bug como uma história do usuário e atribuir a ele vários pontos. Eu não necessariamente escreveria no formato de "Como um X, eu quero Y para que Z", como é comum em histórias de usuários - eu escreveria mais como "Como um X, quando IY, Z acontece, mas Z 'é o comportamento esperado ".

A vantagem disso é que ele permite priorizar correções de erros ao lado de novas solicitações de recursos. A verdade é que, às vezes, um novo recurso é mais importante do que consertar um bug. No entanto, ele também permite que você dimensione adequadamente o trabalho necessário, permitindo que você o ajuste em uma sprint quando tiver a capacidade de fazê-lo.

Uma coisa é ter em mente que pode ser difícil estimar o esforço necessário para corrigir um bug. Pode envolver vários componentes que interagem entre si, exigindo que alguém se familiarize com as interações de grandes partes do sistema ou com várias pessoas para trabalhar na correção.

A estimativa de histórias baseia-se na noção de que, com o tempo, uma equipe ganha experiência para resolvê-las. Com isso, a precisão é melhorada e a velocidade pode ser estabelecida para medir a velocidade de uma equipe. Uma metodologia perfeita para estabelecer prognósticos confiáveis para futuros sprints.

Bugs são um fato da vida de uma empresa de desenvolvimento de software. Embora eu concorde que todos os erros devem ser capturados durante o desenvolvimento de uma história, aceitar que isso não pode ser alcançado em todos os momentos deve ser algo que toda equipe deve planejar. Em vez de teimosamente pensar que o processo deve governar a equipe, deve ser o contrário.

Claro, bug ou história, do lado comercial, não importa com o que a equipe está lidando. Ambos podem produzir uma quantidade igual de valor para o proprietário do produto.

Em nossa equipe, experimentamos algumas técnicas para estimar bugs:

1. Estimando bugs completamente desconhecidos
2. Apenas estimando erros que já foram analisados
3. Atribuindo tempo para a correção de bugs e não estimando bugs, mas classifique-os com base apenas no valor comercial

Com 1. falhamos de maneira insuficiente. Para a maioria dos bugs, descobrimos que 90% do tempo é gasto na análise de erros. Depois disso, a correção do bug pode ser estimada da mesma maneira que uma história. Ao planejar os erros em um sprint, cometemos o erro de que o escopo desconhecido afetou a resolução da história até o ponto em que quase todos os sprints que fizemos dessa maneira falharam.

Com base na proporção de 90/10 (análise para correção de bugs) a opção de técnica de estimativa 2. significava que tínhamos que planejar uma análise que não era coberta pelo planejamento de sprint (aprendemos da opção 1, mas nenhuma solução real como continuar com os erros analisados). O resultado foi que a análise de erros não foi feita desde que um sprint se concentrou nos itens planejados. A equipe não teve tempo de se concentrar nos bugs do backlog. Então, eventualmente eles também não foram feitos.

Ao adotarmos a incerteza, agora decidimos sobre a opção 3. Dividimos o backlog do produto em uma parte regular da história / tarefa que pode ser estimada pela equipe usando pontos de história e um backlog de bug. No backlog de bugs, o proprietário do produto classifica os bugs com base no valor comercial e no julgamento da equipe. A equipe permite alocar um bom tempo durante um sprint que pode ser gasto com foco em bugs. O proprietário do produto não sabe o resultado exato, pois não foi possível planejá-lo antes. O rácio entre o backlog de bugs e o backlog normal pode ser ajustado para cada sprint, dependendo do status atual de cada backlog e da importância e valor comercial do conteúdo.

Eliminando a incerteza, liberou a equipe novamente. Sprints não foram comprometidos por erros desconhecidos. Ao separar os bugs em um backlog diferente, aumentamos o foco de sprint regular da equipe e fizemos com que terminássemos bugs que também continham um valor comercial significativo.

Então, depende se os pontos da história são adequados para você. Eu tentaria estimar os bugs usando pontos de história primeiro. Se isso falhar, tente a minha opção 3. Ela fez com que nosso time (mais de 30 anos de idade) se concentrasse em bugs antigos que contenham grande valor comercial. Também nos libertou de tentar entregar algo que a equipe simplesmente não pode estimar. Ele estava abraçando o desconhecido que nos aproximou da realidade e também fez com que nossos sprints fossem bem-sucedidos novamente enquanto oferecia um grande pedaço (baseado na proporção do bug à história) de valor de negócios por meio de correções de bugs. A proporção que usamos recentemente foi de 50/50.

Eu tenho que discordar da principal resposta de atribuir pontos de história a bugs. Os pontos da história devem ser para que o novo valor seja entregue. Se você for atribuir pontos ao valor do produto e aos itens sem valor, é melhor estimar e controlar as horas.

Bugs são a sobrecarga do que você fez ontem e não é indicativo da velocidade de conclusão do produto, e eles não criam qualquer novo valor do produto (pense nisso). Bugs são como interrupções e todas as outras tortas de vaca que você precisa lidar semanalmente. A ideia dos story points é que ele rastreia / estima quando vamos entregar o produto (ou conjunto de recursos). Pontos de história são arbitrários e é assim que se remove toda a sobrecarga de não-valor da estimativa. Geralmente, o trabalho sem valor é constante semana a semana, por isso é incorporado à velocidade da equipe. A equipe acelerará quando remover ou reduzir esse trabalho sem valor.

Em outras palavras, por que rastrear aponta para bugs? Então, no final do dia, você sabe quanto "trabalho" cada membro fez? Pare com isso! Mau gerente! :) Meça a equipe, não o jogador. Incentive a equipe a administrar a si mesma se uma pessoa não estiver puxando seu peso. Muito mais eficaz. Fazer itens de ponto de história não deve fazer com que um indivíduo se sinta melhor, mas a equipe como um todo deve se sentir melhor quando se comprometer ao final do sprint. Nos esportes, o objetivo é bom para a equipe ou para o indivíduo? Se o indivíduo joga por si mesmo, a equipe perde no longo prazo.

Você sabe, eventualmente, você não quer usar pontos em tudo. Estimativa é tempo tirado do trabalho real. Quando uma equipe atinge o chi máximo , eles não usam pontos, mas sabem exatamente quantos itens podem ser usados em um sprint. Eles dominaram a arte de desmembrar unidades de trabalho e a estimativa é desperdício de processos.

Algumas tarefas são estimadas, outras não. Para itens que não podem ser estimados, use um orçamento.

Corrigir um defeito não é uma tarefa prontamente estimada, pois ele possui vários componentes desconhecidos. O que está causando o defeito? Uma vez que a causa é entendida, como ela pode ser corrigida? Qual o impacto dessa mudança no restante do sistema? Quantos novos defeitos você injetou corrigindo esse defeito?

A criação de um orçamento pode ser feita de várias maneiras diferentes para tarefas de correção de bugs. Aqui estão algumas ideias que usei efetivamente:

• Use dados históricos (digamos de uma iteração anterior) para ajudar você a entender quanto tempo deve ser reservado para correção de bugs.
• Coloque "blocos" de correção de erros (digamos, 5 pontos ou 20 horas) no seu backlog e deixe que o cliente escolha isso em vez de histórias.
• Exigir que cada membro de sua equipe dedique um período de tempo especificado a cada iteração corrigindo defeitos.

Seu objetivo é corrigir tantos defeitos quanto possível dentro do orçamento alocado. Discuta com suas estratégias de clientes para priorizar os defeitos relatados. Por exemplo, você classifica defeitos por importância e prioridade? Prioridade estrita? Você deveria atacar primeiro os "frutos mais baixos"? Primeiros erros de interface do usuário?

Além disso, corrigir bugs não gera valor. Os defeitos de fixação são uma forma de desperdício. Você já ganhou valor no recurso, por isso não deve receber "pontos de bônus" para corrigir bugs.

Ter um orçamento ajuda no planejamento e ainda fornece uma imagem precisa do Velocity. Orce um número específico de pontos para correção de bugs, dê ao orçamento uma quantidade aproximada de tempo com base em seus dados históricos e, em seguida, elimine o máximo de erros possível no tempo orçado!

Em vez do foco em histórias e bugs e tarefas e os pontos que cada um tem, acho melhor se concentrar em fornecer recursos para o cliente.

Os clientes esperam que o software funcione e só dão valor real ao desenvolvimento, aprimoramentos e novos recursos à medida que impulsionam os negócios.

Correções de bugs, por mais importantes que sejam, não levam o negócio adiante para novas áreas e novos clientes (tangencialmente e eventualmente talvez sim, mas não imediatamente, que é o que a gerência está medindo).

Assim, os pontos são melhor visualizados do ponto de vista mais elevado da velocidade e quantos pontos por semana foram feitos historicamente para histórias com pontuação similar.

Isso pode levar a uma gestão por histórico de registros, em vez de forçar a necessidade urgente de que as histórias desta semana sejam concluídas e, freqüentemente, descobrir que elas não são. No entanto, a perda do controle inicial e o aumento da confiança que isso exige terão alguns gerentes correndo para a porta com horror.

Eu uso o Pivotal Tracker (apenas o JIRA, o Trak, o Trello e outros) e o Pivotal Tracker também não faz pontos para tarefas ou bugs. É feito pelas mesmas boas razões acima que também são verdadeiras no JIRA, como você está se vendo.