Como afetar as prioridades dos bugs para os desenvolvedores e tratá-las adequadamente?

Temos um processo de bug que está sendo trabalhado no momento.

Temos 3 níveis de bug:

• Erro P1: erros que impedem os usuários de trabalhar. Eles devem ser resolvidos no local.
• Bug P2: erros que estão impactando, mas os usuários podem trabalhar
• Erro P3: erros que não afetam e onde os usuários podem trabalhar.

P1 é obrigatório e deve ser tratado no local. Mas para P2 e P3, julgamos caso a caso.

Com os três níveis que temos, a equipe tem a tendência de trabalhar em novos desenvolvimentos mais prementes solicitados pelos clientes, em vez de lidar com P2 e P3, o que é quase como não urgente.

As perguntas são as seguintes:

Devo adicionar outro nível de prioridade, como ter um P4?

Também devo atribuir a eles metas para lidar com tickets não urgentes, como nesta semana, quando não atribuir uma tarefa de codificação, você deve tratar pelo menos 1 P2?

Atualmente, não temos objetivos como eu levantei acima, mas minha preocupação é que dar a eles esses objetivos possa ser brutal. O que é certo é que preciso conversar com eles sobre os objetivos, a equipe gosta de se envolver na discussão, especialmente quando estamos definindo objetivos.

Atualizar:

Foi-me proposta esta questão em termos de similaridade. No entanto, não é nada parecido.

Minha pergunta é como fazer com que as pessoas lidem com os bugs, sem impor uma agenda estrita e ainda assim resolvê-la. Portanto, não, a pergunta implícita não me ajuda. Ainda assim, obrigada.

Geralmente você tem dois eixos para erros: gravidade e frequência.

Então, obviamente, algo grave e frequente é da mais alta prioridade. No entanto, algo sério, mas que raramente acontece, deve pesar aproximadamente o mesmo que algo que não é sério, mas acontece com frequência. Então, supondo que você classifique a gravidade de 1 a 3 e a frequência de 1 a 3, os tipos de bugs que você provavelmente deve corrigir são aqueles que cruzam a diagonal definida pela gravidade 1, frequência 3 e gravidade 3, frequência 1.

Um erro de bloqueio ou um erro que poderia criar possíveis danos às informações do cliente sempre seria uma gravidade 3. Da mesma forma, um erro com a gravidade 1 provavelmente não será percebido pelo usuário ou tem baixa prioridade. Se você não tem certeza aqui, 2 provavelmente é um número seguro para atribuir.

Um erro que o usuário vê toda vez que o programa é iniciado terá uma frequência de 3. Um erro com a frequência 1 será algo que acontece raramente, se é que ocorre. Novamente, se você não tiver certeza, 2 é provavelmente um número seguro para atribuir.

É principalmente subjetivo sobre o que constitui um erro com gravidade 3 ou um erro com frequência 3, mas use seu bom senso. Um erro com gravidade 1, frequência 2, talvez seja um rótulo com erros ortográficos. Um bug com gravidade 2, frequência 1, pode ser o tratamento adequado de erros quando a conexão com o banco de dados está inoperante.

Novamente, essa é apenas uma ideia aproximada, mas a idéia é enfatizar qual deve ser o foco da correção de bugs como uma espécie de triagem. Claramente, não é possível eliminar todos os bugs, bloqueando ou não, embora pelo menos com essa metodologia, você possa dizer com segurança que os bugs não são muito urgentes ou muito frequentes. Se você apenas bugs que estão bloqueando erros fixo, então os erros de alta frequência será ignorado e os usuários vão perceber que você não corrigir esses erros.

Além disso, por conveniência, você pode preferir fornecer notas por gravidade ou frequência, para dizer que um bug é um erro B3, e fica claro tanto a gravidade quanto a frequência.

Boa sorte!

Isso realmente se resume ao que você considera mais importante. O bug P2 ou o novo recurso?

Geralmente, um sistema ágil de gerenciamento de projetos inclui algum tipo de reunião de priorização, na qual as tarefas são ordenadas por prioridade e trabalhadas nessa ordem.

Os desenvolvedores não têm permissão para escolher as tarefas em que trabalham. Esse é o trabalho do gerente de projetos. Quem deve garantir que o projeto tenha o maior número possível de recursos importantes incluídos antes que o orçamento se esgote.

Essa é realmente a coisa mais importante. Regras simples como "consertar pelo menos 1 P2 por semana" não ajudam realmente esse objetivo.

É um ciclo bastante comum para um software acumular bugs não críticos até que algo dê, então um grande evento acontece e muitos deles são corrigidos ao mesmo tempo; talvez dedicando um ou dois sprints apenas a correções de bugs antes de uma grande nova versão, ou pelo software sendo EOL e tendo sobrevivido aos heap-o-bugs.

Então você está em boa companhia se seus desenvolvedores apenas os deixarem escapar. É claro que você pode brincar com "regras" como você mencionou ("se você não estiver trabalhando em um novo recurso, deverá trabalhar em pelo menos um P2 por semana"), mas isso provavelmente o tornará impopular.

Minha pergunta é como fazer com que as pessoas lidem com os bugs, sem impor uma agenda estrita e ainda assim resolvê-la.

Em vez disso, sugiro alterar um pouco a mentalidade geral e tornar os bugs mais parecidos com os recursos, no sentido de que eles são cidadãos de primeira classe no seu backlog. Sim, novos recursos são ótimos; Sim, o gerenciamento e as vendas se esforçam muito com os novos recursos. Mas ter um aplicativo estável e que funcione bem, em vez de uma pilha enorme de bugs confusos, também é importante.

Não diga aos seus desenvolvedores que eles devem fazer um trabalho que não gostam; mas tente mudar a atmosfera para que eles gostem de trabalhar em bugs. Tente instilar um sentimento de orgulho em um aplicativo sem erros. Torne mais divertido (sic) trabalhar em um bug, permitindo especificamente que eles consertem realmente o motivo subjacente que tornou esse bug manifesto (ou seja, não apenas soluções rápidas / hacks), se houver algum. Rasgar alguma estrutura de classe quebrada e substituí-la por algo mais adequado pode ser muito divertido para os desenvolvedores. Se você tiver uma peça central quebrada que regularmente faz com que os bugs se manifestem em outros lugares, conserte a peça central.

Como você alcança seu objetivo é altamente dependente de seu próprio personagem e do de suas equipes - não tente enganá-los sobre o que deseja alcançar, mas tenha discussões abertas, tente obter um efeito de colegas em execução, permita que eles apresentem um processo de trabalho, e assim por diante.