Melhores maneiras de ajustar a correção de bugs em um processo Scrum? [fechadas]

Tenho estudado e lido sobre Scrum nos últimos dias e lido sobre planejamento e tarefas de Sprint. Um problema que me veio à mente é como lidar com bugs no Scrum. Henrik Kniberg lista algumas maneiras de lidar com esse problema em seu livro Scrum e XP from the Trenches :

1. O product owner imprime os itens Jira de maior prioridade, traz-os para a reunião de planejamento do sprint e os coloca na parede junto com as outras histórias (assim, especificando implicitamente a prioridade desses itens em comparação com as outras histórias).
2. O product owner cria histórias que se referem a itens Jira. Por exemplo, “Corrija os bugs de relatórios de back office mais críticos, Jira-124, Jira-126 e Jira-180”.
3. A correção de bugs é considerada fora do sprint, ou seja, a equipe mantém um fator de foco baixo o suficiente (por exemplo, 50%) para garantir que eles tenham tempo para corrigir os bugs. Em seguida, é simplesmente assumido que a equipe gastará um certo tempo em cada sprint corrigindo bugs relatados pelo Jira
4. Coloque o backlog do produto no Jira (isto é, vala o Excel). Trate os bugs como qualquer outra história.

Isso é realmente algo que precisa ser decidido por projeto ou existem soluções melhores? Posso pensar em problemas com cada uma dessas abordagens. Existe um híbrido vindo dessas abordagens que funciona melhor? Como você lida com isso em seus projetos?

Esta é uma pergunta muito boa e tenho algumas observações a respeito das diferentes abordagens desse problema.

1. Tratar todos os bugs igualmente com itens de backlog pode parecer uma boa ideia na teoria (trabalho rastreado em um único lugar), mas não funciona bem na prática. Os bugs são geralmente de baixo nível e mais numerosos, portanto, se você criar uma história de usuário individual para cada bug, as histórias "reais" serão obscurecidas em breve.
2. O tempo explícito em cada sprint reservado para correções é bom se feito de uma forma que seja visível para o product owner. Os bugs devem ser mencionados durante a reunião diária e a discussão sobre os bugs corrigidos deve ocorrer durante a revisão do sprint. Caso contrário, o product owner não estará ciente do que está acontecendo no projeto.
3. Colocar todo o backlog na ferramenta de rastreamento de bugs leva ao mesmo conjunto de problemas que em 1. Além disso, a maioria dos rastreadores de bugs não são projetados com Scrum em mente e usá-los para este propósito pode ser doloroso.

A solução que achamos mais satisfatória foi colocar uma única história de usuário chamada "Tickets" ou "Bugs" em cada sprint. Então, tal história pode ser dividida em tarefas de baixo nível que descrevem um bug específico (se conhecido durante o planejamento) ou meta-tarefas reservando um determinado número de horas para correção de bug geral. Dessa forma, o product owner tem visibilidade do processo e o gráfico burndown reflete o progresso.

Apenas lembre-se de fechar impiedosamente todos os "bugs" que são na verdade novos recursos e criar novos itens de lista de pendências para eles. Certifique-se também de corrigir todos os bugs relatados contra o sprint atual antes que ele termine, para considerá-lo concluído.

Na verdade, acho que a melhor resposta é jpeacock a partir desta pergunta. Você conta as horas gastas em correções de bugs para o scrum?

Deixe-me citar:

• Se o bug for fácil / rápido de consertar (uma linha, etc), apenas corrija-o.
• Se o bug não for trivial e nem um bloqueador, adicione-o ao backlog.
• Se o bug for um bloqueador, adicione uma tarefa (ao sprint atual) para capturar o trabalho necessário para corrigi-lo e comece a trabalhar nele. Isso requer que algo mais seja movido (do sprint atual) para o backlog para contabilizar as novas horas porque o total de horas disponíveis não mudou.

O primeiro passo é definir o que é um bug. Eu ensino que um bug só é um bug se for uma funcionalidade que não funciona na produção como foi planejada / projetada. Eles se tornam PBIs do tipo bug a serem priorizados em relação a novos desenvolvimentos. Funcionalidade ausente na produção é um Recurso e se torna um item normal do backlog do produto. Qualquer código defeituoso encontrado durante um sprint é considerado trabalho incompleto, já que você não passa para a próxima história até que a atual seja concluída; não é necessário rastrear esses defeitos no sprint, pois a equipe está sempre trabalhando no código ofensivo. Post-its podem ser muito úteis aqui para lembretes rápidos entre companheiros de equipe. Consertar código quebrado sempre tem precedência sobre escrever novo código.

Estoque é desperdício. O rastreamento de bugs é um inventário. Rastreamento de bugs é desperdício.

Tratar todos os bugs igualmente com itens de backlog pode parecer uma boa ideia na teoria (trabalho rastreado em um único lugar), mas não funciona bem na prática. Os bugs são normalmente de baixo nível e mais numerosos, portanto, se você criar uma história de usuário individual para cada bug, as histórias "reais" serão obscurecidas em breve.

Se você tem muito mais bugs do que recursos, precisa trabalhar em suas práticas de engenharia. Este é um cheiro de que algo está errado e o rastreamento não é a resposta. Vá mais fundo. Na verdade, os insetos estão sempre fedorentos. Eles não são legais e, se você tiver muitos deles, precisará encontrar a (s) causa (s), eliminá-la e parar de se concentrar em rastrear bugs.

Não rastreie defeitos em uma lista, encontre-os e corrija-os - Mary Poppendieck

Na verdade, se o inventário é um desperdício, que tal um inventário de defeitos ...

É por isso que sempre tento implementar uma mentalidade Stop-the-Line com desenvolvimento orientado a testes e integração contínua, para que possamos encontrar e corrigir a maioria dos defeitos, em vez de colocá-los em uma lista de retrabalho.

E quando os defeitos passam, nós os corrigimos antes de escrever um novo código (histórias com bugs não são feitas de qualquer maneira). Então, tentamos consertar nosso processo para torná-lo mais à prova de erros e detectar defeitos no momento em que ocorrem.

Não existe uma solução única para todas as necessidades e cada projeto é diferente. Os bugs também podem ser classificados de missão crítica a dificilmente vale a pena consertar.

A menos que seja crítico para o funcionamento do sistema, prefiro que os bugs se tornem cartas de história. Isso torna a prioridade do desenvolvimento de recursos vs. correção de bugs realmente explícita. Em um cenário em que as correções de bugs são consideradas "fora do sprint", a correção de bugs pode passar a corrigir bugs realmente triviais enquanto recursos de negócios realmente importantes não estão sendo desenvolvidos.

Passamos por uma série de permutações antes de definir o bug como uma abordagem de história. Experimente algumas coisas diferentes e repita-as nas reuniões retro da equipe.

Em nosso caso (desenvolvimento greenfield, 2-3 desenvolvedores) os bugs encontrados são anotados, marcados claramente como um bug e com base em sua gravidade, eles são atribuídos à próxima iteração ou deixados no backlog. No caso de bugs críticos e urgentes, eles são adicionados à iteração em andamento.

Não sei por que algo tão simples como consertar bugs é complicado com regras. Scrum tem pouquíssimas regras, lembra? Cada recurso, Suporte, Recomendação ou Defeito é um problema de Backlog no Scrum, não há diferenciação. Então, como diz o guia do Scrum: as tarefas em um Sprint nunca são limitadas ao que você decide durante a reunião de planejamento, o Daily Scrum ajuda as pessoas a discutirem "impedimentos" ao longo do caminho.

Por quê?

Então, você discute e pensa racionalmente como uma equipe se quiser que o defeito, ou seja, o problema do backlog, vá para o PBI ou permaneça neste Sprint e o entregue ...

A melhor pergunta é como faço para parar de criar bugs na fase de desenvolvimento? veja -> http://bit.ly/UoTa4n

Se estiver identificando e documentando bugs, você terá que fazer uma triagem e corrigir em algum momento futuro. Isso leva a "sprints de estabilização", ou seja, um sprint inteiro apenas para corrigir bugs. Ou você pode adicioná-los de volta ao backlog e priorizá-los como parte de algum sprint futuro. Isso também significa que você fornecerá e esperará que o software seja aprovado e lançado com bugs conhecidos (P3 e P4, também conhecidos como cosméticos e secundários).

Isso não é realmente ágil?

Apresentei a ideia em nosso projeto de introduzir um sprint de correção de bug curto a cada três sprint. Nossos sprints atuais são de três semanas.

A ideia é que isso permitirá que todos os desenvolvedores se concentrem na correção de bugs juntos, permitir o foco apenas em novas histórias em sprints regulares e manter um foco regular na redução do débito de tecnologia.

As correções de bugs serão agrupadas em histórias relevantes e priorizadas. A ênfase não está no dimensionamento antes do sprint, já que os desenvolvedores se esforçam para dimensionar as correções de bugs sem se prenderem a entender a natureza do defeito.

Alguém tentou fazer isso ou tem algum feedback sobre como eles acham que isso pode funcionar?

Saúde, Kevin.