Quando o ágil tem o poder

A presença de profissionais com mindset ágil, com conhecimento técnico, imersos no processo de desenvolvimento e dispostos a sujar as mãos, tem o poder de criar um ambiente onde soluções são pensadas, construídas e entregues com o mínimo de atrito.

Quando se fala das funções dentro de um time de desenvolvimento de software, os seguintes papéis recebem muita atenção atualmente e possuem responsabilidades bem específicas:

• Software Engineer:  Desenvolve os sistemas/produtos vendidos por suas empresas, estão presentes no core do processo de desenvolvimento de software e são os primeiros a sentir os efeitos de gargalos dentro desse processo.
• Agile Coach: Possui o mindset ágil capaz de identificar gargalos  no processo de desenvolvimento e de sugerir abordagens de modo a gerar mais valor ao produto e melhorias nos processos através de constante inspeção, adaptação e transparência, como um Scrum Master, por exemplo.
• DevOps: Desenvolve e disponibiliza ferramentas de automação e infraestrutura necessários aos trabalhos dos dois acima, visando a melhoria nos processos internos e a garantia de que o produto será entregue com velocidade, alta disponibilidade, segurança e escalabilidade. Pode-se dizer que Software Engineers também se enquadram nesse papel quando se envolvem em atividades de Operações.

Mas, e se um gargalo for identificado? Uma melhoria nos processos internos for sugerida? Ou uma nova alternativa para deploys surgir? Qual a chance do desenvolvimento dessa melhoria não precisar envolver toda a equipe? Quantos profissionais você conhece que poderiam ir desde a detecção do problema, proposta da solução, desenvolvimento até a  entrega? Para ilustrar, temos um caso que aconteceu na M2Agro recentemente e que já gerou resultados:

O PROBLEMA:

Uma das etapas de nosso processo de desenvolvimento é chamada de review, a qual é responsável por se certificar que uma nova feature, sendo entregue, atenda a nossa DoD (Definition of Done), garantindo que a nova funcionalidade está pronta para ser liberada para produção. Porém, nós não tínhamos uma maneira fácil de disponibilizar vários ambientes de homologação simultâneos e independentes por feature, sendo necessário que o revisor configure o ambiente de homologação em sua própria máquina local. Essa abordagem de revisão, portanto, traz alguns problemas que prejudicam nosso processo de desenvolvimento:

• Os revisores são obrigados a possuir conhecimento mínimo em Python/Django, Git e Linux para conseguir montar seu ambiente de homologação;
• O ambiente de homologação precisa ser montado nas máquinas locais dos revisores, o que demanda tempo e recurso;
• Em geral, os revisores são os próprios desenvolvedores que precisam parar suas atividades para poder montar esse ambiente de homologação;
• UX designers e gerentes de produto seriam úteis mas não conseguem atuar como revisores por não conseguirem montar ambientes de homologação em suas máquinas locais.

Além disso, não temos em nossa equipe um especialista em virtualização e infraestrutura, especificamente em Docker, Kubernetes e Cloud, o que aumenta a dificuldade em utilizar essas tecnologias a nosso favor.

A SOLUÇÃO:

Nosso sistema é composto por três Apps independentes que se comunicam via HTTP e, que são acessíveis por três servidores web. Sendo assim, criamos um framework que disponibiliza ambientes remotos de homologação, cada qual com esses três Apps se comunicando e disponibilizando nossa ferramenta 100% funcional. Durante o desenvolvimento desse framework, foi necessário:

• Configurar servidores web no Ubuntu para servir aplicaçôes Python utilizando Nginx e uWSGI;
• Criar dockerfiles para gerar imagens Docker contendo o código da feature a ser testada e os servidores mencionados acima já configurados;
• Configurar repositório privado para imagens Docker;
• Configurar ambiente Kubernetes para o deploy das imagens Docker geradas acima;
• Criar scripts para automatizar a build das imagens Docker, upload para repositório e deploy no Kubernetes.

Esse framework possibilitou que qualquer desenvolvedor conseguisse disponibilizar suas features para testes, agilizando o nosso fluxo de desenvolvimento e possibilitando que qualquer membro da equipe fosse capaz de validá-las.

PRÓXIMOS PASSOS:

Uma das limitações que temos hoje é o isolamento do banco de dados por feature. Para isso, precisamos ter uma certa orquestração entre a equipe sobre qual banco de dados um ambiente deverá usar caso hajam migrações na feature sendo testada. Sendo assim, também pretendemos automatizar a criação/deleção de novos bancos de dados  por ambiente.

Um outro passo será automatizar a execução desses scripts utilizando ferramentas como Jenkins, para não mais necessitar que desenvolvedores disponibilizem os servidores de homologação manualmente.

CONCLUSÃO:

Apesar do fluxo criado ser intuitivo e já utilizado no mercado, minha atenção na escrita desse artigo está longe de estar no artefato gerado, mas na trajetória que envolveu sua concepção, desenvolvimento e encaixe final no nosso processo.

Muito é dito sobre Agile Coaches e sobre a capacidade que seu conhecimento tem de transformar o mindset de uma empresa. No entanto, se esse conhecimento se restringe ao seu mindset, frameworks e dinâmicas, o seu poder de ação se torna muito genérico e não consegue atingir profundamente os processos da organização, principalmente quando se trata de processos que envolvem conhecimento técnico.

Mais especificamente no nosso setor de tecnologia, a presença de profissionais com skills que abrangem toda a cadeia de valor no desenvolvimento de software e, que se engajam em todos os processos, é capaz de alavancar a liberação de novas funcionalidades bem como automatizar processos repetitivos nos diversos setores da empresa com o mínimo de atrito.

Se você já teve alguma experiência semelhante em que, mesmo envolvido ativamente no processo ágil de sua equipe, precisou desenvolver alguma solução com tecnologia com o objetivo de melhorar os processos do seu time, deixe um comentário e nos conte como foi. Também gostaria de sugestões de temas para novos artigos caso haja interesse em saber mais detalhadamente como foram efetuados os passos que nos levaram a construir nossa solução.