Como os relatórios de erros levam em consideração um sprint?

Estive lendo sobre Scrum recentemente. Pelo que entendi, é realizada uma reunião antes do início do sprint, para decidir o que será movido do backlog do produto para o próximo backlog do sprint. Quando um recurso é concluído no sprint atual, ele entra no intervalo "Pronto para o controle de qualidade" e é nesse ponto que estou ficando confuso. Os relatórios de erros retornam ao backlog do produto? Presumo que eles não possam voltar ao backlog do sprint, pois já decidimos que trabalho será feito para esse ciclo? O que acontece quando o controle de qualidade encontra um bug? Onde isso vai?

Na minha opinião, existem duas soluções principais para isso:

1. Não aloque 100% do seu tempo para o sprint atual. Reserve de 10 a 15% do seu tempo para a correção de bugs e outras atividades de suporte que surgirão durante o sprint. Então, se um bug de bloqueio aparecer, você terá tempo para corrigi-lo no sprint atual.

   Se surgir um bug que não bloqueia, você pode corrigi-lo no final do sprint atual, se tiver o tempo restante ou ele entra no "pote" para o próximo sprint.

2. Faça um sprint de "correção de bugs" de vez em quando. Provavelmente antes do próximo grande lançamento. Você pode usar isso para "limpar" o máximo de erros que você pode / deseja corrigir para a próxima versão.

Provavelmente nenhuma dessas soluções é verdadeira no Scrum "puro", mas elas funcionam no mundo real.

Durante um sprint "regular", você ainda pode incluir tarefas para corrigir erros específicos, tratando-os como se fosse uma nova funcionalidade.

No mundo ideal do scrum, não existe um depósito "Pronto para controle de qualidade" (pelo menos não visível fora da equipe), pois um recurso não é concluído até que as atividades de controle de qualidade sejam concluídas e os bugs corrigidos. Isso significa que deve haver pessoas na equipe que possam assumir as atividades de controle de qualidade.

No mundo real, você pode ter uma equipe de controle de qualidade / teste separada que trabalhe em paralelo com a equipe de scrum (desenvolvimento). Nesse caso, a seguinte abordagem pode funcionar bem:

1. Pouco antes de um recurso ser colocado no bloco "Pronto para controle de qualidade", o desenvolvedor (principal) desse recurso e o representante de controle de qualidade que (provavelmente) assumem o controle se sentam juntos e percorrem o recurso. Quaisquer problemas encontrados naquele momento são resolvidos antes que o recurso seja colocado no intervalo "Pronto para controle de qualidade". Observe que essa não é uma parte inicial de uma demonstração do sprint. Destina-se a obter os frutos baixos pendentes nas questões resolvidas o mais rápido possível.

2. Quaisquer problemas encontrados após a entrega ao controle de qualidade devem ser colocados no backlog do produto como histórias, a serem levados em consideração na próxima reunião de planejamento.

3. Para erros de rolha, reserve uma quantidade fixa de tempo a cada sprint. Se, próximo ao final do sprint, ainda houver tempo nesse buffer, ele poderá ser preenchido com problemas de menor prioridade.

Com base em como você descreve seu fluxo de trabalho a partir de uma história, com um backlog de produto, um backlog de sprint e outros buckets (suponho que eles pareçam algo como "em andamento / em desenvolvimento", "pronto para controle de qualidade", "concluído "), parece que você está adicionando alguns elementos do Kanban ao Scrum - uma combinação não incomum às vezes chamada Scrumban . A noção de Kanban adiciona limites ao tamanho de cada intervalo para impedir que seus desenvolvedores tenham muitas histórias em andamento ou que seus testadores testem demais. É semelhante à velocidade para mover itens do backlog do seu produto para o backlog do sprint, mas dentro de um sprint.

Eu abordaria o problema fazendo com que suas tarefas sejam as histórias do usuário, com as histórias do usuário passando do backlog do produto para o sprint backlog, para o bucket em andamento, para o bucket de QA pronto para o bucket final. Depois que o desenvolvedor termina a história (com base na sua definição de concluído), ele a move para o intervalo "pronto para o controle de qualidade", onde a próxima pessoa a extrai e trabalha nele. Se houver algum problema, um defeito será inserido no seu sistema de rastreamento e a história do usuário será movida para o bucket final, pois ele foi implementado e testado. Se não houver problemas, ele será movido diretamente para o balde pronto.

Quando o defeito vem de dentro do seu sprint, não há problema em colocá-lo novamente no backlog do sprint (ou talvez algum tipo de intervalo "em andamento"). Uma história com defeitos conhecidos é geralmente considerada inacabada. Se for determinado que não há tempo suficiente para terminar a história ou se os defeitos forem atribuídos à não compreensão da história, uma opção pode ser descope-la totalmente do sprint até que você possa entender melhor a necessidade - nesse caso, eu recomendaria não incluindo a implementação defeituosa no seu produto lançado.

Se, devido ao seu defeito, a história não terminar no seu sprint, isso aparecerá nos seus cálculos de velocidade para futuros sprints. Histórias inacabadas (histórias defeituosas) não fornecem pontos de história, então você planeja sprints menores. Menos histórias complexas levarão a mais tempo nos testes e o incentivarão a dedicar mais esforço para encontrar defeitos mais cedo - a prevenção de defeitos não é apenas mais barata, mas leva menos tempo do que a soma do tempo gasto para identificar a existência de um problema, localize o problema no design ou implementação, corrija o problema e teste novamente para garantir que o problema foi resolvido sem nenhum outro impacto negativo no sistema. Como o timebox é essencial, a capacidade de evitar defeitos leva a sprints mais produtivos no futuro.

Independentemente do que você faz, você deve envolver o Dono do Produto (que, esperançosamente, é um representante de cliente / usuário) quando se trata de decidir como priorizar defeitos. Alguns defeitos podem ser aceitáveis ​​para serem lançados em uma versão se houver soluções alternativas ou forem raras, o que significa que o defeito aparecerá como uma história em um sprint futuro. Outros defeitos podem ser urgentes e "showstoppers" - eles devem ser corrigidos imediatamente e um produto não pode ser usado se existir.

Se o tempo gasto com o defeito é bastante consistente de uma mola para a outra, então você realmente não precisa gerenciá-lo - a velocidade da sua equipe refletirá isso.

Caso contrário, se a correção de defeitos puder ser planejada (ou seja, você pode adiá-la pela duração de um sprint), faça-o.

Caso contrário, o Scrum não terá uma boa resposta - os defeitos serão uma alteração não planejada do conteúdo do sprint no meio de um sprint, o que significa que você precisará renegociar seus compromissos.

Um sprint deve ser independente. Isso significa que todas as atividades, incluindo controle de qualidade, correção de erros e documentação, devem ser concluídas antes do final do sprint. As atividades de pré-implantação também devem ocorrer antes do término do sprint.

O problema de não terminar é que você se distrai no próximo sprint.

Se, no sprint B, você precisar voltar sua atenção ao código do sprint A para corrigir os erros, sua capacidade de se concentrar nas tarefas do sprint B sairá pela janela. O mesmo acontece com a sua velocidade de avanço.

No meu último trabalho, os sprints foram agendados com base no conceito de "horário ideal"; de um dia de desenvolvedor de 8 horas, 5 horas foram o TDD, com novos recursos que nunca existiam antes. Os outros três estavam fazendo todo o resto; e-mails, reuniões, código de compilação / confirmação / atualização, trabalho de refatoração e, sim, correções de bugs.

Consideramos um trabalho realizado, mas ainda havia bugs para contar a velocidade da equipe; no entanto, os bugs eram dívidas técnicas que precisavam ser pagas quando acumuladas e, portanto, obviamente deviam ser evitadas. Nunca tivemos um problema real com pessoas fazendo trabalhos mal feitos; ninguém queria ter que voltar atrás.

De vez em quando, também tínhamos sprints para corrigir bugs. Tínhamos a sorte duvidosa de ter um cliente que não podia fornecer requisitos no ritmo que os consumíamos; portanto, para deixar o backlog aumentar um pouco, muitas vezes agendamos duas semanas em que o objetivo era "matar o máximo de defeitos e pague o máximo de dívida técnica possível ". Tecnicamente, a velocidade para um sprint é zero, mas é um trabalho que precisa ser feito e que faz o cliente feliz, por isso vale a pena.