Histórias para tarefas de correção de bugs: É adequado para o Scrum?

Eu só estou querendo saber se devemos atribuir pontos da história para tarefas de correção de bugs ou não. O JIRA, nosso software de rastreamento de problemas, não possui um campo de storypoint para problemas do tipo Bug (é apenas para Storys e Epic s).

Devemos adicionar o tipo de problema de bug aos tipos de problema aplicáveis ​​do campo Story Points ? Quais são os prós e contras? Seria adequado para o Scrum?

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

Na realidade, no entanto, os bugs surgem após a implantação o tempo todo, não importa o quão rígido seja seu teste; quando isso acontece, a remoção do bug é apenas mais uma alteração, um recurso, se você desejar. 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 determinado comportamento e o usuário (ou algum outro interessado) gostaria que ele fosse alterado.

De uma perspectiva comercial, as correções e os recursos também são os mesmos: na verdade, você faz (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 apenas os pesará e seguirá o que lhes der mais lucro (a longo ou a curto prazo, dependendo da estratégia de negócios).

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

O maior problema com isso é que as correções de erros geralmente são mais difíceis de estimar: 90% ou mais do esforço real consiste em encontrar a causa; depois de encontrá-lo, é possível obter uma estimativa precisa, mas é quase impossível avaliar quanto tempo a pesquisa levará. Eu já vi vários bugs em que a maior parte do tempo foi gasta apenas tentando reproduzir o bug. Por outro lado, dependendo da natureza do bug, geralmente é possível restringir a pesquisa com algumas pesquisas mínimas antes de fazer uma estimativa.

A estimativa de bugs com pontos é inerentemente difícil, como já indicado em outras respostas, e sim a solução ideal é que os bugs encontrados em um recurso APÓS a aceitação do sprint sejam considerados novos recursos .

Essa dificuldade na estimativa de pontos para 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 é necessário dilligence e experiência para se tornar hábil na estimativa de pontos. Muitos projetos enfrentam problemas significativos ao determinar corretamente a velocidade; muitos projetos Agile usam pontos para determinar quais histórias entram no sprint; no entanto, usam horas para calcular o gráfico de burndown .

Parece contra-intuitivo, mas gerenciável, desde que a estimativa de horas não seja usada como fator na determinação do comprometimento do sprint. O comprometimento excessivo naturalmente levará a recursos ou horas extras perdidos ou incompletos, portanto, com o tempo, todos os envolvidos são forçados a melhorar a estimativa de pontos, quando a estimativa de horas em tarefas e bugs se torna lentamente uma métrica sem sentido.

Você não deve dar pontos à resolução de erros. Considere o fato de que o bug surge de uma história em que os desenvolvedores já ganharam pontos por concluí-la. Não deve receber pontos novamente onde realmente não deveria ter conquistado os pontos .

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

Talvez um link útil:

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

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

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

Lembre-se de que pode ser difícil estimar o esforço necessário para corrigir um erro. Isso 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 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 em resolvê-las. Com isso, a precisão é aprimorada 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.

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

Obviamente, bug ou história, do lado comercial, não importa com o que a equipe esteja 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 bugs que já foram analisados
3. Atribuir tempo para correção de bugs e não estimar bugs, mas classifique-os apenas com base no valor comercial

Com 1. falhamos miseravelmente. Para a maioria dos erros, 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 bugs em um sprint, cometemos o erro de que o escopo desconhecido impactou a resolução da história até o ponto em que quase todos os sprints que fizemos dessa maneira falharam.

Com base na opção 2. da técnica de estimativa da razão 90/10 (análise para correção de bugs), significava que tínhamos que planejar uma análise que não era algo coberto pelo planejamento de sprint (aprendemos da opção 1, mas não possuía solução real). como continuar com os erros analisados). O resultado foi que a análise de bug não foi feita, pois um sprint focou nos itens planejados. A equipe não teve tempo para se concentrar nos bugs da lista de pendências. Então, eventualmente, eles também não terminaram.

Ao abraçar a incerteza, decidimos agora a opção 3. Dividimos o backlog do produto em uma parte normal da história / tarefa que pode ser estimada pela equipe usando pontos da história e um backlog de erros. Na lista de pendências de bugs, o proprietário do produto classifica os bugs com base no valor comercial e no julgamento muito duro da equipe. A equipe permite alocar um pedaço de 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 era possível planejar isso antes. A proporção de backlog de erros versus backlog regular pode ser ajustada para cada sprint, dependendo do status atual de cada backlog e da importância e valor comercial do conteúdo.

Tirando a incerteza, liberou a equipe novamente. Os sprints não foram comprometidos por erros desconhecidos. Ao separar os bugs em um backlog diferente, aumentamos o foco regular do time na sprint e nos fizeram terminar os bugs que também continham um valor comercial significativo.

Portanto, depende se os pontos da história são adequados para você. Eu tentaria estimar bugs usando pontos de história primeiro. Se isso falhar, tente minha opção 3. Isso fez com que nossa equipe (com mais de 30 anos de idade) se concentre em bugs mais antigos novamente, os quais contêm 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 aproximava da realidade e também tornava nossos sprints bem-sucedidos novamente, ao mesmo tempo em que fornecia uma grande parte (baseada na proporção entre bugs e histórias) do valor comercial através de correções. A proporção que usamos recentemente foi de 50/50.

Eu tenho que discordar da resposta principal de atribuir pontos de história a erros. Os pontos da história devem ser para que um novo valor seja entregue. Se você deseja atribuir pontos ao valor do produto e aos itens que não são de valor, é possível apenas estimar e acompanhar as horas.

Os erros são a sobrecarga do que você fez ontem e não são indicativos da velocidade de conclusão do produto, e também não criam nenhum novo valor para o produto (pense nisso). Os bugs são como interrupções e todas as outras tortas de vaca com as quais você precisa lidar semanalmente. Toda a idéia dos argumentos é que ela rastreia / estima quando entregaremos o produto (ou conjunto de recursos). Os pontos da história são arbitrários e é assim que ele remove toda a sobrecarga sem valor da estimativa. Geralmente, o trabalho sem valor é constante semana a semana, portanto é incorporado à velocidade da equipe. A equipe irá acelerar quando remover ou reduzir esse trabalho sem valor.

Em outras palavras, por que rastrear pontos para bugs? Para que, no final do dia, você saiba quanto "trabalho" cada membro fez? Pare com isso! Mau gerente! :) Meça a equipe, não o jogador. Incentive a equipe a se autogerenciar se uma pessoa não estiver exercendo seu peso. Muito mais eficaz. Fazer itens de storypoint 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 no 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 a longo prazo.

Você sabe, eventualmente, você não deseja usar pontos. Estimativa é tempo tirado do trabalho real. Quando uma equipe atinge o chi máximo, eles ainda não usam pontos e sabem exatamente quantos itens podem usar em um sprint. Eles dominaram a arte de dividir as unidades de trabalho que estimar é um desperdício de processo.

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

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

Lembre-se de que a causa de um defeito pode vir de qualquer ponto do ciclo de vida do software - requisitos incompreendidos ou mal comunicados, design inadequado ou suposições erradas, codificação incorreta, testes incorretos, novos conhecimentos sobre o problema com base nas informações aprendidas na versão atual ...

A criação de um orçamento pode ser feita de duas maneiras diferentes para tarefas de correção de erros. Aqui estão algumas idéias que usei efetivamente:

• Use dados históricos (digamos de uma iteração anterior) para ajudá-lo a entender quanto tempo deve ser reservado para a correção de erros.
• Coloque "blocos" de correção de bugs (digamos 5 pontos ou 20 horas) em sua lista de pendências e deixe o cliente escolher isso no lugar de histórias.
• Exija que cada membro de sua equipe dedique um tempo especificado a cada iteração, corrigindo defeitos.

Seu objetivo é corrigir o maior número possível de defeitos dentro do orçamento alocado. Discuta com as estratégias de seus clientes para priorizar defeitos relatados. Por exemplo, você classifica os defeitos por criticidade e por prioridade? Prioridade estrita? Você deve atacar "frutas baixas" primeiro? Erros de interface do usuário primeiro?

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

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

Em vez de focar em histórias, bugs, tarefas e os pontos que cada um possui, acho melhor me concentrar em fornecer recursos para o cliente.

Os clientes esperam que o software funcione e apenas dê valor real ao desenvolvimento, aprimoramentos e novos recursos, pois isso impulsiona os negócios.

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

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

Isso pode levar a um gerenciamento por histórico de histórico, em vez de pressionar a necessidade urgente de que as histórias desta semana sejam completas e frequentemente descubram que não são. No entanto, a perda do controle inicial e o aumento da confiança necessária exigem alguns gerentes correndo para a porta horrorizados.

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