Bug e sua priorização em equipes Ágeis

Antes de iniciarmos a questionar quais formas e como priorizar devemos entender a diferença entre: Erro, Defeito e Falha.

[box type=”info” align=”aligncenter” class=”” width=””]Segundo o Syllabus CTFL: O ser humano está sujeito a cometer erros, este erro produz um defeito (bug) no código, sistema ou documento, se este defeito for executado irá ocorrer uma falha.[/box]

Devemos diferençar melhorias de bugs, um exercício que pode ser feito neste momento é:

Melhoria é tudo que já existe e funciona, porém quer-se adequar a algum padrão, cor ou estilo, alterar a experiência do usuário ou em aspecto lógico alterando performance e ganhando qualidade.
Bug é tudo que já existe porém não está funcionando como previsto.
(Lembrando que este é um previ resumo, pois este assunto é muito abrangente)

Priorização de Bugs: Como deve priorizar bugs? Com base em qual matriz traço a priorização? Sprint e Bugs? Priorizar bugs durante a sprint? São muitas as perguntas, neste texto a seguir colocarei alguns pontos importantes quanto a minha concepção destas questões

..:: Como devo priorizar Bugs? ::..

O processo natural de priorização dos bugs vem as decorrer que equipes ficam maduras o suficiente para entender a complexidade e impacto ao cliente do problema, alguns guias e boas práticas podem ser inclusas no processo para ajudar na maturidade da equipe. Algumas empresas e autores descrevem uma matriz de priorização como sendo um dos pontapé iniciais para esse processo, esta matriz possua dois aspecto: Frequência e Gravidade.

Nesta matriz utilizei o conceito de Nível de Criticidade onde N1 é o mais crítico e N4 é o menos crítico, mas isto pode ser alterado conforme um pré-padrão que as empresas possuem. O que deve ficar claro é que tudo está em mudança e consequentemente alterações nesta matriz iram ocorrer conforma a maturidade. O time tem toda autonomia para contestar que: Exemplo: Ocorre Sempre e Consegue realizar tarefa é N4 em vez de N3.

Utilizando esta matriz poderemos já tirar um peso dos ombos em relação a como tratar os bugs e priorizar.

..:: Sprints e Bugs::..

Quando a feature está dentro da sprint e ela é fechada e o QA realiza os testes e constata que existe um bug,deve-se abrir um bug na ferramenta de gestão de bugs? A feature deve ser reprovada e o desenvolvedor deve fazer os reparos antes da sprint terminar? Creio que dentro da comunidade esta questão já está dissolvida: Se a feature está dentro da sprint, foi finalizada, QA encontra problema, ela deve ser reprovada e o Desenvolvedor deve realizar os reparos antes de finalizar a sprint, como deve ser previsto na Planning da equipe, toda feature possui obstáculos e o QA é um (kkk), brincadeiras a parte, toda feature possui seu impacto e complexidade assim como probabilidade de ocorrer falhas durante os testes, então bugs relacionados a features dente de sprints devem ser resolvidos dentro da sprint sem necessidade de abertura de bugs na ferramenta de gestão de bugs.

..:: Bugs de Backlog em Sprint ::..

Aqui o bicho pega! Não existe consenso e nem forma correta, o que existe é um certo padrão informal criado pela comunidade onde 20% da sprint fica locada para bugs de backlog.

..:: Bugs durante Sprint ::..

Aplicação morreu, cliente está ligando desesperado… O cliente tem que esperar a próxima Sprint? NÃO! Devemos levar em consideração com base na Matriz de Priorização de bugs mostrada acima que N1 é o nível mais crítico, e que a equipe deve parar qualquer atividade e resolver este problema, claro esta atitude vai de encontro ao que a empresa definiu como crítico.

 

Informações importantes:
A Matriz de priorização inserida acima foi criada com base em uma palestra ministrada por Barbara Cabral e foi realizada adaptações e alterações.