Navegue
cultura da qualidade
Compartilhar no facebook
Compartilhe no Facebook
Compartilhar no twitter
Compartilhe no Twitter
Compartilhar no linkedin
Compartilhe no Linkedin

O MVP e a cultura da qualidade

MVP, do inglês Minimum Viable Product é o produto mínimo viável, e consiste na prática de lançar um produto com as principais funcionalidades e com investimento mínimo. Essa prática permite testar o negócio antes de realizar investimentos maiores, validando a eficiência do produto, sua usabilidade e aceitação no mercado. Esse conceito foi popularizado por Eric Ries, consultor e escritor sobre startups, no livro The Lean Startup.

Já a definição de qualidade de software é um pouco mais complexa e tem na literatura diferentes interpretações de variados autores. O glossário do IEEE define qualidade como “Grau de conformidade de um sistema, componente ou processo com os respectivos requisitos”, ou como “Grau de conformidade de um sistema, componente ou processo com as necessidades e expectativas de clientes ou usuários”.

Apesar do conceito de MVP ser aplicado ao produto, a filosofia de se entregar o máximo de valor com o mínimo de recursos pode ser aplicada a quase tudo, em qualquer área de conhecimento.

Logicamente todos nós desejamos o estado da arte, mas na grande maioria das vezes é extremamente difícil atingí-lo, pelos mais diferentes motivos.

Em qualidade, mais especificamente na qualidade de software e na qualidade de software dentro de metodologias ágeis, o estado da arte poderia ser algo como:

“Times multidisciplinares maduros, com Product Owners (PO’s) escrevendo histórias ‘INVEST’, UX’s criando wireframes assertivos para cada história, desenvolvedores realizando testes unitários/integração automatizados, code review independente, versionamento com ferramenta e processos bem definidos, interagindo por meio de uma boa comunicação com os testers, que documentam os casos de testes em uma boa ferramenta que seja integrada à ferramenta de requisitos, mantendo assim a rastreabilidade entre as execuções dos testes funcionais, as histórias e os bugs. Além disso, as principais funcionalidades são automatizadas, a automação dos testes funcionais e unitários roda em um ambiente de integração contínua, gerando relatórios diários para a gerência.

Por falar em ambiente, no mínimo 4 estão disponíveis: DEV, QAS, STG e PROD.” O ambiente de QA permite a execução da automação diariamente, em que o dump da base de dados também é realizado de forma automática, mantendo a massa de dados do QA sempre atual e funcional. O ambiente de Stage permite a realização dos testes de carga, stress, performance e segurança. Tudo isso acontecendo em um ambiente no qual os times de desenvolvimento seguem as diretrizes do manifesto ágil, a comunicação é eficaz, a gerência motiva o time por meio da confiança, autonomia e a organização valoriza a cultura de qualidade, tanto dos produtos quanto dos processos. Ah, faltou dizer que o processo de melhoria contínua também funciona.

UFA! Talvez a palavra “Devop’s” resumisse as últimas 9 linhas desse artigo, mas vamos manter o foco: O MVP da qualidade. Vamos chamá-lo de MVQ!

O cenário descrito acima não é uma utopia. Empresas com grande maturidade no desenvolvimento e na qualidade de software possuem até mais que isso. Mas vamos a um cenário encontrado recentemente, que se assemelha a maioria dos cenários encontrados na maioria dos projetos:

“Um projeto em desenvolvimento há um ano, sem tester no time, em que os testes funcionais foram executados pelo Product Owner. O Scrum, que pode ser considerado um “template”, foi adaptado à realidade, na qual a Review por exemplo foi substituída por uma “Demo” interna.

Nenhum caso de teste registrado. Sem ferramentas, muito menos automação. Carga e Stress: o que é isso? A qualidade se restringia a testes unitários e code review, por parte dos desenvolvedores.”

Então, uma analista de testes foi alocada ao projeto. Vindo de um projeto rodando corretamente, com testes funcionais sendo executados e documentados, os bugs registrados, a rastreabilidade mantida entre histórias -> casos de testes -> bugs e a automação sendo entregue para as histórias da sprint anterior, seria natural que ela tentasse implantar o mesmo processo nesse time.

Não funcionou. Existe um fator muito importante que muita gente esquece e deixa de trabalhar: A cultura. E esta geralmente está acravada em uma área e dentro de um time. Hoje é comum encontrar diversas culturas distribuídas dentro de uma mesma organização.

E esse foi o fator a ser trabalhado nesse time. Não existia QA, e agora existe. O que fazer? O MVQ. O menor valor de qualidade possível, entregue pouco a pouco, um pouquinho a mais a cada sprint.

E esse pouquinho adicional vai sendo embutido na mentalidade de desenvolvedores, P.O’s, gerentes etc. Pode-se dizer que o MVQ é composto por pequenos objetivos a serem atingidos o mais rápido possível e então incrementados. Nunca deixando de ter em mente que cultura não se impõe, deve ser trabalhada!

Como aplicar o MVQ

O primeiro passo, já implantado e executado pela primeira analista, foi a criação de casos de testes de regressão. Esses testes foram executados e dezenas de bugs foram abertos e registrados. A cada sprint, o time ia “matando” os bugs abertos, ao passo em que as novas features eram desenvolvidas. E claro, os casos de testes eram registrados em uma ferramenta e executados (não necessariamente dentro do sprint atual). Alguns sprints rodaram dessa forma, até que todos os bugs (da regressão) foram exterminados.

Os próximos objetivos dentro de um MVQ

Bom, é comum que dentro do Definition of Done das histórias estejam os casos de testes escritos e executados, evidências coletadas, bugs corrigidos e as histórias sejam aprovadas pelo QA. Percebeu-se também que os critérios de aceite das histórias precisavam melhorar, então o QA  passou a ajustar os critérios de aceite com o P.O.

Alguns sprints quase tiveram 100% das histórias entregues com o DoD completo, mas até o momento ainda não atingimos esse objetivo. E aqui entra um fator importante na busca pela transformação da cultura da qualidade: O MVQ é incremental, mas não é necessário que se atinja 100% de um ou mais objetivos antes de se iniciar outros.

Iniciou-se então a inclusão de um novo objetivo dentro do MVQ: A automação de testes!

Com o processo de desenvolvimento ágil rolando mais “redondo”, foi possível que os QA’s tivessem tempo para criar um backlog de automação, para as features mais críticas

do sistema. Esse backlog vem sendo trabalhado, e atualmente, em alguns sprints, é possível atingir o target de automatizar as histórias do sprint anterior.

Dentre os próximos objetivos dentro do nosso MVQ, podemos citar:

  • atingir o objetivo de entregas de sprints com 100% de aprovação do QA;
  • automatização da automação, colocando nossos testes pra rodar em um ambiente cloud e integrado;
  • dump automático com a base de dados original antes de rodar a automação e;
  • talvez o mais importante objetivo de TODOS: Disseminar a cultura de qualidade para todos os times, áreas e empresa.

E assim, de MVQ em MVQ, é possível construir o caminho para o estado da arte. O importante é que nessa caminhada a cultura da qualidade seja incorporada na cabeça de todos, pois o VALOR da qualidade vai sendo demonstrado e absorvido a cada entrega, a cada interação.

Fabiano Pereira

 

Receba nossos conteúdos

Preencha seu email e receba nossos conteúdos sobre Gestão de Ativos

Entre em contato

Email: contato@atech.com.br
Tel.: 55 (11) 3103-4600
Rua do Rocio, 313 – 5° andar
Vila Olímpia – São Paulo – SP

Copyright © 2019. Todos os direitos reservados.
Criado pela Intelligenzia