Por que precisamos de prioridade e gravidade?

Entendo o que eles determinam, mas é realmente útil atribuí-los aos problemas encontrados? Quero dizer, é necessário consertar rapidamente ou não.

Eu sei como configurá-los, categorizá-los etc. Eu sei que o IEEE / ISO exige isso. Eu simplesmente não vejo o porquê.

É absolutamente possível ter esses valores diferentes. Se você tem uma venda para uma agência governamental importante que exige alto desempenho, mas nunca usa o módulo X, faz muito sentido para os negócios corrigir um pequeno erro de disponibilidade do banco de dados mais cedo do que um erro grave no módulo X. Basicamente, razões técnicas não são o único fator quando você administra um negócio de software .

Erros de data e hora

Bug: O processamento de final de ano corrompe totalmente seu banco de dados. Isso é claramente um bug grave.

Data: 15 de dezembro. O bug é uma prioridade muito alta.

Data: 1º de fevereiro. O bug é de baixa prioridade.

Lançamento acidental de bug de míssil

Bug: O software de controle ICBM vomita ao passar de 28 de fevereiro a 1 de março em anos divisíveis por 4. O resultado é um lançamento não solicitado.

É um bug tão grave quanto possível. Porém, a prioridade é muito baixa - existe alguma chance realista de o software ser usado quando a condição for acionada?

Palavras 'ruins' inadvertidas na tela

Bug: As mensagens que excedem seu espaço na tela resultam em uma referência profana inadvertida à exibição de Bob. (Mundo real: tínhamos pessoas trabalhando no departamento "Final Ass". "Ass" = "Assembly".)

Infelizmente, amanhã você estará fazendo uma apresentação em que a venda é uma oportunidade para a empresa. Você está fazendo a apresentação para alguém chamado "Bob". Gravidade: muito baixa. Prioridade: muito alta.

Você escreveu:

Quero dizer, é necessário consertar rapidamente ou não.

Está correto. Se você é como a maioria das empresas, no entanto, seus recursos são limitados. Ou você não tem pessoas suficientes para corrigir todos os problemas ou não tem tempo suficiente.

Dado o fato de que um bug precisa ser corrigido rapidamente ou não, e você tem muitos erros que precisam ser corrigidos, a "prioridade" responde à pergunta "qual devo corrigir primeiro"?

Gravidade, por outro lado, é um indicador usado pela pessoa que define a prioridade. Do ponto de vista de um desenvolvedor, a gravidade é um ponto discutível. Da perspectiva de quem está atribuindo um trabalho, a gravidade é uma informação importante que ajuda no processo de tomada de decisão.

Obviamente, tudo isso é uma informação muito geral. Se você é uma equipe com uma lista de erros impossivelmente longa, prioridade e gravidade significam algo completamente diferente do que se você estivesse em uma equipe que possui um banco de dados de erros quase vazio.

Se você faz parte de uma equipe em que "alta gravidade == alta prioridade" nada disso importa e você não precisa das duas métricas. No final do dia, essas são apenas ferramentas. Sua equipe precisa decidir como usá-los. Para sua equipe, pode não fazer sentido usar as duas coisas.

IMHO, colocar Prioridade e Gravidade é apenas burocracia.

Na prática, você só precisa de uma medida de "importância". Freqüentemente, a prioridade é usada e a gravidade é usada como termo técnico como "alto = sistema de falhas ou o torna inutilizável", "médio = comportamento de buggy, potencialmente prejudicial", "baixo = incômodo, irritante, mas inofensivo"

Geralmente, a prioridade anda de mãos dadas com a gravidade. Alguns exemplos contrários são um "incômodo em que todos sempre reclamam" ou "um acidente ocorrendo uma vez em um ambiente exótico".

... mas, no final, como desenvolvedor (ou gerente, etc), você só precisa saber em que ordem deve corrigir / melhorar as coisas, só isso. Portanto, uma medida é suficiente.

A necessidade de prioridade é clara: é saber em que ordem os relatórios de erros devem ser tratados. O outro, IMHO, como de costume, é a burocracia. Por que você precisa disso? Aparentemente, é inútil para classificação, porque a prioridade faz isso. E as consequências (descrição da gravidade) são descritas no relatório de erros de qualquer maneira.

Eu até acho que é prejudicial porque deixa menos claro qual bug é mais importante:

• Alguns podem pensar que um bug "crítico" tem prioridade mais alta do que um bug de "alta prioridade".
• Alguns usuários que relatam um bug podem confundir gravidade e prioridade
• ... no total, acrescenta confusão sobre a ordem em que os bugs devem ser resolvidos

Além de outras respostas, considere este cenário: o bug A levará 30 minutos para ser corrigido e possui severidade 'baixa'; o erro B pode levar mais de 2 semanas para ser corrigido e ter severidade 'alta'. Além disso, o bug B pode exigir muita discussão e coordenação na equipe de desenvolvimento e talvez fora da equipe; O bug A pode ser corrigido por um único desenvolvedor imediatamente. É perfeitamente bom definir uma prioridade mais alta no bug A.

Obviamente, 'severidade' e 'prioridade' podem ser interpretadas de diferentes maneiras.

Em um pequeno rastreador de erros que fiz para meu próprio uso, preferi 'dificuldade' e 'prioridade', onde problemas de alta gravidade sempre teriam prioridade mais alta, e eu poderia decidir adiar o trabalho neles com base na dificuldade.

Uma coisa que eu não gosto sobre 'severidade' é que ela se aplica apenas a bugs e não a recursos. Pode ser melhor ter uma lista única de todos os problemas ordenados por prioridade e dificuldade, pois é mais diretamente útil decidir 'no que eu trabalho a seguir?'.

Eu projetei e implementei processos em uma empresa de software certificada ISO9001: 2007. Houve atualizações para o padrão desde 2007, portanto, pode haver requisitos adicionais dos quais não estou ciente ... no entanto:

A norma ISO9001 visa garantir que sua empresa projete e implemente processos com ciclos de feedback para melhorar o processo quando os defeitos do produto e do processo são identificados.

Durante a fase de projeto, os requisitos focam se a solução proposta, se implementada corretamente, realmente resolveria o resumo do projeto (validação) e verificar se a implementação foi realmente implementada sem defeito (verificação)

No ciclo de feedback, quando os defeitos são identificados, não basta que sejam registrados. Um defeito também precisa ser avaliado quanto à gravidade, e o retrabalho priorizado.

A parte principal é que a maneira como sua empresa em particular decide avaliar sua gravidade e tomar decisões sobre prioridade não é definida pelo padrão ISO. É uma questão comercial e de governança para a empresa decidir e documentar.

Como está escrito no padrão como requisito, qualquer empresa certificada terá um processo para avaliar a gravidade de um defeito e um processo para determinar a prioridade do trabalho para corrigir o bug. Definitivamente, são duas decisões separadas que precisam ser tomadas.

A gravidade do bug é apenas um ponto de dados. Impacto no cliente É outro ponto de dados. Há também um esforço para corrigir, idade do defeito, vida útil restante no produto e qualquer outro fator que a empresa decida incluir na tomada de decisões. A única coisa que não deve ser escrita como “defeito atual ao gerente de produto para decidir a prioridade”, pois isso apenas define a autoridade para tomar a decisão e não define o processo que eles seguem para tomar a decisão.

Eu tenho uma preferência por priorização tendenciosa para fornecer uma alta taxa de mudanças pequenas e importantes, pois isso parece fornecer o melhor impulso à confiabilidade geral do produto. Isso significa que um bug grave que exigirá muito trabalho para corrigir precisaria que seu trabalho fosse dividido em partes menores para ter prioridade suficiente para ser agendado.

Por razões para diferir fortemente prioridade e gravidade:

Um exemplo simples. Imagine o caso de você ter um local estreito que impeça o dimensionamento do seu sistema - algum algoritmo tem complexidade O (N ^ 3), onde N é a contagem das lojas do cliente. O cliente diz que abrirá 200 novas lojas no próximo ano e os cálculos necessários (distribuição de mercadorias, planejamento de transporte etc.) não serão concluídos a tempo. No entanto, atualmente esse cliente possui apenas 30 lojas e os recursos são suficientes. A tarefa de otimizar esse algoritmo (para O (N ^ 2) ou melhor) é definitivamente importante (você perderá o cliente se não for implementado), mas provavelmente não será urgente: você tem alguns meses para implementar o novo algoritmo.

Exemplo 2: um aplicativo falha sistematicamente, mas esta versão fica fora de uso em alguns dias devido a atualização ou migração. A correção é urgente porque as falhas realmente afetam a experiência do usuário, mas são de baixa importância.

Obviamente, ambos os parâmetros são unificados usando alguma métrica (formal ou informal) para produzir um plano de trabalho de curto prazo, porque o último é unidimensional (sequência de tarefas). Mas, a longo prazo, eles não devem ser unificados.