AltoQi - Uma história de desafios e inovação - Parte 4: Engenharia de software

Os anos entre 2000 e 2005 foram bastante produtivos para a AltoQi. As Versões 2002 do Eberick, Hydros e Lumine formavam um pacote de soluções para projeto de bastante sucesso. A AltoQi tinha deixado de ser uma empresa de software para projeto estrutural e alcançado um patamar mais abrangente de soluções para projeto de edificações. 

No Eberick, lançamos também o Módulo Escadas, primeiro elemento de projeto que conseguimos modelar, analisar e detalhar no Eberick que não era uma extensão dos elementos originais da Linha Pro (vigas, lajes, pilares e fundações).  

No Hydros, criamos o Módulo Gás, que abria um novo leque de projetos em uma solução bastante similar à do projeto hidráulico, e o Módulo Incêndio, que trazia para as ferramentas de projeto um dimensionamento iterativo de vazões e pressões em redes de hidrantes e sprinklers que até então podia ser encontrado apenas em planilhas isoladas. 

No Lumine, estendemos a solução original de fiação automática entre pontos de luz e de força com um cadastro de tipos de ponto que permitia representar arranjos mais complexos envolvendo componentes específicos (como relés e sensores etc.) através de regras cadastradas pelos próprios usuários.  

Essa ainda é hoje a mesma solução embutida no AltoQi Builder e que permite cadastrar os componentes mais modernos nos projetos de automação residencial. Além disso, criamos o Módulo Cabeamento, que estendia o escopo do programa para uma outra gama de projetos. 

Tudo isso se consolidou nas versões que foram icônicas para a época: Eberick V5, Hydros V4 e Lumine V4.  

Além desses três, tínhamos também o QiCAD V3 e seu módulo Editor de Armaduras que complementava o Eberick. O QiCAD também tem um papel importante na história da AltoQi, mas isso fica para um outro artigo.  

Tínhamos crescido a nossa base de clientes, de 4.500 para cerca de 12.000, e crescido internamente como empresa, com departamentos distintos para Desenvolvimento, Marketing, Comercial e Suporte Técnico. 

Novo cenário na equipe de Desenvolvimento 

No Departamento de Desenvolvimento, dos cinco membros originais do time do Eberick, três já tinham saído para perseguir objetivos próprios. Trouxemos outros membros para a equipe, ainda bastante enxuta para conduzir a evolução de todos esses produtos em paralelo. 

Cerca de 10 anos depois da minha entrada na AltoQi, éramos um grupo um pouco maior, que tinha a responsabilidade de manter produtos complexos utilizados por milhares de clientes, mas ainda trabalhávamos basicamente da mesma forma como no início.  

Eu mesmo fazia o levantamento e detalhamento de todas as regras de negócio para implementação pelos nossos desenvolvedores.  

Essas novas implementações eram validadas por mim e alguns colegas, mas a verificação sobre possíveis regressões na ferramenta era feita ao final dos projetos, com o apoio da equipe de Suporte Técnico. O time basicamente tentava verificar se os novos recursos não haviam causado nenhum problema nos recursos existentes, que a cada versão eram em maior número. 

Essa história não é diferente do que se escuta hoje em diferentes startups, ou pela qual elas passarão em algum ponto do seu futuro. 

Por um tempo, você consegue desenvolver softwares sem se preocupar com a estrutura e manutenção dele. Você consegue adicionar novas funcionalidades com facilidade, pois os desenvolvedores conhecem bem a base de código que eles mesmos criaram. Você consegue testar o seu produto de maneira informal, pois não existem tantos aspectos a serem conferidos.  

Com o tempo, os desenvolvedores originais saem da empresa, a base de código se torna muito maior e é difícil para novos desenvolvedores adicionarem funcionalidades a um software que eles já não conseguem entender completamente.  

Em algum ponto ao longo da jornada de um produto (se ele viver o suficiente para passar por isso), a empresa precisa tomar ações para garantir a sua manutenibilidade no futuro. E esse foi o desafio que tive que encarar como Gerente de Desenvolvimento. 

O problema que tivemos que enfrentar 

No caso da AltoQi, o problema ocorreu por volta de 2005 a 2006, durante o projeto da versão que viria a se chamar Eberick V5 Gold.  

Diferente das versões que tinham sido trabalhadas até então, que eram sempre adições de funcionalidades, nessa resolvemos alterar um aspecto da base no nosso ambiente de modelagem.  

Até então, os pilares eram representados como elementos pontuais diretamente na posição em que seriam aplicados no modelo do pórtico (com a seção real sendo uma informação apenas de desenho). Com a alteração, eles passariam a ser representados por suas seções reais e as ligações com as vigas que chegavam neles seriam montadas automaticamente pelo programa. 

Se conceitualmente a alteração pode não parecer complexa, na prática ela afetava muitos aspectos do programa.  

Alterava ferramentas de lançamento, tanto dos pilares como das vigas. Alterava a montagem do modelo de análise. Alterava a obtenção e tratamento das informações necessárias para determinação dos apoios das vigas sobre esses pilares. Além disso, alterava modelagem, análise e dimensionamento das lajes que estavam na região desses pilares.  

Na mesma versão, estendemos também o escopo de atuação do Eberick para o projeto de lajes planas, apoiadas diretamente sobre pilares com ou sem capitéis. Essa mudança, que colocava o programa em outro patamar, também trazia um novo grau de complexidade tanto para o lançamento gráfico como para a modelagem automática dos painéis de lajes. 

Desta vez, cada nova alteração impactava uma série de recursos existentes e nosso procedimento de teste era insuficiente para capturar todos os problemas. Quando os problemas eram detectados, a correção deles gerava outros impactos, que também demoravam muito a serem encontrados, pois os ciclos de testes manuais eram muito longos.  

Nesse projeto, a etapa de estabilização do programa para lançamento levou quase um ano inteiro (mais do que o tempo que havia sido usado para o desenvolvimento dos recursos) e nos custou um volume de correções que ainda levaria meses a ser completamente tratado depois.  

Como tivemos que evoluir enquanto equipe e empresa 

Para sair desse problema, tivemos que nos profissionalizar, investindo em boas práticas de Engenharia de Software que nossa inexperiência nos tinha feito ignorar.  

O aspecto mais crítico dizia respeito aos Testes.  

Existem duas estratégias principais para teste de software: os testes de “caixa preta” e os testes de “caixa branca”. Os testes de caixa branca, ou testes estruturais, são utilizados para avaliar o comportamento interno do software, usualmente para verificar funcionalidades individuais, através de testes unitários.  Essa abordagem foi descartada, pois já tínhamos nesse ponto um volume de código legado acumulado muito grande.  

No seu lugar, investimos nos testes de caixa preta, ou testes funcionais, utilizados para avaliar o comportamento externo do sistema, ignorando detalhes específicos de sua implementação e procurando testar o sistema como um todo, ao representar a interação do usuário com o software.  

Para isso, implantamos um sistema próprio de automação de testes e criamos, dentro do Time de Desenvolvimento, o papel específico de Engenheiro de Testes, responsável por planejar e construir a base de testes que viria a garantir uma regressão completa do sistema a cada modificação efetuada.  

Esse trabalho foi transferido da equipe de Suporte para uma nova equipe dedicada apenas a essa tarefa. Meu colega Rodrigo Koerich foi o líder da primeira equipe de testes alocada sobre o projeto da V5 Gold. Desde aquela época até hoje, cerca de metade da equipe de desenvolvimento é composta por profissionais da área da Computação e a outra metade por profissionais da área de Engenharia.  

Essa base foi crescendo ao longo dos anos, contendo hoje mais de 12.000 testes automatizados em cada produto (Eberick e Builder), que são executados diariamente para garantir 100% de regressão na implementação de qualquer nova funcionalidade. Nenhuma versão desses produtos é liberada aos clientes sem que 100% desses testes, que representam as diferentes funcionalidades do programa, estejam sendo executados sem erros. 

Em paralelo a isso, implantamos um sistema e política de controle de versões (antes feito apenas informalmente) e um sistema para controle das solicitações (voltado, inicialmente, para gerenciamento dos problemas reportados pelos clientes e das correções efetuadas).  

Colhendo os resultados pelo esforço 

Quando foi possível combinar as três técnicas (controle de versões, controle de mudanças e testes automatizados), a equipe finalmente pôde estabelecer um conceito fundamental para apoiar o gerenciamento do projeto: a rastreabilidade bidirecional.  

Isso significa associar qualquer modificação efetuada no programa aos requisitos que a motivaram e, com isso, avaliar com muito mais rapidez qualquer defeito que tenha sido inserido por essa modificação. 

Antes de conseguirmos isso, a equipe lidava com cada problema reportado pelos clientes apenas investigando-o diretamente. Esse procedimento podia gerar impactos em outras partes do programa que não eram detectados rapidamente, levando ao longo ciclo que enfrentamos até a estabilização do Eberick V5 Gold.  

Essa estabilização só foi possível com a automação dos testes, que limitou a propagação de defeitos e reduziu drasticamente custo de cada correção, uma vez que o defeito podia ser detectado rapidamente e rastreado até a sua origem. 

Esse ciclo de melhoria levou dois anos para ser implementado. Com ele, conseguimos retomar o controle sobre o nosso processo de desenvolvimento, resolver os problemas criados sobre o Eberick e passar da manutenção para a melhoria no processo de desenvolvimento de novos produtos.  

A migração para um modelo de desenvolvimento iterativo, que será assunto do próximo artigo, foi possível apenas tendo por base a correta aplicação de boas práticas da Engenharia de Software. 

Algumas reflexões sobre o desafio

Embora eu tenha me interessado pela Computação desde cedo e fosse proficiente o suficiente em programação para apoiar meus colegas desenvolvedores diretamente sobre o código fonte, a minha formação é em Engenharia Civil, com Mestrado em Estruturas, que é o que tinha me levado originalmente ao Eberick.  

O resto da minha equipe, embora tivesse formação na área, também era composto de jovens profissionais que não tinham na época em sua graduação uma base mais sólida de Engenharia de Software. Especialmente, não tinham o link disso com os problemas práticos que são enfrentados pelas empresas no desenvolvimento de produtos. 

Trabalhamos 10 anos nisso com muito entusiasmo e criatividade, resolvendo os problemas conforme eles apareciam, mas em uma abordagem totalmente “ad hoc” e até mesmo amadora.  

Algumas pessoas chamam isso de “modo startup”, o que tem uma certa relação com a verdade, mas que não se sustenta nessa grande maratona que é o Desenvolvimento de Produto. Aprendemos isso a duras penas e este artigo conta um pouco sobre essa “dor do crescimento” que tirou a nossa equipe da infância e a levou para a juventude. 

Minha jornada pessoal de amadurecimento ocorreu em paralelo nesse período. Investi na formação que me faltava, com uma Pós-graduação em Engenharia de Software, que me trouxe esses conceitos que pude aplicar no nosso processo, e uma certificação Project Management Professional (PMP) do PMI, que me mostrou a importância do planejamento e de um processo estruturado para maximização dos resultados. 

A combinação entre as técnicas de Engenharia de Software, a base do PMI e um mergulho no mundo das Metodologias Ágeis foi o que me permitiu conceber e implementar um Processo de Desenvolvimento que colocaria a nossa equipe em outro patamar.

A migração para um modelo de desenvolvimento iterativo, que será assunto do próximo artigo, foi possível apenas tendo por base a correta aplicação de boas práticas da Engenharia de Software.