Modelo de Maturidade em Qualidade de Software
Aqui na Pagar.me nós elaboramos um modelo de maturidade em qualidade, para avaliar as aplicações e assim ter uma visão clara de como essas aplicações estão e pra onde elas devem ir.
Nesse artigo vamos apresentar o nosso modelo, qual foi a inspiração para desenhá-lo, como podemos usá-lo e os próximos passos.
O que é um Modelo de Maturidade?
“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 recursos precisam adquirir a seguir para melhorar seu desempenho. Em muitos círculos, os modelos de maturidade ganharam má reputação, mas embora possam ser facilmente mal utilizados, em mãos adequadas podem ser úteis.” — Martin Fowler
Nesse trecho extraído do blog do Martin Fowler, podemos ver que o modelo de maturidade é uma ferramenta, não é uma forma de avaliar o desempenho de um indivíduo ou time, nem uma forma de burocratizar o processo como muitas pessoas pensam ao ouvirem esse termo. O modelo nos ajuda a ter uma visão clara. Eu costumo dizer que é um retrato da nossa situação e uma direção de como dar o próximo passo.
Para ajudar no entendimento, segue uma tabela de É/Não É sobre modelo de maturidade:
Como esse modelo foi criado?
Nosso modelo foi inspirado no TMMi (Test Maturity Model and Integration) que é um modelo complementar ao CCMI, ele é focado na melhoria do processo de teste de software. Além dessa influência, o modelo também foi construído com feedbacks e opiniões de diferentes pessoas dentro da companhia.
Nosso modelo é bem prescritivo e o que vamos apresentar aqui é a V1. Acreditamos muito em melhoria contínua, então elencamos algumas premissas pra essa primeira versão. Estamos experimentando e vamos evoluindo conforme formos vendo a utilização na prática.
Premissas:
- V1 com foco em qualidade em desenvolvimento de software, no futuro podemos incluir outros tópicos como processos, infraestrutura, quesitos de segurança;
- Num primeiro momento o objetivo é VISIBILIDADE, precisamos saber a saúde das aplicações para aí então priorizar as ações de melhoria;
- Priorizamos aplicações que estão com desenvolvimento ativo (aplicações estáveis a mais de 6 meses não foram consideradas no momento);
- Priorizamos a avaliação das aplicações mais críticas primeiro;
- Alguns ajustes para adequação são mais rápidos e fáceis de implementar, outros demandam um maior planejamento;
Vamos para o modelo!
Níveis:
O modelo tem 5 níveis: Inicial, Gerenciado, Definido, Maduro e Otimizado. Vamos detalhar aqui cada um deles:
1️⃣ Inicial:
“Sem processo estruturado. Os testes são definidos de acordo com a intuição. Testes feitos de forma manual com alguns poucos cenários feitos de forma automatizada”
Nesse primeiro nível, não existe nenhum processo de garantia de qualidade, é totalmente dependente de quem executa e não tem validação de forma automatizada. Temos apenas um critério nesse nível (que inclusive já foi um ajuste em relação a primeira versão). O processo de postmortem é bem importante não importa o nível da aplicação.
💎 Gerenciado:
“Estratégia de Testes definida mas com foco em comportamento funcional. Alguns testes de unidade/integração e alguns testes funcionais executados de forma manual.”
A partir do segundo nível a avaliação fica mais prescritiva e temos alguns itens:
Uma observação importante sobre esses critérios: nesse momento não estamos avaliando a qualidade dos testes existentes ou se o code review é feito de forma efetiva, é apenas se existem esses itens dentro do processo de desenvolvimento.
👍🏾 Definido:
“Tipos de teste definidos para cada cenário. Testes não funcionais executados de forma pontual. Métricas de qualidade de software definidas.”
Critérios:
🥳 Maduro:
“Automação de teste contínua e consistente. Testes podem prosseguir mesmo se componentes externos estão indisponíveis e podem ser executados continuamente como parte do pipeline de entrega de software — fornecendo feedback instantâneo em diferentes níveis. Uso de atributos de qualidade para definir estratégia”
Critérios:
🥇 Otimizado:
“A automação de teste é feita de forma abrangente e é suportada por uma virtualização de serviço sofisticada e com estado e geração/provisionamento de dados de teste. As métricas estão em local para monitorar e melhorar continuamente a eficácia do processo de teste de software. Teste Contínuo é adotado e todas as validações estão no processo de CI/CD.”
Como é feita a avaliação:
Nesse primeiro momento a avaliação está sendo feita de forma manual por uma planilha, porém no tópico sobre próximos passos eu vou comentar sobre a automatização desse processo.
Na planilha temos algumas colunas, como segue:
Feito esse preenchimento partimos para avaliação da maturidade:
Então, para estar em classificada em determinado nível a aplicação precisa cumprir alguns dos requisitos daquele nível, mas para mudar para o próximo ela precisa ter atendido a todos os requisitos anteriores.
Dúvidas que podem surgir:
1- Mas e se a aplicação atende a critérios de um nível mais avançado e não atende alguns níveis básicos?
A aplicação pode ter, por exemplo, 70% de cobertura de testes de unidade e integração (o que é um critério do nível Maduro), mas não tem acompanhamento das métricas definidas ou documentação (itens dos níveis anteriores).
A aplicação não vai ser considerada Madura nesse caso, ela vai ser encaixada no nível em que cumpre a maior parte dos requisitos.
2- Mas e se os critérios não fizerem sentido para determinada aplicação?
Isso pode acontecer, podem ter aplicações, por exemplo, em que o teste de performance não faça sentido, então esse item não será obrigatório para essa aplicação.
É importante entender que o Modelo não é simplesmente 0 ou 1, ele precisa de contexto!
3- Posso copiar esse modelo pra minha companhia?
Poder você até pode, mas não sei se é uma boa ideia. Ele foi criado e validado para o nosso contexto.
Então minha dica é: se inspirar e montar o que faz sentido para você
4- Podem existir aplicações que não se encaixem no modelo?
Pode sim. Como eu comentei no início é uma primeira versão, estamos experimentando e validando e vamos melhorá-la conforme a necessidade. Não adianta de primeira querermos prever todos os casos de exceção.
5- Como fazer a reavaliação?
Não adianta muito fazer uma reavaliação, se você sabe que não foi feito nenhum esforço de melhoria em relação àquela aplicação. Uma sugestão é fazer a reavaliação dentro do seu período de contratação de objetivos. Por exemplo: se os objetivos são trimestrais e vão entrar itens relacionados a melhoria de qualidade, você pode fazer a reavaliação dali a 3 meses.
Outro ponto importante é conseguir amarrar no processo as aplicações que não vão ser “melhoradas”, para que elas não piorem e não tenham quedas de maturidade.
Próximos passos:
Nós já temos alguns próximos passos mapeados para evoluir o nosso modelo. Vou citar aqui dois deles:
1- Planejamento de objetivos com base no modelo:
Como agora sabemos em que nível as aplicações estão, podemos olhar para o próximo nível para definir os objetivos.
Obviamente aqui de novo vale a análise de contexto e não só “porque preciso aumentar a maturidade”.
2- Automação da coleta (ou pelo menos parte dela):
O trabalho inicial de coleta é bem custoso, e algumas informações podem ser coletadas de forma automática, como é o caso da cobertura de código e dos tipos de teste existem no pipeline.
Então um outro passo planejado é ver que informações podem ser capturadas automaticamente e preenchidas na própria planilha. - Um outro passo futuro é ter isso numa base e conseguir criar uma dashboard.
Concluindo
Espero que tenham gostado desse post, como eu comentei foi uma iniciativa criada para atender uma necessidade que vivemos aqui na Pagar.me. Espero que isso inspire vocês a adequarem o modelo para sua realidade.
Fiquem à vontade de comentar o que acharam e se já fizeram algo parecido!
Agradeço aqui também a todas as pessoas que participaram desse trabalho :)
E por último, mas não menos importante. Temos vagas aqui na Pagar.me! Dá uma olhada nas nossas posições e vem fazer parte do time!
