Como explicar uma iteração de correção de bug?

Implementamos o Scrum com bastante sucesso nos últimos 5 meses. No entanto, estamos a 3 semanas longe de PROD sem nunca fazer qualquer teste de integração end-to-end. OUCH! Eu preciso de ajuda. Sem abordar as causas disso (neste ponto), precisamos agora planejar a iteração atual, que consiste em pequenas melhorias e MUITAS correções de erros ainda desconhecidas. Como você explica esse cenário? Como você planeja sua iteração para corrigir erros ainda a serem encontrados?

Scrum ou não, a correção de bugs é basicamente impossível de prever. O melhor que acredito que você pode fazer é:

• Comece o teste imediatamente, sem estimativa inicial de quando será feito.
• Quando você descobrir cada bug, faça uma análise inicial até o ponto em que possa estimar.
• Estime o erro e decida se ele deve ser corrigido e se deve ser corrigido para a versão inicial.
• Se tiver que ser corrigido, adicione-o à iteração.
• Traçar um gráfico de queima. Em algum momento, ele começará a diminuir, o que significa que você não encontra mais erros mais rapidamente do que consegue corrigi-los. Nesse ponto, você poderá fornecer uma estimativa aproximada (e progressivamente mais precisa) quando a liberação puder ser feita.

Do que você deve certificar-se da próxima vez que começar a testar cedo e corrigir os erros à medida que avança. Todas as metodologias sensatas, ágeis ou não, exigem a correção de bugs conhecidos antes de avançar com novos recursos. Além disso, você deve contabilizar quanto tempo foi gasto corrigindo cada recurso, para poder melhorar sua estimativa para implementar o recurso no estado depurado no futuro.

A estimativa e a correção de bugs são bem cobertas por Joel Spolsky no Agendamento Baseado em Evidências e no Bug Fixed ' . Não é relacionado ao Scrum, mas acho que é geral o suficiente para aplicar muito disso.

Como explicar uma iteração de correção de bug? Como você planeja sua iteração para corrigir erros ainda a serem encontrados?

Em relação a uma "iteração de correção de bug". Os erros encontrados não devem ser tratados de maneira diferente das histórias. Trabalhe com a equipe para estimar o esforço (pontos da história) para corrigir cada bug e trabalhe com o proprietário / cliente do produto para decidir se o bug deve passar para a próxima iteração.

Em relação a "erros ainda por serem encontrados". De preferência, a equipe está encontrando e corrigindo problemas a cada iteração. Caso contrário, discuta isso em sua próxima retrospectiva. Se a qualidade do produto for tão baixa que a liberação não for possível, mova imediatamente seus melhores "localizadores de bugs " para encontrar bugs (não corrigindo). Se a qualidade for alta o suficiente para fornecer uma versão beta para selecionar usuários - faça-o. Se não puder, forneça no mínimo demonstrações ao vivo do usuário discutindo áreas fracas que você recomenda que precisem ser aprimoradas.

Não planejamos 'iterações de correção de bugs', mas planejamos iterações de teste do sistema antes de cada versão. O teste do sistema consiste em testes de integração, regressão e realese em todas as partes do produto. Os testadores testam o produto (um sistema legado bastante grande) e os desenvolvedores corrigem os bugs encontrados. Se nenhum erro for encontrado, começamos a investigar os cronogramas dos recursos para o próximo projeto ou trabalhamos nas melhorias internas.

Atualmente, planejamos seis semanas de testes do sistema após o congelamento do código (para um projeto de cinco meses, incluindo o teste do sistema), para garantir que tudo funcione. Isso está no topo de todos os testes realizados durante as iterações de implementação.

Você precisa definir um conjunto de critérios de "release". Estes podem incluir:

• Tempo médio entre falhas
• Número de defeitos encontrados por dia
• Gravidade dos defeitos encontrados por dia
• Número de defeitos pendentes

etc.

Em seguida, no final de cada iteração, você tem algumas pessoas testando (manualmente ou escrevendo testes automatizados) e outras corrigindo a verificação para verificar se você atendeu aos seus critérios. Se você tiver liberado, se não, faça outra iteração.

Deve haver a possibilidade de uma substituição sobre isso, assim como, frequentemente, os números brutos não apresentam uma imagem realista do aplicativo. Você pode ter alguns defeitos realmente graves, mas eles só se manifestam sob condições raras com as quais você pode conviver a curto prazo.

Uma maneira de fazer isso é escrever histórias para o teste de integração, durante o qual você escreve novas histórias para todos os erros encontrados e, em seguida, corrige as histórias de erros na próxima iteração.

Outra maneira de fazer isso é criar uma história que diz "Corrija os erros encontrados nos testes de integração". Nas versões anteriores, você deve ter uma idéia de quantos problemas geralmente são encontrados e de como são difíceis de corrigir, para poder atribuir pontos da história com base nesse conhecimento. Talvez você possa dividi-lo em componentes, se isso o torna mais gerenciável. Sempre há incerteza inevitável nisso. Adicione alguns pontos extras da história para explicar isso.

Você provavelmente já percebeu tardiamente que a melhor maneira é incorporar um pouco de teste de integração em cada iteração, se possível. Parabéns por reconhecer isso e melhorar seu processo apenas um pouco para o seu próximo lançamento.