Bug Fixação Tempo de Alocação

Question

Temos sido solicitado por um cliente para nos dar uma estimativa de tempo em cada bug que temos.

Embora nós temos um cronograma definido para a correção de erros e ter alocado tempo para isso, não temos uma alocação de tempo em cada um dos erros que temos. Simplesmente, temos priorizado os nossos erros e ter garantido que Máximas erros prioritárias será corrigido no tempo previsto.

Eu não sou um fã de alocar tempo para erros, simplesmente porque:

1. É geralmente impreciso. É muito difícil descobrir quanto tempo levaria para correção.
2. Perda de tempo.
3. afeta a qualidade do código
4. Cria mais erros no longo prazo (Podemos perder certas coisas em nossa tentativa de concluí-lo dentro do prazo).

Como devemos abordar esta questão em que não deseja fornecer o número de horas por bug, mas apenas um período de tempo, como o que os erros serão corrigidos?

Como você alocar tempo para os seus erros? É eficaz? Vale o tempo e esforço?

Answer 1

A única resposta que posso dar é para ser extremamente conservador. Adivinhe quanto tempo vai demorar, e múltipla seu palpite por quatro. Usar isso como sua estimativa. Como você disse, é muito difícil descobrir quanto tempo as coisas vão tomar para correção, e é melhor dizer que vai demorar mais tempo do que ele realmente faz do que ser apanhado "quebrar o seu prazo" porque você não bastasse conservador.

Answer 2

A empresa que eu trabalho para muitas vezes recebe pedidos razoáveis ??de nossos clientes. A principal coisa a lembrar é que os clientes querem estar bem informado. Nós temos encontrado a melhor maneira de fazer isso é em termos de relatórios de status.

Então, primeiro fazer um trabalho muito bom de explicar a nossa posição. No seu exemplo, isso seria algo como isto:

Temos um cronograma definido para a fixação dos bugs no nosso projeto, o que temos historicamente um bom historial de ficar dentro do cronograma. No entanto, o processo de detalhamento quanto tempo cada bug vai demorar para correção é bastante propenso a erros. Nós seríamos felizes para lhe fornecer atualizações semanais (ou duas vezes por semana ou diariamente dependendo do cliente) sobre os bugs que foram corrigidos e as correções que foram testados.

No entanto, eu acredito que é bom para tentar estimar quanto tempo cada bug vai demorar para correção. A razão para isso é que você precisa entender o que o tempo total para corrigir todos os erros irá tomar. Você não será capaz de obter uma estimativa precisa se você não tem uma estimativa para quanto tempo as partes individuais levará para correção. Estes podem ser estimativas aproximadas de curso (estimado não superior a passar uma hora pesquisando o problema) - você não quer perder muito tempo estimar. Então eu normalmente levar em consideração um extra de 20%. Assim dizem as estimativas para os erros são 3 dias, 5 dias, e 2 dias. Então eu informar o cliente que deve ser capaz de corrigir os erros em 12 dias. Então é claro que você pode precisar adicionar mais tempo para testar e re-embalar o seu produto antes que você possa dar-lhes uma entrega.

Answer 3

Não pense nisso em termos de estimar quanto tempo os erros tomar para correção, porque você não pode estimar que corretamente.

Pense nisso em termos de gestão de raiva cliente . Se você dizer-lhes os erros terá pouco tempo para corrigir e eles acabam tendo 3 meses, seu cliente vai ser feliz com você agora e furioso com você no futuro.

Se você dizer-lhes os erros terá 3 meses para corrigir e eles realmente levar 3 meses para correção (que vai), seu cliente vai ficar furiosa agora e feliz com você no futuro.

Eu costumo dizer erros levará pouco tempo (2-3 dias parece ser um número bom pacificadora).

Answer 4

Deve ser o mesmo que estimar qualquer outra tarefa que você tem. Dividi-la em mais pequenas tarefas possíveis e estimar aqueles com a maior precisão possível com estofamento para o inesperado. Em seguida, dar-lhes uma gama de modo que você não está preso a uma data específica em tarefas que não estão bem definidos. Não há diferença entre a estimativa de tempo para corrigir um bug e estimar o tempo para implementar um recurso com os requisitos nebulosos.

Answer 5

Você tem razão, as estimativas são geralmente imprecisos.

Talvez você quer perguntar-lhes o quanto cada erro custa-lhes se ele vai unfixed. Então você pode executar o cálculo apropriado para descobrir se eles nunca deve ser fixado, e quanto tempo você (ou realista, eles) pode dar ao luxo de dedicar a cada bug.

Answer 6

Porque não basta escolher várias bandas de gravidade bug, por exemplo, Uma hora, 1/2 dia, 1 dia, 1 semana e atribuir contra eles. Geralmente você terá uma sensação de um bug - aqueles para os quais você não tem idéia, colocar a pior figura caso a ele

Eu não acho que você estaria quis estimar em qualquer nível mais fina do que, pelos motivos que você citou (levando muito tempo para investigar, etc.)

Eu não acho que é um desperdício de tempo. Seu cliente quer saber mais do que o número de bugs e sua prioridade -. Eles querem uma sensação de quanto ainda resta de trabalho

Sob nenhuma circunstância deve este resultado em você gerar mais bugs. Você não deveria estar correndo contra o relógio para corrigir estes. Se você cerca de 1 dia e tooks 10 horas, isso é ok. Se você estimada uma semana e levou 2 horas, bom resultado!

Este é simplesmente um exercício de estimativa!

Answer 7

Geralmente nós concordamos que os erros têm de ser fixado para uma versão particular, e, em seguida, definir um prazo para a fixação todos os bugs. Para cada bug indivíduo existe uma grande quantidade de incerteza / variabilidade quanto tempo pode demorar para corrigir, mas que tende a sair média com um maior número de bugs. Para certos erros que você sabe que vai demorar mais tempo, pode ser possível para dar algumas estimativas, por exemplo, se você precisa escrever um simulador ou um framework de teste para ele.

Answer 8

Se estes são os erros que foram encontrados e relatados, então você deve ser capaz de desenvolver uma estimativa sobre o tempo para corrigi-lo (e o tempo para reteste). A confiança da estimativa provavelmente será proporcional ao tempo que você gasta na estimativa, talvez explicar este custo para o cliente.

Se há uma série de relatórios de pequeno bug relacionado talvez você possa recolhê-los em um relatório omnibus. Isso pode evitar que o cliente tentando escolher quais erros para corrigir puramente baseado em estimativas individuais.