Análise de bugs do processo de desenvolvimento
Toda aquela ideia de que quanto mais cedo achamos bugs durante o processo de desenvolvimento, menos tempo iremos gastar com correções é uma verdade, porém, para chegar até esse ponto, primeiro precisamos entender nossos bugs atuais e de certa forma porque eles acontecem, para então conseguir implementar planos de ação para agir em cima deles. E quando estamos falando do crescimento/desenvolvimento da área de qualidade em uma startup, isso torna-se ainda mais importante.
Aproximando de nossa realidade, a cada nova feature implementada e disponibilizada para teste, surge uma quantidade grande de bugs durante o período de testes voltados a ela, e para entender melhor as causas raízes desses bugs pensamos em realizar uma análise dos tickets abertos em alguns períodos de desenvolvimento.
Essa ideia surgiu durante uma semana dedicada à resolução de problemas do nosso dia a dia de trabalho aqui na Mercafacil, similar a um hackathon, em que no final tínhamos que entregar um MVP da nossa solução e demonstrar à empresa de que forma a mesma agregaria valor. Além dessa análise de bugs das equipes de desenvolvimento, também desenvolvemos um ROI de feature, que resultou em um artigo à parte.
Em um primeiro momento optamos por analisar os bugs dos últimos meses de 2020, entre setembro e o final de dezembro. Além disso, foi realizada uma análise também nos meses de janeiro e fevereiro de 2020 para verificar se os problemas continuavam os mesmos, já que a equipe passou por alterações durante esse tempo, e verificamos que as causas e até as porcentagens de cada causa continuava bem similar (estes pontos serão melhor discutidos no decorrer do artigo).
Nosso objetivo consistia em verificar se houve evolução na diminuição da quantidade de abertura de bugs, e continuar coletando dados de nosso processo, pois logo de início já tínhamos certeza que esse processo deveria fazer parte dos nossos ciclos de desenvolvimento. Assim, poderíamos sempre levar esses dados para o time e garantir uma melhoria contínua do nosso processo e produto.
ANÁLISE DE BUGS
Utilizamos o JIRA como gerenciador de atividades e para dar início à análise, selecionamos todos os bugs abertos do período escolhido e adicionamos eles a uma planilha do Excel. Nossos bugs atuais são abertos entre 3 categorias (mais melhorias): interface (ocorrências voltadas a layout), funcional (ocorrências não impeditivas o usuário consegue utilizar o sistema) e impeditivo (ocorrências que são impeditivas que impede o uso do sistema). Com o objetivo de deixar mais claro a origem de cada bug, criamos outros critérios durante a análise e vamos explicar como ocorreu esse processo de atribuição.
Após exportar todos os tickets dos períodos escolhidos para o excel, começamos a estudar uma forma de identificar a causa raiz dos bugs. Decidimos começar analisando os abertos em um único período e criar alguns grupos e níveis de detalhamento para eles, de acordo com o que achássemos que ele se encaixasse melhor.
Exemplificando melhor o processo de atribuição aos grupos, como exemplo temos uma falha causada por um problema na definição dos requisitos, que foi designada a um grupo chamado “Definição de requisitos”. Como achamos que não era necessário mais detalhamento para esse grupo, nenhum nível foi criado dentro dele.
Outra falha causada por algum problema de implementação foi para o grupo “Erro de implementação” e mais níveis de detalhamento foram necessários para saber se, por exemplo, foi uma falha oriunda da execução incorreta durante a implementação, ou por um motivo como não contemplar alguma parte da história.
Com o passar do tempo, começamos a perceber que os grupos e os níveis de detalhamento começavam a se repetir, e definimos esses grupos como os principais dentro de nosso estudo. A partir disso, pudemos continuar essa análise de forma mais rápida para os outros períodos estudados.
Cerca de 513 bugs foram categorizados inicialmente, em períodos que juntos somam 6 meses, e você pode olhar aqui um período de 2 meses (outubro-novembro) que estudamos. Os nomes atribuídos a cada categoria foram pensados para simplificar mais o processo durante a análise dos bugs, que era extenso, mas pode ser escolhido arbitrariamente de acordo com a necessidade de cada grupo.
RESULTADOS ALCANÇADOS PT. 1
Dezembro/2020–11/01/2021
Critérios Gerais
Erro de implementação — Níveis de detalhamento
Os gráficos acima são referentes ao período de dezembro de 2021 até o início de janeiro de 2021, último período analisado antes do primeiro ciclo de desenvolvimento com os planos de ação implementados.
Como as causas dos bugs dos outros períodos foram bem semelhantes aos apresentados acima, optamos por mostrar apenas os dados desse período, mas você pode ver aqui os gráficos para os meses de outubro e novembro. A ferramenta utilizada para montar esses gráficos foi o infogram, que pode ser utilizada de forma gratuitamente com um limite, e possui uma grande extensão de tipos de gráficos e tipos de customização para apresentar dados.
No gráfico com os níveis de detalhamentos podemos ver que mais da metade dos bugs abertos durante o período foram relacionados à interface, seja por alguma falha durante o desenvolvimento, ou alguma característica do design que não foi contemplada. O segundo critério com mais bugs foi o nomeado “Funcionamento incorreto” que no nosso mundo ideal deveria ser o que tem mais bugs. Esse critério abrange bugs de usabilidade e falhas de componente ou interações, em que, no geral, suas regras de negócio e interface foram contempladas.
Com esses dados coletados, pudemos passar para etapa onde começamos a pensar na razão da existência de cada critério e em planos de ação para otimizar nosso processo e qualidade do produto.
WORKING AGREEMENTS
A partir dos gráficos pudemos chegar a algumas possíveis causas para as origens dos bugs, mas a melhor ação seria levar esses dados para o time e conversar para entender as principais dores durante o processo de desenvolvimento.
Pensamos em alguns métodos de fazer essa abordagem de uma forma mais descontraída e interativa, e a dinâmica que achamos melhor para isso foi a working agreements, que são alguns guias que definimos juntos como um time para melhorar a forma de trabalhar.
Durante a realização da primeira dinâmica, vimos que poderíamos melhorar a descrição das histórias, fornecendo mais informações para os desenvolvedores. Também concordamos em gastar mais tempo em reuniões definindo features, para esclarecer todas as dúvidas antes do início do desenvolvimento, entre outros tópicos que juntos formaram os nossos working agreements pro Q1. A dinâmica durou em torno de duas horas, e caso tenha interesse em como funciona e como você pode aplicar no seu grupo, aqui nesse link tem mais informações sobre ela.
O próximo passo após realização da dinâmica foi analisar os bugs abertos durante o Q1 com o objetivo de comparar esses valores com os gráficos dos últimos meses de 2020 e verificar os resultados desse primeiro plano de ação.
RESULTADOS ALCANÇADOS PT.2 (Q1)
Com o fim do Q1 (primeiro trimestre), analisamos os bugs abertos no período. Passamos por cerca de 288 tickets, separando em critérios iguais aos utilizados anteriormente, e criamos gráficos novamente para cada período estudado. O último mês analisado foi o mês de março, com cerca de 147 tickets, e as informações obtidas podem ser vistas nos gráficos abaixo. Os gráficos de todos os meses do primeiro trimestre podem ser vistos aqui.
Março 2021
Critérios Gerais
Erro de implementação — Níveis de detalhamento
Podemos notar já que o nosso gráfico ficou com uma cara diferente. A quantidade de bugs de interface diminui em relação aos gerados por regra de negócio ou algum tipo de funcionamento incorreto que não estava previsto na interface ou nas regras de negócio da história. Na realização da segunda working agreements levamos esses resultados para o time, e comentamos nossas conclusões.
Conseguimos perceber algumas relações entre os tipos de bugs abertos e as histórias que estávamos trabalhando no período que analisamos. Foi bem interessante ver como o gráfico se comportava durante os ciclos de desenvolvimento e como as histórias (complexidade, descrição) podem influenciar para a quantidade de bugs abertos.
Por fim, mas não menos importante, todos nossos acordos de trabalho mais recentes, para o Q2, estão nessa URL bem legal que nossa product designer fez.
CONCLUSÃO
Com objetivo de evoluir sempre e com o foco de analisar os problemas pela sua causa raiz, esse processo que construímos irá se repetir a cada final de ciclo (a cada 5 semanas), ações serão planejadas baseadas em toda nossas análises e estas serão alinhadas e definidas com o todo o time envolvido.
Com a realização da análise e a dinâmica, conseguimos identificar alguns pontos de melhoria como, por exemplo, histórias com uma melhor descrição e detalhamento, entender o motivo pelo qual estamos desenvolvendo um requisito, ou seja, compreender as dores do cliente e o porquê do desenvolvimento de cada etapa.
A realização do Working Agrements nos proporcionou unir o time como um todo, pois nunca tínhamos realizado nenhuma reunião para falarmos de temas que poderiam melhorar nas nossas tarefas do dia-a-dia. Quanto mais relacionado ao processo de evolução, consequentemente a equipe como um todo ficará mais madura.
Nosso processo ainda está no começo e está evoluindo, ao passar do tempo pretendemos escrever a continuação desse artigo mostrando pontos importantes e atualizações que foram surgindo e se houve realmente evolução ao longo prazo relacionada a solução dos problemas e ao mesmo tempo evolução da equipe. Foi uma ideia que surgiu em um hackathon e que está agregando bastante valor ao nosso dia-a-dia.
