Quase todo bug reportado é um bug de alta prioridade [fechado]

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.

Se você tem esse problema onde os usuários estão atribuindo bugs de prioridade cada vez maior, a única solução realista é um mecanismo de triagem. Todos os bugs são reportados com qualquer prioridade que eles gostem, mas algum gerente ruim terá que passar por cada bug recém-informado e redefinir sua prioridade para um nível razoável.

Depois de um tempo, os usuários receberão a mensagem ou você poderá alterar o sistema de relatórios para que cada bug tenha uma prioridade padrão. Se eles quiserem escalar, terão que contatar alguém para bater, o que exigirá alguma justificativa. Este fato por si só fará com que 99% de todos os bugs sejam deixados sem escalação pelo usuário.

Obviamente, você tem mais bugs do que você pode processar, então talvez você precise embarcar em um roundup de correção de bugs para limpar o backlog. Isso mostrará aos usuários que seus bugs serão corrigidos sem precisar que sejam marcados como super-super-dooper-realmente-não-honestos-desta vez-importante-

ISENÇÃO DE RESPONSABILIDADE: Eu ainda não tive experiência com shenanigans de prioridade de bug relatados pelo usuário. Eu sei que a pergunta pede por isso, mas pode ajudar ter a perspectiva de alguém de fora.

Seu problema não é que você tenha muitos erros de alta prioridade. Seu problema é que você tem muitas pessoas que têm controle direto sobre a prioridade do bug. Se todos os usuários puderem atribuir diretamente uma prioridade ao bug, eles quase automaticamente informarão seu problema como alta prioridade.

Você pode fazer com que a prioridade do bug seja configurada por um gerente ou um drone de helpdesk, mas isso pode levar a favoritismo e engenharia social, onde um cliente recebe artificialmente maior prioridade por causa de seu status ou porque sabe suas mensagens para torná-las mais importantes. Também é muito mais trabalhoso.

Existe um meio-termo, onde seus usuários têm algum controle sobre a prioridade, mas de uma maneira que dificulta a exploração do sistema. Essencialmente, você força seus usuários a usar um modelo para relatar bugs. Eles primeiro selecionam uma categoria:

1. O programa fica inutilizável ou trava quando eu faço alguma coisa.
2. O programa tem um defeito gráfico que afeta a funcionalidade.
3. O programa não me permite fazer algo que eu possa fazer.
   O programa me permite fazer algo que eu não deveria ser capaz de fazer.
4. O programa dá o resultado errado quando eu faço alguma coisa.
5. O programa demora muito para fazer algo.
6. O programa tem um defeito gráfico que não afeta a funcionalidade.
7. O programa tem um defeito que não se encaixa em uma das categorias acima.

Para dar exemplos:

1. Meu iPhone falha quando recebo uma mensagem contendo símbolos em hebraico.
2. Minha tela de bloqueio do Android é girada de modo que metade dela caia na tela.
3. Por vezes, o meu telemóvel Android não aceita o código do bloqueio de ecrã, apesar de ter introduzido o código correcto.
4. Quando tento navegar para o PhoneHub.net, meu telefone me redireciona para um site adulto.
5. Quando abro o aplicativo do Facebook, demora um minuto para abrir, mesmo em conexões rápidas e sem outros aplicativos em execução.
6. Seu aplicativo tem um erro de ortografia.
7. Encontrei um defeito de segurança no seu programa e gostaria de denunciá-lo.

Como você pode ver, cada um desses erros tem um grau de severidade diferente, e as categorias são mais ou menos ordenadas com base nessa gravidade. Você pode então atribuir a cada bug uma prioridade com base na categoria, quem a reporta e palavras-chave que aparecem na descrição. Bugs na categoria 7 devem ter sua prioridade atribuída manualmente.

Note que isso pode acontecer de forma totalmente automática, e você deve deixar isso acontecer automaticamente; na verdade, a automação é a chave aqui. Os usuários tendem a superestimar sua própria importância para os negócios, de modo que não vêem um problema em relatar seus bugs como uma prioridade maior do que deveriam. eles estão menos inclinados a colocar deliberadamente o bug em uma categoria diferente, porque isso exige que eles mentam basicamente sobre o bug.

Os usuários ainda podem inserir seus bugs na categoria errada, é claro. A primeira coisa que você deve fazer é, a partir da versão 1.0, mostrar uma mensagem amigável incentivando os usuários a fornecer informações precisas sobre o bug para ajudar os desenvolvedores a encontrar e corrigi-lo mais rapidamente. A maioria dos usuários entenderá e impedirá a comunicação incorreta de erros. Alguns usuários ainda podem continuar fornecendo informações erradas. Quando isso acontecer, envie a esses usuários um lembrete gentil por e-mail de que informações precisas são importantes e que não agrade o abuso do sistema. Se eles continuarem a falsificar registros, você avisará que eles estão abusando do sistema intencionalmente e o abuso contínuo resultará na atribuição automática de uma categoria inferior aos bugs. Se eles persistirem, você pode ajustar o multiplicador de bug deles.

Você pode ver partes deste sistema implementadas em situações de suporte de alta produtividade: empresas de tecnologia gigantes como Microsoft, Facebook, Google, empresas de jogos com muitos usuários como Valve e Blizzard, certos governos, ... Enquanto eu Não tenho certeza do funcionamento por trás do cenário, você percebe que o sistema de suporte voltado para o usuário tem uma interface semelhante àquela que eu sugiro aqui, com um sistema de categoria estrito.

Como as pessoas disseram, é por isso que as pessoas que relatam bugs não atribuem prioridade. Sua equipe de desenvolvimento deve estar no controle de sua própria atribuição de tarefa (dentro do escopo definido pelo gerenciamento superior). Então, alguém mais acima diz "trabalhe em este aplicativo, corrija este recurso, faça melhor em isso ", e a equipe chega decidir como proceder, porque são os que possuem o conhecimento técnico necessário para avaliar a melhor forma de alcançar o que a gerência deseja.

As pessoas que relatam os bugs devem atribuir níveis impacto ou gravidade , que têm escopo definido. Você pode facilmente chamar as pessoas por não se ater aos níveis acordados de severidade, porque você tem evidências materiais para esses níveis. Por exemplo:

1. Perda completa de funcionalidade
2. Perda parcial de funcionalidade
3. Redução generalizada da eficácia
4. Redução localizada na eficácia
5. Aborrecimento ou impedimento (existe solução)
6. Cosmético
7. Ninguém realmente notou, foi encontrado durante obscuro teste exploratório

Para começar, você pode usar esses níveis como um instrumento contundente para apontar que um desalinhamento de algum texto de título não é um bug do Nível 1 porque não está tornando o aplicativo inteiro inutilizável. Uma vez que eles tenham a ideia, você pode torná-la mais refinada e começar a debater se a falha na atualização desta caixa de texto é um Nível 5, pois você pode corrigi-la clicando com o botão direito do mouse na caixa de texto algumas vezes. porque está diminuindo a velocidade de todos na Contabilidade, de modo que eles recebem menos formulários processados por hora.

Uma vez que você tenha informações úteis, mensuráveis sobre quão ruim o bug é para sua organização , a atribuição de prioridade se torna óbvia. O que quer que esteja causando o maior problema para a organização - perda de lucros, danos à imagem pública, infelicidade do empregado, seja o que for - será a alta prioridade, e você trabalha a partir daí.

É mais ou menos assim:

Mgr: no que você está trabalhando? Dev: tarefas de baixa prioridade Mgr: você não deveria estar trabalhando em tarefas de alta prioridade?

Cliente: quando meu bug será corrigido? Dev: é baixa prioridade, temos tarefas de alta prioridade. Cliente: ah, bem, então configure meu status de bug para alta prioridade.

Isso levará a níveis cada vez maiores de prioridade. Vejo que você já passou da alta prioridade para a prioridade muito alta. Quais serão as próximas etapas:

1. Super alta prioridade
2. Ultra Alta Prioridade
3. Muito Super Ultra Alta Prioridade.
4. Muito alta prioridade super ultra mega.

etc.

Sim, este é um processo normal. Desde que não haja nenhum custo envolvido na atribuição de prioridade, e o chamador tenha influência, é claro que tentarão resolver seu problema da maneira mais rápida e definir a prioridade mais alta.

Existem basicamente duas maneiras de combater isso:

1. Tire o controle do cliente em relação aos níveis de prioridade.
2. Associe um custo ao cliente para níveis de prioridade elevados.

Pode-se adicionar níveis de prioridade mais altos e mais altos ao sistema, especialmente se for Jira. Dar as novas prioridades altas cada vez mais tolas, mas nomes medonhos podem aumentar a colisão de efeito Hawthorne na qualidade das escolhas prioritárias feitas por todas as partes . Se a prioridade mais alta tiver um nome realmente estranho, o efeito poderá ser permanente. Eventualmente, quando alguém escolhe uma prioridade, eles têm que pesar as consequências sociais de escolher a prioridade do "bug da morte" versus obter a devida atenção. Assim, a maior prioridade é de fato reservada para algo que aconteceu com o CTO em casa na frente de seus convidados, ou outros incidentes de visibilidade equivalente.

Introduza um custo para suportar pedidos. Você só pode permitir que um usuário denuncie um número X de itens de alta prioridade em um determinado período de tempo, um número Y de itens de prioridade média e uma prioridade baixa de Z.

Naturalmente, isso também significa que a equipe de desenvolvedores e a gerência precisarão garantir que um certo número deles será realmente consertado - todos os itens de alta prioridade, a maioria dos itens de prioridade média e (talvez) alguns dos itens de baixa prioridade dentro de um determinado período de tempo.

Mas se isso vai funcionar, a gerência vai ter que comprar, caso contrário, todo o exercício é uma perda de tempo.

Algo como isso foi implementado na primeira empresa em que trabalhei, pois o processo de suporte era disfuncional e levava a uma situação em que, se tudo é uma emergência, nada é. No nosso caso, depois de controlar a situação interna, o novo gerente de desenvolvimento de software colocou um limite rígido no número de questões de alta prioridade que um cliente poderia depositar, dependendo de quanto pagavam em contratos de suporte. Se eles superassem o limite, ou eles cuspiam mais dinheiro ou a questão de suporte era reduzida em prioridade.

Isso acontece com muita frequência em grandes corporações, onde a TI é vista como auxiliar e / ou terceirizada. As pessoas de negócios não entendem de software e não se importam, tudo o que eles se importam é que o "seu" bug é corrigido ontem, independentemente de quão crítico ele seja. Eles não percebem, ou se importam, que há centenas de outros usuários também preenchendo bugs, e uma equipe de talvez 5 desenvolvedores disponíveis para consertar as coisas.

Isso é exacerbado pelo mau gerenciamento, especialmente pelos gerentes que não são de TI, que não podem dizer "não" ou que simplesmente permitem que as pessoas de negócios definam a prioridade do bug. (Em ambos os casos, o gerente não está fazendo o seu trabalho.) A maioria dos gerentes prioriza o bug do último contato porque "é urgente"; O resultado final é que os desenvolvedores acabam pulando de bug para bug, consertando assim que um único bug leva mais tempo (troca de contexto), e no final do dia todo mundo está infeliz. "Quando cada bug é um bug de alta prioridade, nenhum bug é de alta prioridade."

Eu tenho estado nesta situação e, geralmente, a única maneira de escapar é sair. As diretrizes de relatório de bugs são sempre ignoradas porque os usuários não fornecem um s ** t. A tentativa de introduzir a triagem de bugs terá resistência ou será implementada e, em seguida, ignorada na próxima vez que um usuário ligar para seu gerente para reclamar do erro "seu".

Basicamente, se os desenvolvedores não tiverem controle da prioridade , você já perdeu.

Como empresa, você quer resolver os problemas com a maior relação importância / custo. Os usuários decidem a importância, a engenharia decide o custo. Se os usuários atribuírem a mesma importância a todos os erros, o custo por si só é importante.

Na prática, isso significa que você define prioridade como importância / custo e não permite que usuários ou desenvolvedores definam essa prioridade diretamente. Nenhum lado tem a imagem completa.

Se os usuários decidirem classificar todos os problemas igualmente importantes, tudo bem, mas isso significa que a engenharia (custo) decide o que é feito. Explique-lhes que a importância é a única maneira pela qual eles podem influenciar (mas não decidir) a prioridade.

Alguns fatores ...

• Frequentemente, a pessoa relata que o bug não conhece a imagem maior e não consegue decidir a importância do bug.
• Freqüentemente, bugs de baixa prioridade nunca são triados ou considerados, por isso é melhor dar uma prioridade que seja muito alta e deixar a pessoa fazendo a triagem abaixá-la.
• Como desenvolvedor, muitas vezes analisei o relatório de erros e descobri que há um problema de alta prioridade por trás do bug, mas o gerente de produto que faz a triagem não se importa com o bug.

Então, eu acho que todos os relatórios de bugs precisam ser analisados rapidamente por um ou dois desenvolvedores experientes, adicionando seus pensamentos ao relatório do bug, então o bug precisa ser triado. Esperar que a pessoa que encontra o bug seja capaz de definir uma prioridade útil no momento em que a encontra, está apenas pedindo demais.

É bem possível que todos os erros mencionados tenham alta prioridade. Eu estive em projetos que foram subfinanciados e subespecificados, e quando o teste começou QA e os usuários desistiram de relatar itens de baixa prioridade, porque eles sabiam que os erros de ortografia ou falhas na usabilidade eram um desperdício de tempo se a funcionalidade principal do projeto foi completamente lavado. Se o seu sistema automatizado de bagagens estiver travando carrinhos e destruindo a bagagem , quem se importa se a fonte das tags for 2pt muito pequena ?

Em uma situação como essa, o projeto está falhando. Se você suspeitar que isso é mesmo uma possibilidade, você precisa de um coração para coração com as pessoas relatando defeitos para descobrir. Se as pessoas estiverem inflando relatórios de bugs, as outras respostas ajudarão. Se os erros são tão ruins quanto o reportado, então você precisa tomar medidas extremas .

A maioria já foi dita, mas eu destilei a lista do "zoológico de insetos" para algo menos granular:

R: O bug interrompe o usuário em suas trilhas, gera resultados errados, geralmente torna o sistema / recurso / função inutilizável. Esse é um bug de "alta prioridade".

B: Todo o resto. Estes são bugs "negociáveis".

Os erros NEGOTIABLE caem sob uma variedade de preocupações (que você colocaria em seu próprio pedido):

1: erros que afetam a segurança;

2: Erros que afetam a usabilidade (adequação ao objetivo pretendido);

3: Erros que impactam a estética;

4: Erros que afetam o desempenho (talvez um subconjunto de usabilidade?);

5: Insetos que ofendem sua sensibilidade como programador profissional;

6: Erros que diminuem a CONFIANÇA DO USUÁRIO;

Então esse é o mundo utópico em que nenhum de nós realmente vive. suspiro Para completar minha resposta à pergunta do OP, em toda a indústria de software, é absolutamente comum que os esforços de desenvolvimento estejam em andamento. um status onde cada bug é prioridade-um-super-banger-especial. E você sabe o que eles dizem sobre "especial": quando todos são especiais, ninguém é especial.

DO CURSO, todo usuário quer que o problema seja corrigido primeiro. E assim que você permitir isso, o caos. Você não tem uma prioridade válida. Você precisa que isso seja feito por uma ÚNICA pessoa com autoridade (consultando outros quando necessário), que tenha VISIBILIDADE em TODAS as questões e necessidades de negócios e competente o suficiente para coletar as recomendações necessárias de negócios e de TI e gerar estimativas razoavelmente precisas das métricas acima.

Correndo o risco de afirmar o óbvio, vou assumir que não há software de rastreamento de bugs que esteja definindo bugs como prioridade alta (ou que tenha sido definido para essa configuração).

Eu tenho medo, que na ausência de controles, esse é o cenário padrão para várias equipes, clientes, etc. relatando. Se o status quo está sendo abusado, algum tipo de processo de triagem está definitivamente em ordem.

Uma vitória rápida que eu já vi funciona muito bem no passado é que o P1 (bugs de prioridade máxima) gera uma infinidade de alertas de gerenciamento. Se o sistema tiver sido abusado, ele será imediatamente ignorado. Ou, se for genuinamente urgente, uma teleconferência ou reunião física resolverá o problema o quanto antes.

Estou assumindo aqui que você está falando sobre todos erros não apenas aqueles do desenvolvimento inicial. Se você é tipicamente uma arma de desenvolvimento de campo verde para contratar, então certamente não é incomum que a maioria dos bugs tenha alta prioridade após o lançamento alfa inicial.

Você não pode simplesmente ter uma prioridade e esperar que tudo funcione magicamente. Às vezes as pessoas descobrem por conta própria, mas nem sempre.

Para atribuir corretamente prioridades, deve haver uma definição de exatamente o que constitui cada prioridade. Esses critérios devem ser objetivos, para evitar o favoritismo de erros e a priorização política. Se os critérios objetivos não forem seguidos, você precisa fazer a equipe segui-lo.

Não há realmente nenhuma maneira de contornar isso - se você não puder ter critérios objetivos para o bug que vai para onde e se as pessoas voluntariamente se recusarem a honrar esses critérios, talvez você não tenha prioridades atribuídas pelo apresentador - faça sem prioridades ou ter um terceiro atribuído prioridade como outros sugeriram. Os dados de crowdsourced só funcionam se os solicitantes são cooperativos e não sabotam ativamente a coleta de dados.

Se a dificuldade surgir por não conseguir criar critérios objetivos, você pode usar critérios relativos:

• Tenha uma fila simples de todos os bugs. Os usuários podem inserir erros em qualquer lugar da fila. Eles só devem inserir em uma determinada posição se sentirem que seu bug é mais importante do que tudo abaixo dele. Os fixadores de erros começam no topo da fila.
• Supondo que você já tenha um conjunto de bugs bem classificados, diga a todos que a condição para colocar um bug na prioridade X é que ele deve ser mais importante que todos os bugs na prioridade X-1 .
• Informe aos remetentes que em nenhum momento o número de bugs com prioridade X pode exceder o número de bugs com prioridade X-1 .

Mas parece que o seu problema não é a definição, mas a crença entre os solicitantes de que bugs de baixa prioridade não são consertados. Presumivelmente, você não pode persuadi-los de outra forma, já que (pelo que você diz) a crença deles é baseada em fatos. Então, por que você os faz enviar esses bugs? Isso acaba sendo nada além de trabalho pesado. Você poderia, por exemplo, depois que um determinado número de bugs ativos fosse alcançado, dizer a todos para não se incomodarem em fazer relatórios, a menos que achem que encontraram algo mais importante do que mais bugs pendentes. Concedido, esta é apenas a solução de fila com um limite superior no comprimento da fila.