Item investigativo no Backlog

Item investigativo no BacklogSaudaçõ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!

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:

“Nossa, esse erro é bastante complicado! Vamos levar um bom tempo para rastreá-lo, mas como estamos com um prazo apertado, vou colocar uma condição aqui para evitar o erro. Depois volto com mais tempo.”

Vamos ser realistas: o desenvolvedor não irá voltar com mais tempo para rastrear o erro. Isso simplesmente cairá no esquecimento.
A maior consequência desse “descaso” é a recorrência do mesmo erro em locais 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.

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!


Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Ótima dica, André!
    Primeiramente, gostaria de parabenizá-lo pelo blog!
    Sobre o artigo, como você salientou, o item investigativo por ser tão básico, acaba sendo esquecido.
    Valeu por relembrar e incentivar essa dica!
    😉

    1. Olá, Beatriz, ou melhor: olá, minha namorada! 🙂
      Bia, obrigado pelo comentário e pela motivação que você sempre me proporcionou para continuar escrevendo os artigos!
      Espero sempre contar com as suas visitas!
      Um grande beijo! Te amo!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.