BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

Como terminar histórias sem deixar bugs para trás

| por Lucas Souza Seguir 0 Seguidores em 03 jan 2011. Tempo estimado de leitura: 2 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

"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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT