Estava o Doomsday, time Scrum, constituído pelos integrantes Carlos Coelho, Bruno Ceron, Rafael Polmann, Stephano de Macedo, Glauber Dias Barbara, Davi Waltrick Durieux e eu, em uma retrospectiva (última cerimônia do ciclo Scrum, focada na melhoria continua de processos), mais uma vez foi citado e enumerado as diversas interrupções que tiveram durante o Sprint. Para quem ainda não está familiarizado com o termo, Sprint é o tempo definido dentro do qual um conjunto de atividades deve ser executado.
Como era feito, os problemas eram descritos esperando que alguém trouxesse a solução, porém naquela retrospectiva, o time resolveu ir além. Que ações poderiam tomar para resolverem o problema? Ainda não se sabia, mas nessa retrospectiva, o time Doomsday recebeu a missão de se infiltrar no suporte. Como toda missão em curso sofre desvios e surgem situações inesperadas, nessa não foi diferente.
O objetivo inicial era entender o processo do suporte, identificar a causa e atuar para que o problema fosse resolvido. Ao começar a entender como o suporte trabalha e os processos utilizados, foi descoberto que o time era mais uma vítima do modelo tradicional, existindo uma distância enorme entre suporte e desenvolvimento.
Neste momento começaram ações para aproximar o suporte e desenvolvimento criando laços para unir os setores. Agora sim, os times estavam focados na solução. A reclamação cessou, dando espaço para o suporte e desenvolvimento trabalharem na solução juntos.
Várias ações foram elencadas e algumas já estão em prática. Uma delas trata-se de uma base de conhecimento compartilhada, baseada em perguntas e respostas, denominada Quandora. Ela é alimentada de forma colaborativa por ambos os setores, tornando disponível pesquisas e comentários futuros, com isso a informação não se perde como era feito antigamente, onde dúvidas eram respondidas via e-mail ou telefone.
Outra coisa legal que aconteceu, foi o compartilhamento dos números de chamados e indicadores que o suporte gerava. A partir do momento que o time teve acesso aos números, foi possível identificar quais os módulos que tomam mais tempo em ações corretivas. Investigando as causas, um dos itens apontados foram que os logs da aplicação não eram uteis para o suporte.
Os logs, até então, não eram escritos para o entendimento comum e como parte da entrega do produto. Logo, isso implica que para uma simples analise de um comportamento anômalo, o desenvolvimento seja envolvido. Então por que não melhorar os logs das aplicações? Torná-lo de fácil entendimento? Assim, todo o desenvolvimento se propôs a melhorar os logs nas novas funcionalidades e refatorações.
No dia 19 de janeiro, ocorreu um workshop para discutirmos as melhores práticas e abordagens nas escritas de logs. Estavam presentes os desenvolvedores das verticais de impressão e documentos eletrônicos.
Este workshop foi ministrado pelo desenvolvedor, Rafael Polmann, que abordou em detalhes como configurar e utilizar o framework de logs Log4Net. E em sequência o analista de desenvolvimento Clayton Richard, que já vem utilizando esta ferramenta na solução e-Forms, compartilhou as suas experiências, modos de utilização, desafios, boas práticas e dificuldades encontradas durante o uso do framework. Os palestrantes e os times compartilharam experiências e boas práticas, pretendemos utilizar no nosso dia a dia a partir de agora, e com certeza em breve colheremos os frutos.
Estas ações são apenas o começo de nossa evolução. Os times de suporte e desenvolvimento estão fazendo a mudança acontecer, mexendo diretamente com o nosso Remindset.
