Em meados de 2008, estávamos saindo da nossa fase mais problemática no Desenvolvimento da AltoQi, que tinha sido a estabilização do Eberick V5 Gold, possível apenas com uma profissionalização substancial nas nossas atividades.
Nesse ano, fizemos o lançamento do Eberick V6, que tinha essencialmente os mesmos recursos da V5 Gold, mas um novo núcleo de processamento, que permitia a análise da estrutura em um tempo 5 a 10 vezes menor do que na versão anterior. Mais do que um lançamento comercial, nosso objetivo tinha sido marcar o final daquela fase.
No mesmo período, fizemos também o lançamento dos módulos Muros e Reservatórios. O plano original era ter feito isso sobre a versão corrente V5 Gold, mas os problemas que estávamos tendo com ela nos impediram. Tivemos que fazer esse desenvolvimento sobre a versão V5 anterior e, por um tempo, a versão V5 Gold não teve todos os recursos disponíveis na V5, que precisou ser comercializada em paralelo.
O Eberick V6 marcou o ponto onde conseguimos juntar tudo isso, obtendo uma versão que incluía os recursos da V5 Gold (projeto de lajes planas, maciças ou nervuradas, apoiadas diretamente sobre os pilares, contendo ou não vigas chatas no modelo) e ainda a possibilidade de modelar, analisar, dimensionar e detalhar paredes de contenção e reservatórios incorporados ao modelo.
Processo iterativo e incremental
Como já abordei no artigo anterior, junto com os testes automatizados e controle de versões, tínhamos implantado uma ferramenta para controle de solicitações, o Mantis, para controlar melhor as mudanças solicitadas (que antes eram feitas por e-mail) e estabelecer o conceito de rastreabilidade bidirecional entre os problemas reportados e as soluções implementadas no código.
Paralelamente, fizemos as primeiras iniciativas para se ter um planejamento básico e gerenciamento dos projetos de desenvolvimento. Pode parecer estranho dizer isso hoje, mas isso não existia antes da V5 Gold. Apenas tínhamos as versões a serem desenvolvidas e uma certa expectativa do tempo que levaríamos para entregá-las. Foi apenas quando tivemos um projeto que estourou qualquer ideia de prazos que precisamos procurar uma abordagem mais estruturada.
Começamos com uma abordagem clássica, utilizando a ferramenta DotProject, mas rapidamente percebemos que ela não se aplicava bem ao nosso cenário de desenvolvimento. O nosso fluxo de trabalho já utilizava equipes multidisciplinares (engenheiros e desenvolvedores) e três etapas para organizar o desenvolvimento de qualquer funcionalidade (Feature):
- o detalhamento dos requisitos funcionais em cada aspecto específico necessário (interface, algoritmos etc.);
- a implementação desses requisitos no código do programa, utilizando uma abordagem de integração contínua, que gerava versões completas e integradas a cada alteração; e
- o teste completo de cada alteração no programa.
Essas características nos levaram para o caminho das metodologias ágeis, que ganharam força no mercado a partir de 2001, com a publicação do Manifesto Ágil e a popularização do Scrum e do XP, mas que ainda eram uma novidade no Brasil.
O modelo de ciclo de vida que adotamos, de natureza iterativa e incremental, se baseia nesse refinamento sucessivo do produto através de múltiplos ciclos de análise, projeto, implementação e teste em cada nova Feature.
Nos primeiros anos, essa descrição de processo era fundamentada no Scrum e compartilhava muitos dos artefatos com essa metodologia, que se assemelhava à nossa visão específica sobre como os projetos deveriam ser conduzidos. 
Gestão de produto e portfólio
Embora as empresas de desenvolvimento de software, de forma geral, trabalhem na criação de Produtos, nem todas organizam efetivamente isso na forma de Projetos. O estabelecimento desse conceito foi o primeiro passo na implantação do nosso modelo de desenvolvimento. Fizemos a definição sistematizada do Escopo de cada projeto antes do início dele e cuidamos para ter o controle sobre as mudanças nesse escopo ao longo do projeto.
Para isso, separamos do Desenvolvimento o Departamento de Produtos e Serviços (DPS), liderado pelo Engº Rodrigo Koerich, distinguindo de maneira clara as atividades de definição do escopo do projeto (necessidades dos clientes) das atividades de execução desse escopo (desenvolvimento de software).
O DPS, além do suporte técnico aos clientes, tinha a responsabilidade de avaliar, priorizar e posicionar a empresa com relação às necessidades do mercado e repassar essa priorização para que o Desenvolvimento produzisse as necessidades selecionadas.
Essa etapa de prototipação dos recursos a serem incluídos nos projetos de desenvolvimento é, até hoje, um dos pontos fortes do nosso processo.
Estimativas de software
Dentre os aspectos que foram importantes para a criação de um processo de desenvolvimento que fosse efetivo, o mais complexo deles foi a estimativa dos produtos de software.
Em 2009, estávamos saindo de um ciclo vicioso de manutenção que tínhamos sofrido no Eberick V5 Gold. Além disso, a capacidade da empresa de entregar novos produtos, no prazo definido e com a qualidade necessária, estava sendo questionada.
No aspecto da qualidade, a implantação das práticas de teste automatizado foi fundamental. No aspecto do cumprimento dos cronogramas, era preciso estabelecer uma forma adequada de estimar os projetos a serem desenvolvidos.
Existem muitas dificuldades conhecidas no ato de estimar:
- Ambiguidade e volatidade nos requisitos, impedindo estimativas sobre requisitos que não estejam corretamente definidos. Atacamos esse problema com a criação do Departamento de Produtos e Serviços e o investimento em uma fase clara de Preparação dos projetos.
- Falta de medições adequadas e de referências válidas (comparação entre os valores estimados e os realizados), sem retorno para a equipe quanto à qualidade e utilidade das suas estimativas. Atacamos esse problema implantando uma ferramenta de gerenciamento de tarefas que se baseasse nas metodologias ágeis, mas que também estabelecesse o apontamento de horas nas atividades e permitisse usar as informações coletadas como subsídio para o planejamento dos próximos projetos.
- Visão distorcida do que seja estimar, sem diferenciar a estimativa dos conceitos de meta e compromisso. Uma estimativa é uma avaliação aproximada de algo (ato técnico de atribuir um tamanho a uma determinada grandeza). Com base nela, pode-se estabelecer uma meta relacionada a tempo e valor (ato gerencial) e assumir um compromisso, ou seja, o acordo final e responsabilidade sobre o resultado do projeto. São três variáveis diferentes, que tratamos com a inclusão de critérios explícitos de variabilidade no planejamento dos projetos.
Existem vários procedimentos disponíveis em bibliografia para estimativa de software. Quando começamos, nos baseamos no Scrum e no procedimento mais comum nas metodologias ágeis, os Stories Points, uma unidade de medida aplicada para representar o tamanho/complexidade de cada User Story (funcionalidade do sistema), na qual o valor isolado de uma estimativa não tem qualquer importância, mas sim o tamanho relativo entre os diversos recursos do projeto.
O tamanho representa uma medida da atividade que deve ser independente do profissional que a executa. Para que se obtenha o esforço estimado (número de horas necessárias), deve-se conhecer a produtividade do profissional ou da equipe, valor que só pode ser obtido na execução de atividades anteriores que tenham sido estimadas da mesma forma. 
Esse critério foi usado durante o primeiro ano de implantação do processo, gerando resultados interessantes e trazendo bom grau de controle ao projeto no qual estava sendo aplicado, mas apresentou algumas deficiências.
Em primeiro lugar, mesmo mantendo a equipe na execução de uma sequência de projetos, esse procedimento estabelecia uma escala relativa de tamanho adequada entre as Stories desse projeto, mas apresentava dificuldades na comparação de um projeto com o outro.
Em segundo lugar, e mais importante, como tínhamos mais de uma equipe trabalhando nas linhas de desenvolvimento, o critério das Story Points utilizava referências diferentes em cada equipe, inviabilizando um controle organizacional do desempenho dos diversos projetos.
Para melhorar o processo, foram avaliadas outras técnicas de estimativa, mas nenhuma das técnicas estudadas pôde ser aplicada diretamente. Os Stories Points apresentavam a dificuldade de comparar os resultados entre equipes diferentes. Outra métrica, a dos Pontos de Função, objetivava justamente definir um critério de medida que seja válido entre diferentes organizações, mas esse processo de contagem não é bem definido para aplicações baseadas em computação gráfica.
Procurando aproveitar o melhor de cada técnica, criamos uma escala própria de decomposição funcional (pontos de função) para nossos requisitos. Ao invés de estimar diretamente uma User Story, ela é dividida em quantos aspectos funcionais possam ser identificados (ferramentas gráficas, algoritmos de dimensionamento, geração de desenhos etc.) e cada uma dessas partes é estimada.
Ao reduzir um problema a aspectos mais genéricos, tornou-se possível manter uma consistência entre diversos projetos e mesmo entre as equipes que lidam com Produtos diferentes.
Os resultados obtidos com as estimativas nunca são totalmente precisos, mas são úteis e servem ao propósito estabelecido pela organização. Esse ainda é essencialmente o mesmo critério que usamos até hoje, tendo acumulado centenas de projetos desenvolvidos usando essa metodologia e anos de informações históricas disponíveis em cada equipe.
Embora a dispersão entre as horas estimadas e realizadas em cada Feature seja bastante grande, a soma desses erros (para mais e para menos) nas Features em cada Projeto também gera uma dispersão entre o total planejado e o realizado para cada projeto, mas bem menor.
Da mesma forma, ao somar a dispersão entre os diferentes projetos conduzidos em paralelo para a entrega de um Release, o erro total também é menor e a aplicação sistemática desses conceitos permite que o nosso planejamento de Produto seja conduzido com um grau bastante elevado de previsibilidade (considerando as incertezas que temos na nossa área). 
Desenvolvimento colaborativo
No início de 2009, nos preparávamos para iniciar o desenvolvimento de uma nova versão do Eberick. O processo de desenvolvimento a ser adotado havia sido concebido e uma ferramenta para gerenciamento dos projetos havia sido customizada e implantada, suportando o processo definido.
O escopo do produto estava sendo selecionado pelo DPS, dentre uma lista de cerca de 300 sugestões reportadas pelos clientes ao longo dos últimos anos. Sabíamos que havia tempo e equipe disponível para atender apenas a uma pequena parte dessa demanda.
O foco desse projeto, definido pela Direção da empresa, deveria ser o de fornecer aos clientes recursos que maximizassem a sua produtividade e melhorassem a sua experiência com o produto.
Partindo dessa definição bastante abrangente, era esperado um ciclo de desenvolvimento de 18 a 24 meses. Como a última versão do produto havia sido lançada havia mais de dois anos, o ciclo total superaria os quatro anos, uma demora que vinha sido percebida pelos clientes.
Esperar o final do projeto para fazer a sua divulgação, como havia sido feito nos lançamentos anteriores, poderia causar uma evasão expressiva da base de clientes.
Nesse cenário, a empresa resolveu aplicar o conceito do desenvolvimento iterativo, concebido apenas para controlar internamente o andamento dos projetos e para definir o produto junto aos seus clientes.
Para isso, foi criado o programa AltoQi Eberick Next, um conjunto de 8 Releases, com duração de 2 a 3 meses cada. O conjunto desses projetos tinha por objetivo a criação da nova versão do AltoQi Eberick, através de um modelo de planejamento progressivo.
Foi definido, apenas em alto nível, o escopo do produto completo. Foi planejado o primeiro Release, contendo os recursos considerados mais prioritários pela equipe, e pré-definido o escopo do Release 2 mas, para os demais, ainda seria aguardado o retorno dos clientes. 
Cada um desses Releases deveria ser concebido como um projeto independente, ao final do qual deveria existir um Produto parcial completamente estabilizado, que poderia ser enviado para a base de usuários participantes do programa Eberick Next.
Cada cliente participante poderia receber as versões intermediárias do produto e aplicá-las imediatamente nos seus projetos, sem as restrições de uma versão “beta”. Essa proposta, evidentemente, só foi viabilizada pelo investimento que tínhamos feito sobre os testes automatizados.
Eberick Next
Além da liberação de versões intermediárias do produto, a empresa decidiu criar um ambiente de colaboração com seus usuários, na forma de um blog de desenvolvimento, o Blog Eberick Next.
Nesse blog, eram publicados os recursos do projeto, conforme eram desenvolvidos, permitindo o feedback dos clientes mesmo antes do fechamento do Release. Isso permitia discutir com os usuários os critérios adotados e coletar opiniões a respeito de recursos que estavam planejados para os próximos releases. 
No período de abril de 2009 a novembro de 2010, o Blog do Eberick Next teve 150 posts publicados, os quais foram acompanhados por 826 profissionais registrados. Foram mais de 72 mil visualizações e 5.600 comentários, todos tratados pela equipe de desenvolvimento do produto. 
Ao final, mais importante do que demonstrar a aplicação dos conceitos do desenvolvimento iterativo para a Direção da empresa, com o feedback positivo dos clientes participantes dessa iniciativa, foi o resultado comercial obtido pelo produto.
Após completar os oito Releases, o produto foi oficialmente fechado como “AltoQi Eberick V7” e lançado comercialmente a toda a base de clientes da empresa. Dos 826 profissionais que participaram, mais de 600 efetuaram imediatamente a migração para a versão V7. Outros 220 profissionais que não participaram do projeto Next também adquiriram a licença no lançamento, apenas pelo histórico desse projeto. 
Avaliação MPS.BR
O projeto Eberick Next teve como foco a preocupação da empresa pela melhoria dos produtos e serviços oferecidos. Como apoio à melhoria interna do processo de desenvolvimento, a empresa optou por alinhar essa iniciativa com um modelo destinado especificamente ao mercado de desenvolvimento de software brasileiro, o MPS.BR (modelo de Melhoria de Processos de Software Brasileiro), baseado nas normas NBR ISO/IEC 12207, ISO/IEC 15504 e no modelo internacional de melhoria de processos de software CMMI-DEV, com o objetivo de guiar a melhoria dos processos das micro, pequenas e médias empresas do mercado de software brasileiro.
O modelo MPS.BR define sete níveis de maturidade de processos:
- (em otimização);
- (gerenciado quantitativamente);
- (definido);
- (largamente definido);
- (parcialmente definido);
- (gerenciado); e
- (parcialmente gerenciado).
A escala de maturidade se inicia no nível G e progride até o nível A. Em cada um dos níveis, há um conjunto de processos que indicam onde deve ser feito o esforço de melhoria.
Os níveis são cumulativos, o que significa dizer que uma organização aprovada no nível F possui as capacidades de ambos os níveis F e G (ver Figura 11).
Vínhamos trabalhando na melhoria de processos desde 2007, até chegar ao modelo de desenvolvimento iterativo em 2009, que ganhou destaque com o Blog do Eberick Next. A formalização desses procedimentos foi uma necessidade que a empresa observou no caminho de ampliação da sua equipe e fortalecimento do Departamento.
No final de 2009, usando como piloto o próprio projeto Next, resolvemos buscar essa certificação de qualidade, validando o investimento que havia sido feito e visando posicionar a empresa no início dessa jornada em direção à excelência.
O primeiro passo foi a implantação do nível G do MPS.BR, o qual envolve as áreas de Gerência de Projetos e Gerência de Requisitos. Esse trabalho transcorreu durante um ano e culminou em uma avaliação impecável, ao final de 2010.
O sucesso nessa avaliação vem trazendo diversos benefícios à empresa, mas o atendimento às melhores práticas do desenvolvimento de software é o principal fator a ser considerado, resultando em projetos mais eficientes e organizados, com benefícios diretos para os usuários dos produtos AltoQi.
Conclusões
Na área de desenvolvimento de software, muitos são os fatores que determinam o sucesso de um empreendimento. Certamente, sem a inspiração para a criação de um produto ou serviço diferenciado, ou sem contar com as pessoas adequadas e motivadas para o desenvolvimento do produto, não é provável que a empresa possa colher bons resultados. Mesmo o melhor dos processos não garantiria o sucesso dos projetos. Por outro lado, a adoção de um processo inadequado pode, certamente, minar a produtividade de uma equipe, desviá-la dos objetivos do negócio e reduzir a moral da empresa como um todo.
Neste artigo, procurei mostrar como a aplicação de uma metodologia de desenvolvimento bem estruturada permitiu à AltoQi retomar o seu ritmo de crescimento e estabelecer uma nova forma de interação com seus usuários. Para que isso fosse possível, um investimento inicial na adoção de boas práticas de Engenharia de Software, com destaque para a automação dos testes, foi imprescindível.
Na próxima parte, contarei um pouco sobre esse crescimento e sobre o produto que foi o resultado dessa nova fase da AltoQi: o QiBuilder.
