Quando cheguei na Lambda3, me deparei com uma grande novidade: A disciplina de ALM. Eu já tinha conhecimento das práticas e já usava várias ferramentas, mas até então não sabia que havia empresas que possuem áreas inteiras dedicadas somente à fazer isso. Descobri que isso é muito comum, especialmente falando em tecnologia Microsoft, que possui uma solução completa para te ajudar nisso, o TFS (Team Foundation Server). Creio que meu estranhamento com esse fato ocorreu por dois motivos:

• a minha vivência desenvolvendo software com tecnologias não Microsoft – Java, Scala e Ruby;
• ter trabalhado em empresas que não possuem um departamento de TI muito grande, de modo que cuidar da saúde do projeto sempre foi parte do meu trabalho diretamente.

Pois bem. Surgiu um cliente com a necessidade de melhorar a forma de gerenciar seus projetos, e para encurtar a história a Lambda foi chamada para instalar o TFS. Até aí, nenhuma novidade – exceto uma: os projetos são todos Java. É possível colocar seus projetos Java no TFS e administrá-los por ele, podendo fazer build, deploy, controle de acesso e tudo o mais. Para isso, você só precisa que os projetos tenham scripts de Ant ou Maven, e tudo funciona perfeitamente bem. É aí que eu entro na história.

Como eu já estava interessado em participar de consultorias para desenvolver outras habilidades além das técnicas, fiquei com o trabalho. Qual poderia ser a dificuldade de escrever alguns scripts de build?

No meu primeiro dia no cliente, entendi que era um mundo completamente diferente: o cliente não desenvolve nada, tudo é terceirizado. Para fazer build e deploy, há uma série de scripts bash que fazem de tudo, como baixar o código de uma dada branch no cvs, compilar, empacotar e por aí vai. Mas o pior ainda estava por vir: cada fornecedor cria quantas branches quiser do projeto no qual está trabalhando, além de uma para cada uma de suas dependências, conforme necessário. Nesse momento, escrever os scripts era o de menos. Eu não conseguia ver qual era a diferença entre ter ou não uma ferramenta, dada a confusão na qual o cliente estava trabalhando.

Falando sobre a minha parte do trabalho, meu primeiro grande problema foi o seguinte: Temos o Projeto P1, que possui as dependências D1 e D2. Aí temos também o projeto P2, que possui a sua prórpia versão das dependências D1 e D2. Isso impossibilita o cliente de adotar Maven para esse tipo de projeto, já que ele precisa fazer o merge de todas as inúmeras versões das dependências dentre os projetos (e são muitos). A solução foi criar uma branch principal para cada projeto, onde estarão presentes também suas dependências. O problema ainda existe, mas essa ação vai garantir que ele não continue aumentando, enquanto o cliente terá tempo de fazer o merge que levará à solução ideal.

Para chegar nessa solução, precisei entender todo o contexto hoje, onde querem chegar e o mais importante, todas as limitações. Eu já tinha esquecido como é trabalhar em outro ambiente, ainda mais um ambiente de uma mega empresa com inúmeras restrições, e confesso que passei uns 2 dias me batendo com essa situação. Após esses 2 dias, entendi como eu devia ajudar meu cliente.

Essa consultoria resultou no estabelecimento de diretivas, regras e restrições dentro do TFS que permitem que agora nosso cliente:

• tenha grupos de controle por area
• saiba quem está cuidando de cada demanda
• garanta que as alterações em um projeto sejam necessariamente ligadas a uma demanda, acabando com as solicitações “por fora” que tanto o atrapalhava
• defina a branch em que seu fornecedor vai trabalhar, acabando com os problemas de merge que existiam até então

Entre outras coisas que vão lhe conceder o controle de seus inúmeros projetos.

Os costumes que você adquire trabalhando em uma empresa ágil podem tornar sua visão um tanto “cega”. Enquanto você se preocupa com melhoria contínua, pode se esquecer que outras empresas possuem problemas totalmente diferentes, que você não possui e essa consultoria serviu para me ensinar isso. Hoje está claro para mim que instalar a ferramenta trouxe um ganho enorme para nosso cliente, o qual está satisfeito com o controle que conseguimos trazer pra ele (e que ele já deve desejar faz um bom tempo). E felizmente, em minhas primeiras impressões, eu estava errado! 🙂

Juliano Alves

Juliano Alves é formado em Ciência da Computação e Especializado em Engenharia de Software pela PUC-SP e considera desenvolvimento de software uma arte. Trabalha com desenvolvimento a 6 anos, focado em métodos ágeis, possuindo experiência com Java, Scala, Ruby e Python, falando sobre elas no twitter @vonjuliano de vez em quando. Contribuinte do framework opensource Mirror, criado para simplificar o uso de reflection e commiter do VidaGeek Games, uma plataforma que mistura prática deliberada e Gamefication para ensino. Hoje trabalha na Lambda3, empresa envolvida no meio ágil desde que foi criada.