Como controlar a qualidade do software no mundo ágil?

Autor: Fabrício Fujikawa

Uma vez que as práticas ágeis de desenvolvimento de software estejam em pleno uso na sua empresa por seus times, é bem provável que você encontre alguns problemas em relação ao processo de desenvolvimento:

- novos releases quase sempre acompanhados de novos bugs;

- dúvidas se o esforço de desenvolvimento está indo para valor adicionado ao produto ou para manutenções corretivas;

- não-conformidades e divergências em relação ao padrão corporativo (mesmo entre analistas de uma mesma equipe);

- diferentes padrões de desenvolvimento e metodologia entre os times;

- falta de sinergia entre as equipes e dificuldades para fazer um rodízio entre os analistas de times diferentes (afinal, cada equipe faz do “seu” jeito).

Uma solução tradicional seria montar um time de controle de qualidade para inspecionar os artefatos e testar as releases, apontar as não-conformidades, bugs e rejeitá-los. Simples, porém um paradoxo conceitual. Afinal, todo o ganho de agilidade nas entregas pode ser colocado em risco se deixarmos para descobrir, lá no finalzinho, que parte do software precisa ser refeita. Facilmente, para cada correção, podemos adicionar algumas semanas no prazo final. Ou, então, aquela correria de entrega final, com custos de horas-extras e a penalização motivacional do time, além de prejudicar a qualidade do produto (“testa aí, rapidinho…”).

É possível fazer diferente, com bons resultados. Podemos contar o caso, ocorrido numa grande organização, onde atuamos na causa-raíz do problema (a falta da cultura de testes e a baixa aderência à metodologia de desenvolvimento pelos desenvolvedores), e não apenas nos sintomas (artefatos com não-conformidades e bugs), focando na importância de se construir software com qualidade desde o início.

Em conjunto com a equipe de qualidade, criamos indicadores para acompanhamento das entregas e do trabalho dos desenvolvedores, tangibilizando os pontos fortes e os pontos de melhoria. Livres do rigor acadêmico, alguns indicadores eram simplesmente valores booleanos que indicavam se uma prática era seguida. Eles foram divididos em quatro grandes temas:

- Processo de Desenvolvimento de Software

- Produto

- Eficiência e Melhoria Contínua

- Cliente/Negócio

Fizemos uma apresentação dos indicadores para todos os desenvolvedores na reunião geral da Gerência de Desenvolvimento de Produtos, mas a receptividade deixou a desejar: alguns desenvolvedores sentiram-se "auditados". Sempre acreditando no trabalho colaborativo, fizemos encontros com cada equipe para esclarecer dúvidas e reforçar o foco na melhoria do processo, e não no controle individual de desempenho.

Também para melhorar a comunicação com os times, criamos um rito ao final de cada sprint, a Retrospectiva Técnica, em que o time de qualidade apresentava para cada célula de desenvolvimento a sua planilha de indicadores, e eram levantados pontos de melhoria e respectivos planos de ação.

Após dois anos de trabalho, tivemos sólidos resultados.

Melhoria da Qualidade do Software Produzido

Redução direta do custo do desenvolvimento. A relação de causa e efeito foi visível: os times mais aderentes à metodologia de desenvolvimento tinham menos defeitos no software produzido. Além disso, identificamos que estava ocorrendo muito trabalho em correções de funcionalidades que já tinham sido dadas como concluídas. E, pior, sem reflexo em nenhuma métrica de acompanhamento, já que o indicador de defeitos, inicialmente, só monitorava sistemas em Produção. Mudamos o conceito do indicador para abranger as manutenções corretivas em todas as funcionalidades concluídas pelos times, mesmo que ainda não estivessem em Produção. Assim, cobrimos este aspecto da qualidade já na fase de desenvolvimento. Descobrir defeitos mais cedo sai mais barato.

Criação de Comunidade de Práticas: Fórum de QA

Conseguimos um compartilhamento contínuo de conhecimento tácito entre os participantes através de encontros periódicos. As reuniões de retrospectiva técnica foram fundamentais, pois permitiram o compartilhamento de experiências e debates, incluindo “lavagem de roupa suja”, com os desenvolvedores apresentando suas insatisfações e críticas com a metodologia. Isto permitiu uma melhoria contínua do processo. Tanto que elas evoluíram para uma comunidade de práticas, chamada de Fórum de QA, formada por representantes de todas as equipes de desenvolvimento, onde também tivemos troca de experiências, discussões sobre dificuldades, sugestões e dúvidas técnicas que ocorriam no dia-a-dia dos times.

Ampliação do Uso dos Cenários de Testes

Na metodologia de desenvolvimento da empresa, um documento muito relevante era o Cenários de Testes, escrito pelos próprios desenvolvedores, no formato “Given-When-Then”, de especificação comportamental (BDD). Com o passar do tempo, vários outros pontos de utilização dos documentos dos cenários de testes, não imaginados inicialmente, foram identificados:

- na validação do PO técnico;

- na validação do cliente;

- na review;

- na ambientação de novos colaboradores;

- no apoio à equipe que cuidava da operação do software em Produção;

- na definição dos cenários para testes de performance.

O fato de os documentos serem criados na plataforma Google Docs, disponível via internet para todos os usuários da empresa, e não só os da Tecnologia, viabilizou e liberou todo o potencial de uso dos artefatos, que se tornaram a principal forma de compartilhamento e reuso de conhecimento explícito na metodologia.

Automatização dos Testes

À medida que a cultura de desenvolvimento orientado a testes (a partir dos cenários de testes) foi absorvida pelos analistas, começamos a buscar soluções para automatização. Ao final do trabalho, todos os times já executavam testes automatizados: tanto os unitários, como também os testes de interface. Testes de regressão que levavam algumas horas para serem feitos manualmente, passaram ser executados em cerca de 20 minutos. Com os deploys constantes de seus produtos, isto representou uma redução significativa de custos para a empresa.

Simplificação da Planilha de Acompanhamento dos IndicadoresAo longo do tempo, o acompanhamento dos indicadores foi simplificado, e reduzimos os indicadores para apenas quatro: um para cada tema. O objetivo foi focar no essencial e tornar a metodologia de acompanhamento mais leve.

Pesquisa de Satisfação com a Metodologia de Desenvolvimento

Tivemos 73,9% de avaliações positivas, respondidas pelos desenvolvedores e Scrum Masters.

Apoio e Patrocínio são Fundamentais

Mudar cultura é complexo. A alta gerência precisou atuar em alguns momentos como mediadora entre as equipes de desenvolvimento e a Equipe de QA, mantendo saudável a relação entre os analistas envolvidos. Sem este apoio, a iniciativa teria fracassado, sem dúvidas. Nossa experiência mostrou que é possível fazer software rápido e bem-feito. Trabalhar na causa-raíz do problema, na cultura de desenvolvimento, é uma jornada árdua, que exige paciência e evangelização, mas compensa com resultados concretos, duradouros e, sim, mensuráveis.

FONTE: CorpTV