Severidade x Prioridade na gestão de defeitos em Equipes Ágeis

Para auxiliar o ciclo de desenvolvimento de um software, é necessário a utilização de um sistema para gestão de defeitos, seja ele manual ou não. Normalmente, ao utilizar uma ferramenta específica para a gestão de defeitos, já há opções pré-definidas no momento da priorização das atividades (sejam elas defeitos ou tarefas dentro de Sprint). Entenda a Severidade x Prioridade na gestão de defeitos com Método Agile.

Tempo de leitura: 5 minutos Nesse post você lerá sobre:

• Priorização de tarefas
• Gestão de equipe
• Gestão de defeitos
• Correlação entre prioridade e severidade

Hoje focaremos na priorização de defeitos, assunto muito discutido entre a equipe de desenvolvimento aqui da Exact Sales, que conta com 8 desenvolvedores, 2 analistas de sistema, 2 analistas de testes, 1 arquiteto, 1 suporte, 1 Scrum Master e 1 Product Owner. Antes de mais nada: você sabe o que é Scrum?

Por se tratar de um desenvolvimento ágil, é comum que seja feito verbalmente a priorização do defeito, ao ser encaminhado ao dev (redução do inglês development; desenvolvimento, em português). A problemática de haver essa verbalização da priorização resulta nas seguintes dificuldades:

• Tudo se torna de alta prioridade e alta severidade;
• Interrupção constante de atividades: o dev. começa uma atividade com prioridade e severidade alta solicitada por pessoa X, pessoa Y sem saber da situação, pede pra que ele comece outro defeito com prioridade e severidade alta;
• Muito tempo discutindo qual atividade é mais importante entre pessoa X e Y: normalmente o desenvolvedor continua parado até ser decidido qual tarefa continuar;
• Estresse de ambos os lados.

Avaliando os prejuízos nessas ações, foi constatado que antes de definir como e quem priorizar os defeitos, é necessário organizar quais definições serão necessárias e o que cada uma significa. De acordo com Cristiano Caetano, autor do site DevMedia, prioridade é relacionado diretamente ao negócio ou processo (satisfação ou não do cliente, por exemplo) e severidade é relacionado diretamente ao software (falha ao executar uma ação, por exemplo). Para isso, é importante estar atento à história de usuário:

Aqui na Exact, a equipe tinha maior dificuldade em priorizar os defeitos Críticos (1) e Importantes (2), relacionando-os entre Prioridade (de 1 a 10) e Severidade (de 1 a 4). Porém, aplicando as matrizes a seguir, foi possível ter uma orientação melhor no momento de priorização. A ideia das matrizes surgiu após uma palestra da Barbara Cabral e Matriz de Risco.  

Tabela 1: Matriz para Priorização de Defeitos

Tabela 2: Correlação entre Prioridade e Severidade

Ações para praticar ao cadastrar um defeito: Com as respostas das perguntas feitas, conforme

Práticas ao cadastrar defeito, seguir as matrizes para Priorização de Defeitos e a de Correlação, para saber qual prioridade e severidade colocar no defeito cadastrado.

Também foram acordadas outras boas práticas:

1) Atitude padrão: Quando for acionar o dev. para algum item crítico, sempre consultar no sistema de gestão de defeitos se ele já está na execução de uma tarefa crítica.

• Exceção do item 1: Caso seja percebido que o sistema de gestão não está atualizado ou ficou na dúvida, acionar o dev. Nunca passar o defeito crítico sem saber no que ele está trabalhando ou, ainda, pedir para que seja interrompido o trabalho. Na dúvida, sempre perguntar.

2) Atitude padrão: Ao cadastrar um defeito, manter na fila dos defeitos apenas um item como prioridade 1 e severidade 1, caso tenha apenas um recurso focado nos defeitos.

• Exceção do item 2: Caso realmente tenha mais de um defeito com o combo Prioridade e Severidade 1  → nunca interromper o desenvolvedor que já está no primeiro defeito crítico, (evitando que haja déficit de atenção entre as tarefas). Se o segundo for realmente crítico, vale mais a pena alocar outro desenvolvedor que esteja alocado em Sprint para resolver esse segundo defeito.

3) Atitude padrão: Definir quem é o responsável por cadastro de defeitos. O cadastro de defeitos vindo do cliente será sempre feito pelo suporte ou defeitos em produção. Os defeitos encontrados ainda em fase de desenvolvimento serão sempre feitos pelos testers.

• Exceção do item 3: Analistas de sistemas também podem cadastrar bugs. Porém, sempre conversar informalmente com os testers para saber se já há algo cadastrado sobre o assunto, evitando duplicidades.

4) Atitude padrão: Se o dev. tem dúvida de qual atividade fazer, acionar quem cadastrou o defeito.

• Exceção do item 4: Se a pessoa que cadastrou não esteja disponível, acionar o time para saber qual ação seguir.

Benefícios que esperamos ter: Maior agilidade na ação dos defeitos críticos, maior rapidez nas entregas e, ao ter um padrão de prioridade/severidade, estabelecer métricas quantitativas e qualitativas nos defeitos encontrados, sendo esse um assunto para um próximo texto. Até breve!