Quanto tempo deve ser gasto em bugs versus desenvolvimento original? [fechadas]

Esta pergunta é um pouco abstrata, mas espero que alguém possa me apontar na direção certa.

Minha pergunta é quanto tempo se pode dedicar aos erros de um projeto de software em relação ao tempo de desenvolvimento original. Percebo que há um grande número de fatores determinantes, mas eu esperava um colapso típico ou médio.

Por exemplo, se o Projeto A levar 40 horas para ser concluído e mais 10 erros de correção, esse projeto terá uma proporção de 4: 1.

Se outro Projeto (B) levar 10 horas para ser concluído, mas outros 8 em erros, ele terá uma proporção de 5: 4.

Este é um conceito documentado / pesquisado?

ATUALIZAR

Obrigado por todas as respostas informativas. Entendo que é impossível estabelecer um padrão para esse tipo de métrica devido a todas as variáveis ​​e fatores ambientais envolvidos. Antes de atribuir uma resposta, gostaria de saber se essa métrica tem um nome acordado para que eu possa fazer mais pesquisas. Gostaria de chegar a um ponto em que eu possa entender as medidas necessárias para gerar as métricas por mim mesmo e, eventualmente, criar um padrão de linha de base para o meu projeto.

A porcentagem de equilíbrio da capacidade total alocada para a fixação de defeitos é igual à taxa de injeção de defeitos .

Muitos fatores podem afetar essa taxa, entre eles, é claro: que tipo de produto a equipe está desenvolvendo, quais tecnologias e práticas técnicas utilizam, o nível de habilidade da equipe, a cultura da empresa etc.

Considerando a Equipe B, se eles criarem, em média, 8 unidades de retrabalho para cada 10 unidades de trabalho concluídas, o trabalho dessas 8 unidades criará novas 6,4 unidades de retrabalho. Podemos estimar o esforço total que eles eventualmente terão que gastar como a soma de uma progressão geométrica:

10 + 8 + 6,4 + 5,12 + ...

O número de bugs diminuirá exponencialmente com o tempo, mas o Time B tem um coeficiente em seu expoente que chegará a zero muito lentamente. Na verdade, a soma dos três primeiros termos da série acima é de apenas 24,4; dos cinco primeiros, 33,6; dos primeiros 10, 45; de toda a série, 50. Então, resumo da equipe B: taxa de injeção de defeitos, 0,8; desenvolvimento de características, 10/50 = 20%; fixação de defeitos, 80%. 20/80 é a alocação de capacidade sustentável.

Por outro lado, a equipe A está em muito melhor forma. Sua progressão é assim:

40 + 10 + 2,5 + 0,625 + ...

A soma desta série é 53 1/3, portanto, a alocação de desenvolvimento de recursos do Time A é de 40 / (53 1/3) = 75% e a alocação de correção de defeitos é de 25%, o que corresponde à taxa de injeção de defeitos de 10/40 = 0,25 .

Na verdade, todos os termos da série do Time A após os três primeiros são insignificantes pequenos. O que isso significa em termos práticos é que a Equipe A provavelmente pode eliminar todos os erros com algumas versões de manutenção, sendo a segunda versão muito pequena em escopo. Isso também cria uma ilusão de que qualquer equipe pode fazer isso. Mas não a equipe B.

Pensei nessa equivalência ao ler o novo livro de David Anderson, "Kanban" . (O livro trata de um assunto diferente, mas também trata de questões de qualidade.) Ao discutir a qualidade do software, Anderson cita este livro, de Capers Jones, "Avaliações de software, benchmarks e práticas recomendadas" :

"... em 2000 ... a qualidade de software medida para as equipes norte-americanas ... variou de 6 defeitos por ponto de função a menos de 3 por 100 pontos de função, um intervalo de 200 a 1. O ponto médio é de aproximadamente 1 defeito por 0,6 a 1,0 pontos de função. Isso implica que é comum que as equipes gastem mais de 90% de seu esforço consertando defeitos. "Ele cita um exemplo fornecido por um de seus colegas de uma empresa que passa 90% do tempo consertando seus bugs. .

A fluência com que Anderson passa da taxa de injeção de defeitos para a alocação da capacidade de fixação de defeitos ( demanda por falha é o termo para isso) sugere que a equivalência das duas coisas é bem conhecida pelos pesquisadores de qualidade de software e provavelmente já é conhecida há algum tempo. .

As palavras-chave na linha de raciocínio que estou tentando apresentar aqui são "equilíbrio" e "sustentável". Se retirarmos a sustentabilidade, há uma maneira óbvia de enganar esses números: você faz a codificação inicial, passa para o código em outro lugar e deixa a manutenção para os outros. Ou você aumenta a dívida técnica e a descarrega em um novo proprietário.

Obviamente, nenhuma alocação específica será adequada para todas as equipes. Se decretarmos que 20% devem ser gastos em bugs, se uma equipe tiver uma taxa de injeção de defeitos ultra baixa, eles simplesmente não terão bugs suficientes para preencher o tempo e, se uma equipe tiver uma taxa muito alta, seus bugs continuará a acumular.

A matemática que usei aqui é muito simplificada. Negligenciei coisas como custos de transação (reuniões de planejamento e estimativa, post-mortem etc.), que afetariam um pouco as porcentagens. Também omiti equações simulando a sustentação de um produto e o desenvolvimento de outro simultaneamente. Mas a conclusão ainda permanece. Faça o que puder, em termos de práticas técnicas, como testes de unidade, integração contínua, revisões de código etc., para reduzir sua taxa de injeção de defeitos e, consequentemente, sua demanda de falhas. Se você puder criar apenas um bug para cada 10 recursos, terá muito tempo livre para desenvolver novos recursos e satisfazer seus clientes.

Infelizmente, acredito que essa proporção é altamente variável em um determinado projeto. Será drasticamente afetado pelo seu ambiente, idioma, ferramentas, tamanho da equipe e experiência.

Você deve dedicar tempo a um bug apenas se o que você ganha com a correção for maior do que investe.

Use uma matriz como a seguinte (tempo horizontal necessário para corrigir o erro, tipo vertical de erro - impacto nos usuários)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Exemplo de problemas:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

A matriz pode ser mais complexa com diferentes níveis de gravidade, esforço, riscos, etc.

Você pode até criar uma classificação para cada bug e corrigi-las com base na classificação. Algo como:

Bug priority = Risk x Severity x Effort

* Pode ser (1-x) para alguns operandos, dependendo da escala que você escolher :)

Portanto, para responder à sua pergunta: depende do tipo de bugs, tempo / orçamento disponível etc.

É altamente variável, não apenas (é claro) na experiência e qualidade da equipe, e na dificuldade do projeto (não é o mesmo que criar outro aplicativo Web padrão que um novo kernel do SO), mas também na abordagem de gerenciamento que você vou usar.

Por exemplo, em um modelo em cascata, você pode definir com precisão o primeiro bug na primeira fase de teste, mas em um ambiente ágil pode ser difícil elevar uma linha dizendo "daqui em diante, estamos corrigindo bugs", pois os recursos podem mudar ( e para mim não é justo contar uma alteração de recurso como um bug)

Por experiência, eu digo que é algo que SEMPRE é subestimado e pode facilmente passar a mesma quantidade de horas que o "projeto original".

A resposta realmente correta seria zero horas em correções de erros porque seu código é perfeito. :-)

Realisticamente, não posso dizer que já ouvi alguém pedir ou oferecer esse tipo de proporção. Isso não quer dizer que algumas empresas não acompanhem o tempo de desenvolvimento e manutenção. Mas o desenvolvimento de um aplicativo é um prazo tão curto quando comparado à manutenção que a maioria das empresas não volta e calcula essa proporção. Eles provavelmente estão mais preocupados em saber por que um aplicativo requer manutenção e em aplicar essas descobertas a novos aplicativos.

Ter critérios muito amplos para o que é um bug pode quase dobrar seu tempo. Um gerente excessivamente zeloso que pensa que a solicitação de um cliente para aumentar um botão (eles têm problemas com o mouse) é uma ótima maneira de aumentar o número de bugs que corrigimos. Levará apenas alguns segundos para corrigir, porque não há necessidade de considerar, testar, recompilar e distribuir um patch. Ah, e é contado duas vezes como um novo recurso.

O maior fator determinante para isso é se você está trabalhando com uma nova tecnologia ou uma existente. Se você estiver trabalhando com algo novo e desenvolvendo algo que não foi feito ou já foi feito algumas vezes em circunstâncias diferentes, você gastará muito tempo corrigindo bugs e fazendo com que seu projeto funcione da maneira que deseja . Com frequência, os bugs serão o resultado de trabalharmos em um canto, e você precisará fazer uma quantidade significativa de trabalho para reestruturar o que fez. Além disso, muitos erros resultam de um entendimento incompleto das expectativas do usuário e da falta de conhecimento do desenvolvedor em casos extremos.

Se você estiver trabalhando em uma tecnologia estabelecida, a maioria dos problemas será tratada pelas bibliotecas ou pelas práticas da comunidade, e você poderá pesquisar no Google, comprar ou solicitar a solução de quaisquer erros que encontrar.

Em softwares críticos, a proporção de 1: 1 não é incomum. Somente para testes de unidade, vi indicadores mencionarem 1 dia de teste de unidade para cada 10 linhas de código.

Penso que esta questão é tendenciosa: parte do pressuposto de que a correção de bugs é uma fase semelhante ao desenvolvimento de novas funcionalidades . Este não é o caso.

Um bom desenvolvedor não gasta muito tempo depurando o código, pois seu código estará livre de erros desde o início. Um desenvolvedor ruim gasta muito tempo depurando seu código porque não pode criar abstrações adequadas para solucionar problemas reais.

Observe que os desenvolvedores devem testar seus próprios códigos por unidade. É responsabilidade do trabalho deles fornecer código sem erros. Portanto, é difícil separar a codificação da depuração.

É também uma questão de prioridade. Durante o desenvolvimento, o tempo necessário para corrigir um bug está relacionado exponencialmente ao tempo decorrido desde o momento em que você inseriu o bug no código. Portanto, a correção de erros deve ter maior prioridade do que o desenvolvimento de novas funcionalidades.

Então, ao invés de falar sobre "tempo gasto em bugs", você deve falar sobre "tempo gasto em testes" (testes de integração, testes de aceitação do usuário ...)

Acho que você está certo - você não receberá nenhuma métrica significativa devido ao seu número de fatores de influência.

Se ajudar, posso dizer que projetos em que trabalho (espaço corporativo, grandes sistemas complexos, muita integração com outros sistemas) têm uma proporção de cerca de 3: 2. A maioria destes não são falhas no código - mais geralmente falhas nas interfaces. Por exemplo, os sistemas A e B conversam entre si por meio da interface X. Os desenvolvedores do sistema A interpretam a interface X de maneira um pouco diferente dos desenvolvedores do sistema B. Comédia.

Uma observação a ser feita é que o desenvolvimento do código e o teste / correção de erros do código não devem ter duas fases distintas. Se você testar enquanto desenvolve, o "custo" da correção de bugs é menor.

Eu adoto um ponto de vista puramente prático: o que está impedindo mais a utilidade prática do projeto? Se houver erros na funcionalidade existente, você deve corrigir os erros. Se faltam recursos, você deve fazer o desenvolvimento original, voltar e corrigir os erros assim que os recursos ausentes mais graves forem implementados. Isso requer familiaridade com seus casos de uso. Um bug que trava o programa em uma caixa de esquina estranha pode ser uma prioridade mais baixa do que pequenas melhorias na usabilidade que afetam a todos. Um pequeno bug incômodo na funcionalidade mais usada pode ser mais importante do que um recurso que beneficia apenas as pessoas que estão levando o software ao extremo.