Existe um benefício marginal na correção de bugs [fechado]

Ouvi de um ex-colega que nem todos os bugs precisam ser corrigidos, porque à medida que você desce na lista de bugs prioritários, o caso de uso que causa esse bug se torna mais obscuro ou a satisfação do cliente diminui. Mas você ainda precisa gastar um tempo considerável corrigindo esse bug.

Em um esforço para convencer o proprietário do produto sobre esse conceito, não consegui encontrar bons recursos. Tudo o que pude encontrar foi discutir se existe ou não um custo marginal no desenvolvimento de software.

Existe realmente um benefício marginal na correção de bugs? Existe um termo diferente que explica esse conceito?

Do ponto de vista comercial, uma correção de bug não é diferente de uma solicitação de recurso. Tem um certo custo no tempo de desenvolvimento e um certo valor para os clientes. Se um erro não for crítico, pode fazer totalmente sentido para os negócios priorizar um recurso valioso acima da correção.

Mas, do ponto de vista técnico, os bugs podem ser mais críticos, porque indicam um erro em uma base na qual outros códigos podem usar / desenvolver; nesse caso, o erro é "contagioso" e adiciona custo à manutenção futura. Portanto, não corrigir um erro é uma dívida técnica que requer gerenciamento, enquanto não implementar um recurso não tem um custo contínuo. Mas o nível de dívida técnica incorrida por um bug depende muito da natureza do bug.

Todos esses fatores devem ser levados em consideração na priorização.

Quanto à existência de um benefício marginal na correção de bugs: esse é um dado. Como nem todos os erros são iguais em gravidade, você prioriza naturalmente os erros mais importantes primeiro. Portanto, quanto mais erros você corrigir, menor será o valor marginal de corrigir o próximo. Mas se alguma vez atinge o nível em que a correção do bug não vale a pena é uma decisão de negócios e não técnica.

Aqui está uma boa referência

http://www.joelonsoftware.com/articles/fog0000000043.html

Você corrige bugs antes de escrever um novo código? A primeira versão do Microsoft Word para Windows foi considerada um projeto de "marcha da morte". [...] porque a fase de correção de bugs não fazia parte do cronograma formal [...]

A Microsoft adotou universalmente [...] algo que a maior prioridade é eliminar erros antes de escrever qualquer novo código [...] Em geral, quanto mais você esperar antes de corrigir um erro, mais caro (em tempo e dinheiro) será corrigido. .

Você pode ter certeza de que quanto mais tempo esses bugs estiverem aqui, mais tempo será necessário para corrigi-los quando eles se tornarem a prioridade. Portanto, em vez de ter um benefício bruto no momento, você está evitando uma perda mais cara no futuro.

Uma boa maneira de gerenciar isso seria definir uma quantidade de tempo alocada para lidar com problemas de lista de pendências. Isso não seria tão complicado quanto a Microsoft, mas garantirá uma grande quantidade de solução de problemas futuros, se eles ainda não forem o seu problema, mesmo que o cliente realmente não se importe.

Em um esforço para convencer o proprietário do produto sobre esse conceito, não consegui encontrar bons recursos.

Supondo que você esteja trabalhando para uma organização comercial, certamente haverá alguém que conhece a Análise de Custo-Benefício .

Sua organização possui uma quantidade finita de recursos para desenvolvedores e uma lista infinita de coisas benéficas a serem feitas. Essas coisas benéficas incluem a adição de novos recursos e a remoção de erros existentes - a remoção de um erro melhora o software, assim como a adição de um novo recurso.

Então, obviamente, existem decisões a serem tomadas sobre como alocar esse recurso finito contra essa lista infinita, e não é de surpreender que o resultado seja que alguns erros não sejam corrigidos agora, ou na próxima semana, ou no próximo ano, ou em fato de sempre.

Se você está procurando uma abordagem mais estruturada aqui, pode tentar o sistema PEF / REV que atribui números às visualizações de Usuário e Programador de um bug, como ponto de partida para decidir o que é corrigido - e o que não é.

Veja também esses dois posts aqui sobre Engenharia de Software:

Resolvendo quais erros fornecerão o maior custo benefício

Quase todos os erros relatados são de alta prioridade

Nem todos os aspectos não intencionais ou indesejáveis ​​do comportamento do software são erros. O importante é garantir que o software tenha uma gama útil e documentada de condições nas quais pode confiar para operar de maneira útil. Considere, por exemplo, um programa que deve aceitar dois números, multiplicá-los e gerar os resultados e que gera um número falso se o resultado for maior que 9,95, mas menor que 10,00, maior que 99,95, mas menor que 100,00, etc. Se o programa foi escrito com a finalidade de processar números cujo produto estava entre 3 e 7 e nunca será chamado a processar outros, fixar seu comportamento com 9,95 não o tornaria mais útil para o objetivo a que se destina. Pode, no entanto, tornar o programa mais adequado para outros fins.

Em uma situação como a acima, haveria dois cursos de ação razoáveis:

1. Corrija o problema, se isso for prático.

2. Especifique os intervalos nos quais a saída do programa seria confiável e declare que o programa é adequado apenas para uso em dados conhecidos por produzir valores dentro de intervalos válidos.

A abordagem nº 1 eliminaria o erro. A abordagem nº 2 pode tornar o progresso menos adequado para alguns propósitos do que poderia ser, mas se não houver necessidade de programas lidar com os valores problemáticos que podem não ser um problema.

Mesmo que a incapacidade de manipular os valores 99,95 a 100,0 corretamente seja resultado de um erro de programação [por exemplo, decidir imprimir dois dígitos à esquerda do ponto decimal antes de arredondar para um lugar depois, produzindo 00,00], isso deve ser considerado apenas um bug se o programa seria especificado como produzindo uma saída significativa nesses casos. [Aliás, o problema mencionado ocorreu no código Turbo C 2.00 printf; nesse contexto, é claramente um bug, mas o código que chama o printf defeituoso só seria incorreto se pudesse produzir resultados nos intervalos problemáticos].

Em um sentido amplo, sim, nem todos os erros precisam ser corrigidos. É tudo uma questão de analisar a relação risco / benefício.

O que geralmente acontece é que a empresa terá uma reunião com líderes técnicos e partes interessadas para discutir bugs que não estão obviamente na pilha de 'necessidade de consertar'. Eles decidirão se o tempo (= dinheiro) investido na correção do bug valerá a pena para os negócios.

Por exemplo, um 'pequeno erro' pode ser um pequeno erro de ortografia / gramática na seção Termos e Condições de um site. O indivíduo que levantou isso pode achar que é muito pequeno mudar, mas a empresa reconheceria o dano potencial que isso poderia causar à marca e a relativa facilidade de corrigir alguns caracteres.

Por outro lado, você pode ter um bug que parece importante, mas é difícil de corrigir e afeta apenas uma quantidade desprezível de usuários. Por exemplo, um link menor de botão é quebrado para usuários que usam uma versão herdada do Google Chrome e também tem o Javascript desativado.

Outras razões para a empresa NÃO consertar um bug podem ser que o tempo investido atrasaria o projeto por um período inesperado ou que o tempo do desenvolvedor seria melhor gasto trabalhando em outras correções / codificação. Também pode ser que o bug seja pequeno o suficiente para poder ser ativado e, em seguida, corrigido posteriormente.

Espero que explique o conceito um pouco melhor! Eu certamente evitaria pensar sobre isso em termos gerais - todo bug é único e deve ser tratado como tal.

Como, na lista de prioridades de bugs, o caso de uso que causa esse bug se torna mais obscuro ou a satisfação do cliente diminui.

Então o "argumento" deles é realmente

Se você ignorar o bug por tempo suficiente, o Usuário esquecerá qual era o problema ou encontrará uma maneira de contorná-lo.

Os erros devem ser priorizados e tratados "em ordem", assim como as novas solicitações de recursos (mas, sem dúvida, acima e acima de tudo).