Como afetar as prioridades aos bugs aos desenvolvedores e tratá-los de acordo?

14

Temos um processo de bug atualmente em andamento.

Temos 3 níveis de erros:

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

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

Com os 3 níveis que temos, a equipe tem a tendência de trabalhar em novos desenvolvimentos mais urgentes, 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 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 os que mencionei acima, mas minha preocupação é que dar a eles esses objetivos pode ser brutal. O que é certo é que preciso conversar com eles sobre os objetivos, a equipe gosta de se envolver em discussões, especialmente quando estamos definindo objetivos.

Atualização:

Eu propus esta pergunta em termos de similaridade. No entanto, não é semelhante, em tudo.

Minha pergunta é como fazer com que as pessoas lidem com bugs, sem impor uma agenda rígida e, ainda assim, resolvê-la. Então, não, a questão implícita não me ajuda. Ainda assim, obrigado.

    
por Andy K 03.12.2018 / 10:38
fonte

3 respostas

31

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

Então, obviamente, algo grave e freqüente é da mais alta prioridade. No entanto, algo que é sério, mas que acontece raramente, deve ser pesado da mesma forma que algo que não é sério, mas acontece com frequência. Assim, supondo que você classifique a gravidade de 1 a 3 e a frequência de 1 a 3, os tipos de bichos que provavelmente devem ser consertados 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 dano potencial à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 terá 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 raramente acontece, se ocorrer. Novamente, se você não tiver certeza, 2 é provavelmente um número seguro a ser atribuído.

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

Mais uma vez, esta é apenas uma idéia aproximada, mas a idéia é dar ênfase ao que deveria ser o foco da correção de bugs como uma espécie de triagem. É claro que não é possível eliminar todos os bugs, bloqueios ou outros, embora pelo menos com esta metodologia, você possa dizer com segurança que os bugs não são muito urgentes ou muito frequentes. Se você corrigiu apenas erros que estão bloqueando erros, então os erros de alta frequência serão ignorados e os usuários irão perceber que você não corrigiu esses erros.

Além disso, por conveniência, você pode achar que prefere fornecer notas de letra por gravidade ou frequência, portanto, pode-se dizer que um erro é B3 e está claro a gravidade e a frequência.

Boa sorte!

    
por 03.12.2018 / 14:12
fonte
24

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

Normalmente, um sistema ágil de gerenciamento de projetos incluirá algum tipo de reunião de priorização em que as tarefas são ordenadas por prioridade e trabalhadas nessa ordem.

Os desenvolvedores não podem escolher as tarefas em que trabalham. Esse é o trabalho do gerente de projeto. Quem deve garantir que o projeto tenha o maior número possível de recursos importantes incluídos antes que o orçamento acabe.

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

    
por 03.12.2018 / 11:54
fonte
1

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

Então você está em boa companhia se seus desenvolvedores simplesmente deixarem eles deslizarem. É claro que você pode lidar com "regras" como você mencionou ("se você não está trabalhando em um novo recurso, você deve trabalhar em pelo menos um P2 por semana"), mas isso provavelmente fará com que você seja impopular. p>

My question is how to have people deal with bugs, without imposing a strict agenda and yet to have it resolved.

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

Não diga aos seus desenvolvedores que eles devem fazer trabalhos que não gostam; mas tente mudar a atmosfera para que eles gostem de trabalhar com bugs. Tente incutir um sentimento de orgulho em um aplicativo sem bugs. Tornar mais divertido (sic) trabalhar em um bug, permitindo especificamente que eles realmente corrijam o motivo subjacente que fez aquele bug se manifestar (ou seja, não apenas soluções rápidas / hacks), se houver algum. Arrancar algumas estruturas de classes quebradas e substituí-las por algo mais adequado pode ser muito divertido para os desenvolvedores. Se você tem alguma peça central quebrada que regularmente faz com que os bugs se manifestem em outro lugar, conserte a peça central.

Como você atinge seu objetivo é altamente dependente de seu próprio personagem e de suas equipes - não tente enganá-los com o que você quer alcançar, mas tenha discussões abertas, tente obter um efeito semelhante. apresentar um processo de trabalho, e assim por diante.

    
por 04.12.2018 / 10:31
fonte