Item investigativo no Backlog

Saudações, leitores!
Quando um erro em produção é reportado para uma equipe ágil, qual providência deve ser tomada para corrigi-lo? Pois bem, o artigo de hoje é relacionado com os incidentes que eventualmente surgem no software, ou melhor, com a recorrência desses incidentes. Saiba como um item investigativo pode ajudar nessas situações!

Introdução

A dica deste artigo é bem básica, mas, por ser tão básica, acaba sendo ignorada pelas equipes ágeis. Como já mencionei em artigos anteriores, todo software está passível de erros, falhas e defeitos (sim, as três palavras têm definições diferentes), e é perfeitamente natural que seja necessário realizar manutenções para solucioná-los. A questão é que muitas das providências definidas pela equipe é um meio paliativo, talvez por conta dos prazos ou devido à complexidade do problema. Por exemplo, sabemos que isso é relativamente comum:

“Esse erro é bastante complicado. Vamos levar um bom tempo para rastreá-lo, mas como estamos com um prazo apertado, melhor colocar uma condição para evitar o erro. Depois volto com mais tempo para analisar…”

Vamos ser realistas: o desenvolvedor não irá voltar com mais tempo para rastrear o erro. Cairá no esquecimento.

A maior consequência desse “descaso” é a recorrência do mesmo erro em funcionalidades diferentes da aplicação. Já que a causa-raiz é semelhante, será necessário adicionar a mesma condição em todos esses pontos distintos da aplicação para que o erro não ocorra. Bom, o fato é que, ao tomar essa providência, a equipe estará varrendo a sujeira para debaixo do tapete.

Essa situação geralmente acontece quando surgem os tradicionais erros de operação com objetos nulos, como o Access Violation do Delphi ou NullPointerException do Java. Para contornar o problema, os desenvolvedores adicionam uma condição para verificar se o objeto está instanciado antes de ser utilizado, caso contrário, a operação é ignorada. Mas, cá entre nós, por que o objeto está nulo? Se isso ocorre, há algo de errado nos métodos anteriores à esse ponto de execução, concordam? De nada adianta adicionar essas condições se há uma probabilidade considerável de este erro ocorrer novamente em outras operações.

Em outras palavras, o ideal é rastrear a causa-raiz, realizar os ajustes necessários e garantir que o objeto seja instanciado independente da situação. Só assim será possível evitar a recorrência.

Item Investigativo

No entanto, se realmente há um prazo apertado e o rastreamento for algo inviável, o que fazer?

Simples! Uma ótima iniciativa é criar um item investigativo para trabalhar na causa-raiz. Este item será adicionado ao Product Backlog e, posteriormente, ao Sprint Backlog da equipe, portanto, terá o mesmo peso e importância de uma user story. A única diferença é que, diferente desta, o item investigativo não representa uma inclusão ou alteração de um requisito funcional levantado pelo cliente. O objetivo deste item se enquadra na dedicação de um tempo exclusivo para o rastreamento da recorrência do erro que, convenhamos, é tão relevante quanto qualquer requisito, já que interfere indiretamente na qualidade do software.

Se refletirmos melhor, veremos que o item investigativo está intimamente relacionado com os requisitos não-funcionais do software. Sabemos que, entre eles, há o aspecto de confiabilidade, que consiste na capacidade da aplicação em executar as operações como esperado, mantendo-se sempre disponível para o usuário. Oras, se a causa-raiz da recorrência de um erro é encontrada e corrigida, o software se torna mais confiável, não é? 🙂

Como um item investigativo se assemelha com uma user story, também recebe critérios de prioridade, estimativas e percorre as mesmas colunas do Kanban Board. A prioridade, mais especificamente, depende do impacto da recorrência do incidente no sistema e do valor que os outros itens do Backlog possuem em comparação com o item investigativo. De qualquer forma, isso pode ser definido entre a equipe e o Product Owner durante a Sprint Planning.

Apenas para título de conhecimento, o item investigativo possui características parecidas com o Gold Card, outro tópico já abordado aqui no blog!

 

Por hoje é só, leitores! Agradeço a visita!
Até a próxima!

---