ti-enxame.com

Quanto tempo deve ser gasto em bugs versus desenvolvimento original?

Essa 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 esperava uma quebra típica ou média.

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.

26
Mike B

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 novo livro de David Anderson, "Kanban" . (O livro aborda um assunto diferente, mas também trata de questões de qualidade.) Ao discutir a qualidade do software, Anderson cita este livro, por 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 até 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, o que implica que é comum as equipes gastarem mais de 90% de seu esforço na correção de defeitos. "Ele cita um exemplo, 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 de falha é o termo para isso) sugere que a equivalência das duas coisas é bem conhecida da qualidade do software pesquisadores e provavelmente já é conhecido 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 decretamos 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 teste 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.

16
azheglov

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.

8
Mike Clark

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.

8
Victor Hurdugaci

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.

3
Walter

É 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, é possível 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".

3
Khelben

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.

2
JeffO

Software não crítico, uma 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.

1
mouviciel

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 através 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.

1
darreljnz

Eu acho que essa 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 ele 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 erro está relacionado exponencialmente ao tempo decorrido desde o momento em que você inseriu o erro 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 ...)

1
Jérôme Radix

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 que 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 do desconhecimento do desenvolvedor dos casos do Edge.

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.

1
Dan Monego

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 algum canto estranho 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.

0
dsimcha