Esta é uma dúvida comum na aplicação prática do Scrum em projetos de construção de software. Gostaria de saber como a fauna dos métodos ágeis trata os bugs com Scrum.

Os bugs são colocados no Product Backlog?
Os bugs são colocados em um backlog de defeitos específico?

Exibições: 292

Respostas a este tópico

Bem, não sei como se trabalha em outras empresas, mas na última instituição em que adotei scrum os bugs eram colocados nos sprints backlogs para serem solucionado no sprint diário (24 horas).
Eu já vi duas variações, sendo elas:
- Product Backlog de Ajustes para bugs reportados pelo usuário ou equipe de teste e um Sprint Backlog para cada defeito.
- Sprint Backlog não associado ao Product Backlog. O "prazo" para resolução de defeitos nesse caso era o final do sprint corrente.
Adriano, passei pelo mesmo dilema há uns meses atrás. Considerando o tempo destinado ao Scrum diário e à revisão do sprint, acho praticamente inviável manter a lista de bugs no backlog de produto. Se o número de bugs for grande, tal inclusão tende a diminuir a agilidade das revisões.

Neste caso, acho melhor manter em backlog separado e de preferência usando algum software de controle específico de defeitos como o Bugzilla ou GNATS. E cada grupo correlato (origem e dificuldade) de bugs pode gerar uma entrada no backlog de produto. Sendo assim, a entrada é passível de planejamento e estimativa (ex: no planning poker).

Bom... esta é minha visão e como tentei conciliar. Vasculhei o "Agile Software Development with Scrum" do Schwaber, mas não achei nada categórico. O link inspirador e que facilitou a decisão foi: http://jeffsutherland.com/2002/12/scrum-dealing-with-bugs-in-sprint...
Aqui criamos uma pequena extenção no Sprint Backlog para os bugs encontrados, mantemos um histórico dos bugs para que possamos sempre que possível minimiza-los em cada novo projeto.
Matemos tudo na intranet e temos um pequeno painel de evolução de tudo que ocorre no final de cada Sprint.

Estou enviando um simples exemplo para melhor visualização do que fazemos.
Anexos
Lá em "casa", não registramos os bugs em sprint backlogs. Os bugs identificados durante a codificação, são reportados e acompanhados nas reuniões diárias, semelhante ao processo descrito pela Maria Cristina, tendo como prazo o intervalo de tempo até a próxima reunião.
Em cada sprint, fazemos o planejamento de testes das regras de negócio que devem ser atendidas no sprint. Esse planejamento ocorre em paralelo às atividades de análise e codificação, por exemplo. Após a entrega e integração de um determinado componente, são realizados os testes das regras de negócio envolvidas.
Durante planejamento do sprint, é reservado um tempo estimado para a correção dos bugs das regras de negócio. Esse tempo varia de acordo com itens como tamanho e complexidade do sprint.
Na reunião de final de sprint atualizamos as Lições Aprendidas com os problemas encontrados e as soluções adotadas.
No meu caso o backlog de defeitos é mantida em separado no Bugzilla. Na prática temos uma fase de testes de aceitação onde uma versão do produto é homologada. Temos uma equipe de teste especializada que não está full-time no time e trabalha sob demanda em paralelo com a equipe de implementação.
Na Infoq foi publicada esta semana uma notícia bem interessante pelo meu amigo Mark Levison que trata justamente sobre este tema.

Ingles: http://www.infoq.com/news/2009/07/coping-with-bugs

Portugues: http://www.infoq.com/br/news/2009/07/coping-with-bugs

Abraço
Wagner,
outro link no InfoQ sobre este assunto.

Trecho do Livro: Agile Testing
http://www.infoq.com/br/articles/agile-testing-book-excerpt

abs

RSS

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço