"Brian" na lista de discussão do Scrum descreve um problema de qualidade:
Nosso time de desenvolvimento está tendo dificuldades em terminar histórias com um baixo número de bugs no final de nossas iterações. Sugeriram que mesmo que tenhamos corrigido os problemas, uma nova história de QA seja criada.
Jorge Rowies propõe duas alternativas para criar uma nova métrica de qualidade:
As pessoas de QA estão no mesmo time que os desenvolvedores? Se não estão, seria um bom começo para reduzir a quantidade de bugs.
Cada uma das histórias tem testes de aceitação? Se tem, quem escreve estes testes? Eles estão escritos de maneira clara?
Malcolm Anderson recomenda evitar novos desenvolvimentos em favor de aperfeiçoar histórias já existentes:
Não seria mais fácil ter uma pessoa de QA aprovando uma história antes do desenvolvedor começar a trabalhar em uma nova história.
Isso deve baixar o seu número de bugs para quase zero.
Desenvolvedores tem uma tendência a querer trabalhar com "funcionalidades novas" e desenvolvedores também podem codificar rapidamente e mal afim de começar a trabalhar mais cedo com "funcionalidades novas".
Jack Milunsky defende o foco na definição de pronto:
Seu time precisa arranjar o critério de "Pronto" para cada história. Isso inclui testes de aceitação e critérios de qualidade. Se você ainda tiver bugs para uma determinada história no final do sprint, então esta história não está pronta. Você tem que completar o ciclo de desenvolvimento, teste e correção dentro do mesmo sprint. Isso irá deixá-lo com um bom nível de qualidade.
Peter Skeide tem diversas sugestões para resolver estes problemas de qualidade:
- Melhore a maneira como as retrospectivas são feitas, assim elas podem efetivamente detectar e direcionar quais os problemas de qualidade.
- Se existirem diferenças de qualidade no código escrito pelos diferentes membros do time, faça os melhores programadores encontrarem maneiras de melhorar a qualidade do código escrito pelos outros.
- Foco na prevenção de defeitos, não apenas na detecção. As ferramentas que podem ajudar são: inspeções de código e checklists.
- Use programação pareada para melhorar o compartilhamento de conhecimento dentro do time.
- Faça uso regular de ferramentas de análise de códigos estáticos ou dinâmicos.