Categorizar tarefas / bugs por risco de alterações

O projeto em que estou trabalhando no momento tem um problema: bugs e tarefas são frequentemente atribuídos a pessoas que são novas ou inexperientes demais e seu trabalho acaba produzindo mais bugs no caminho. O problema é que partes do nosso software são muito mais "perigosas" para trabalhar do que outras devido a problemas de qualidade do código. Eu tenho tentado combater esse problema estimando o risco associado às tarefas e prestando muita atenção a quais desenvolvedores recebem quais tarefas.

Como usamos o JIRA, comecei a rotular problemas para acompanhar essa estimativa. Percebi que acabei usando várias métricas para categorizar um bug / tarefa:

• Quão claro / direto é. Por exemplo, se é algo que precisará de muito trabalho de design ou apenas uma simples correção de bug da interface do usuário.
• Quão sustentável é a área afetada do código. É uma área bem projetada ou uma grande bola de lama.
• Quanto do programa eu acho que será afetado pela mudança necessária.

Minhas gravadoras estão meio bagunçadas, porque eu não tinha uma ideia clara quando comecei quais seriam as categorias possíveis e ainda não tenho. Estou pensando em solicitar que um novo campo seja adicionado (algo como "Risco") para que possamos exigir uma estimativa antes de atribuir o trabalho a alguém.

Alguém já lidou com esse tipo de coisa antes?

Uma das falhas da maioria das abordagens de rastreamento de bugs é que elas lidam apenas com um lado da equação - a visão do sistema pelo usuário final. Este é um bug crítico a ser corrigido. Isso pode esperar uma semana (prioridade); esse bug é doloroso, pois é uma sfalha de pluralização (gravidade).

Uma postagem no blog descrevendo o rastreamento multidimensional de erros aborda isso, incluindo a visualização do desenvolvedor: PEF e REV.

Os valores do PEF são a visualização do usuário:

• Por exemplo - qual é a dor do bug quando é encontrado?
• E ffort - o quanto de esforço que é preciso para contornar?
• F requência - quantas vezes é que o bug ocorre?

O lado REV é da visão do desenvolvedor:

• R isk - quão arriscado é a correção?
• E ffort - o quanto de esforço será necessário para correção?
• V erifiability - quão fácil é para verificar se o erro foi corrigido?

Cada um deles é medido em uma escala de 1 a 9, sendo 1 baixo / fácil e 9 alto / rígido. Os números são somados para obter uma pontuação para o PFE e o REV.

A parte que aborda os bits descritos:

• Quão claro / direto é. Por exemplo, se é algo que precisará de muito trabalho de design ou apenas uma simples correção de bug da interface do usuário.
• Quão sustentável é a área afetada do código. É uma área bem projetada ou uma grande bola de lama.
• Quanto do programa eu acho que será afetado pela mudança necessária.

Isso é fator no esforço e risco descritos em REV.

Sim, é algo que já foi discutido antes. Eu (no passado) usei esse modelo para campos personalizados no Redmine e foi razoavelmente bem-sucedido.

A grande vantagem disso ocorre quando você compara as pontuações de PFE e REV. Se você tem um PFE de 21 e um REV de 7, isso é algo que pode ser uma grande vitória. Embora um PFE de 7 e um REV de 21 seja algo que deva ser evitado por algum tempo, porque o lado do risco e do esforço provavelmente supera os benefícios de corrigi-lo.

Pode-se então olhar para a pontuação do REV e atribuir coisas com baixo risco aos desenvolvedores menos experientes (baixo risco, alto esforço são geralmente ideais para essa situação).

Eu diria que o que você está se referindo aqui poderia ser chamado de 'complexidade'. Obviamente, quanto mais complexa é uma mudança, maior o risco 'de que algum novo bug seja introduzido por um programador inexperiente. Não é uma má idéia introduzir esse campo se for um problema real.

No entanto, a julgar pelo que você escreveu, você parece ter dois problemas:

1. Você está lidando com programadores novos ou inexperientes.
2. A qualidade de (muito / alguns) do seu código parece ser questionável.

Além de introduzir algo como um campo de 'complexidade' (que ajudaria a gerenciar e priorizar seu trabalho), sugiro que você se concentre em mitigar o risco dos dois problemas acima.

Para resolver o primeiro problema, eu criaria um processo pelo qual os novos programadores discutem primeiro todos os novos erros com um programador mais experiente antes de trabalhar no bug. Definitivamente, introduzirei revisões de código para reduzir o risco de novos bugs serem introduzidos e para usar como oportunidade de treinamento para que os novos programadores acelerem mais rapidamente.

Com relação à qualidade do código, eu faria duas coisas. Em primeiro lugar, pare o processo de apodrecer: chegue a um acordo sobre padrões e práticas de codificação que impediriam a introdução de qualquer novo código inferior. As revisões de código sugeridas também ajudariam aqui. Em segundo lugar, eu identificaria as piores partes do seu código e começaria a refatorá-las e limpá-las.

Sim, é uma boa idéia não dar aos desenvolvedores inexperientes problemas que são muito complexos. Mas o outro lado é que, se você deixar que eles façam as coisas fáceis, eles não aprenderão.

Sugiro que uma estratégia alternativa seja instituir um regime de revisão de código. Deixe os novatos trabalharem nas coisas complicadas (dentro da razão), mas revise minuciosamente o trabalho deles.

No curto prazo, isso é mais trabalho para todos. A longo prazo, você terminará com uma equipe inteira de desenvolvedores que podem lidar com coisas complexas, E estão "na mesma página" no que diz respeito à qualidade do código.