I asked some colleagues about what this may be happening, and they mentioned that if a bug doesn't haven't that level of priority it is very rare that the Bug gets developer attention, which indeed makes sense
Na verdade, se você me perguntar, não. Quanto mais níveis (usados) de prioridade, mais informações você tem. Se você efetivamente tem apenas uma prioridade, é a mesma coisa que não ter prioridade alguma.
E como você ainda tem o mesmo número de bugs para enfrentar, e a mesma quantidade de horas de trabalho para fazê-lo, segue-se que alguma outra heurística será usada, possivelmente a nula - "primeiro a chegar, primeiro a ser servido" . E agora você tem uma métrica de prioridade de bug, exceto que é a hora da chegada e não está mais sob seu controle.
Pode ser um sintoma de não haver recursos suficientes alocados para a correção de bugs (há algumas políticas como " Sem novos recursos até os bugs são corrigidos "que podem ajudar lá. Joel aprova ; o entendimento dos limites e conseqüências é um < href="https://softwareengineering.stackexchange.com/questions/198696/keeping-agile-with-zero-bug-defect-policy"> decisão comercial ).
Em um projeto que eu trabalhei, os bugs recebidos foram acumulados em um "buffer sem prioridade" e toda segunda-feira nós revisávamos a lista de erros, estimamos a dificuldade (uma estimativa muito aproximada; ") e classificá-los pelo tempo disponível. Isso tende a derrubar a lista de bugs chatos, desinteressantes ou pensativos; Para compensar isso, os supervisores e o marketing tinham um certo número de créditos por semana que poderiam gastar para aumentar a prioridade dos bugs favoritos, e eram reembolsados por bugs não resolvidos (isso limitava o quanto um bug desprezado pelo desenvolvedor poderia ser atrasado) .
Também foi possível mesclar, cancelar e dividir bugs; Lembro-me de um módulo que era tão irremediavelmente falho que afundamos cerca de vinte ou trinta relatos de bugs em um único "reescrever essa coisa do zero", que foi então dividida em "indicar claramente as entradas e saídas da coisa miserável", "escrever testes para garantir que entradas e saídas correspondam à especificação ", e assim por diante. O último item foi "imprimir o código antigo em papel reciclado, trazê-lo para fora no gramado e atear fogo" (fizemos isso também. Lembro-me de como foi bom. Revimos o elogio; era hilário. ).
Depois de algumas discussões, tivemos a lista de tarefas da semana, que foi dividida em "vai fazer", "pode fazer" e "não pode", que foram batidas na próxima semana. Este é o lugar onde alguns pechinchas adicionais vieram dentro: nós dissemos cinquenta horas para alocar nos bugs, e estávamos com 95% de certeza de consertar os primeiros vinte. A gerência queria strongmente que um bug do século XXI fosse corrigido e não restasse nenhum crédito; Então, ofereceríamos trocar esse bug por um na lista "Vontade", ou alguém diria "Subtraí-me a subequipe FooBazFeature por alguns dias e eu o farei" ou diríamos "Precisamos de mais mão de obra ".
O sistema não satisfazia ninguém, realmente, mas acreditava-se (pelo menos entre os desenvolvedores) um bom sinal.
Alguns padrões negativos adicionais que apareceram foram o "Wishful Thinking" na parte dos gerentes ("Você afirmou que o bug 57212 requer oito horas. Isso é inaceitável. Faça quatro") e o "Debug by Fiat" ("Do o que você quiser, mas esses quarenta bugs devem ser corrigidos antes da grande demo na próxima semana. Você não pode ter mais tempo, você não pode ter mais pessoas "). Também a Síndrome de Boxer ("vou trabalhar mais"), que tendeu a funcionar muito bem por um curto período de tempo , mas geralmente levou a um desenvolvedor pirando ou saindo para pastos mais verdes.