Como melhorar o processo de qualidade através de um modelo de maturidade?

Photo by John Schnobrich on Unsplash

Produzir software de alta qualidade não é algo facilmente alcançável exige muito esforço e planejamento para obter o resultado esperado, ainda mais quando não há um processo bem estruturado. Uma estratégia robusta é essencial para garantir que novos recursos sejam lançados sem bugs ou problemas não esperados.

Afinal, como podemos medir, acompanhar e melhorar o processo de qualidade dentro do time ou até mesmo da empresa?

Essa pergunta é bastante complexa de ser respondida pois engloba vários fatores e visões que variam de contexto para contexto. Aqui no eCred, tínhamos dificuldades em saber o real estado que se encontrava a maioria de nossos serviços, por isso, criamos um modelo de maturidade para coletar os dados, analisar e definir uma estratégia de melhoria para as nossas aplicações.

O que é um modelo de maturidade?

Segundo Martin Fowler: “Um modelo de maturidade é uma ferramenta que ajuda as pessoas a avaliar a eficácia atual de uma pessoa ou grupo e ajuda a descobrir quais capacidades elas precisam adquirir em seguida para melhorar seu desempenho.”

Photo by Jeremy Thomas on Unsplash

Dentro do contexto de qualidade, o objetivo de usar o modelo é identificar a maturidade e fornecer metas e ações para melhorar o processo alcançando o progresso.

Nosso modelo foi inspirado no TMMi (Test Maturity Model and Integration) que está posicionado como um modelo complementar ao CMMI (Capability Maturity Model Integration), ele é estruturado com uma série de níveis de eficácia. Nós decidimos adotar a mesma estrutura e ideia original, porém, para um melhor entendimento de todos, usamos uma nomenclatura mais clara e simples. Além disso, é importante frisar, que o modelo foi construído junto com o time, onde conseguimos captar opiniões e feedbacks de todos.

O modelo

O nosso modelo é indicativo e vivo, estamos sempre experimentando e evoluindo os critérios de acordo com a utilização no dia a dia, a imagem abaixo mostra um exemplo da primeira versão que criamos.

Níveis

O modelo tem 5 níveis: Inicial, Básico, Regular, Bom e Ótimo.

Critérios gerais

Realização de code review é um ponto legal de se colocar, no nosso caso, já temos essa prática, então colocamos como um critério geral só para continuar com a realização.

Outro ponto importante sobre os critérios é que não estamos avaliando a qualidade dos testes existentes, e sim, se existem esses itens dentro do processo de desenvolvimento.

Avaliação e Ações

Somos rígidos em relação aos critérios, no primeiro momento todos os nossos serviços começaram no nível Inicial, porque tínhamos que coletar informações e ter visibilidade de como eles estavam.

A mudança de nível só ocorre quando o serviço cumpre todos os critérios necessários, por exemplo, o serviço pode ter 50% de testes unitários apontados no sonar, teoricamente ele já cumpriria um critério do nível Regular, mas se os testes não estiverem na pipeline, o serviço não vai ser considerado dentro do nível Regular, e sim nível Básico. A partir disso, se inicia todo o planejamento e realização de ações para a melhoria dos serviços e do processo de qualidade.

É importante ressaltar que os critérios definidos neste modelo fazem sentido para nossa realidade, e que alguns serviços não vão conseguir cumprir todos os critérios, “e tá tudo bem” rsrsrs. É por este motivo que trabalhamos para manter o modelo vivo e evolutivo, e com isso ir melhorando conforme nossa necessidade.

Ganhos com o modelo

Um dos pontos mais positivo de todo o processo foi a aceitação e engajamento do time, não tivemos dificuldades para mostrar a importância do modelo, pois era nítido pra todos os nossos problemas e como poderíamos resolver.

Outro ponto extremamente importante dentro do time, foi o senso de dono e responsável pela qualidade, não temos um processo perfeito, mas hoje podemos dizer que as futuras features obedecem a um padrão mínimo e esperado de qualidade.

E o ponto mais importante: quase não temos problemas em produção com os serviços que estão atingindo o topo do modelo, além disso, a criticidade dos bugs são baixa.

Por fim, o intuito deste artigo foi dar um pouco de visibilidade da inciativa que criamos aqui no eCred para resolver alguns de nossos problemas.

Gostaria de agradecer a todos que participaram e contribuíram com o projeto, e a Samanta Cicilia que foi minha fonte de inspiração para o desenvolvimento deste artigo.

Espero que tenham gostado, fiquem à vontade para mandar sugestões, dúvidas ou trocar experiências.