4 min de leitura
O conhecimento é valioso, mas o seu verdadeiro poder reside na forma como o colocamos em prática. Na Freyr Digital, conhecíamos bem o DevOps, as suas práticas associadas e a forma como este poderia transformar a nossa organização numa potência de desenvolvimento de produtos de alto desempenho, capaz de fornecer produtos e soluções de qualidade aos nossos clientes das ciências da vida. Ao iniciarmos o nosso percurso, os nossos esforços estabeleceram uma base sólida, mas, para nos tornarmos verdadeiramente uma potência de desenvolvimento, sabíamos que precisávamos de adotar uma abordagem mais estratégica e adaptativa.
O principal desafio em transformar o conhecimento em ação reside em saber quando dar os passos certos. Uma vez que as ações afetam muitas pessoas numa organização, fazer a coisa certa no momento certo depende de onde nos encontramos como organização, dos nossos processos e práticas atuais, e das competências e capacidades das nossas pessoas.
Isto marcou um ponto de viragem na nossa transformação. Sendo um portefólio de fornecedores de software especializados em soluções personalizadas, tínhamos uma equipa dedicada que ia mais além para entregar resultados. No entanto, vimos uma oportunidade para melhorar a qualidade, aumentar a produtividade e acelerar a conversão dos requisitos de negócio em entregas. Em vez de nos focarmos em correções de última hora, o nosso objetivo era passar da resolução reativa de problemas para a inovação proativa, construindo soluções escaláveis e de alto impacto.
Tínhamos uma visão de onde queríamos estar — de como queríamos trabalhar, desenvolver, testar, implementar e lançar software. No entanto, sabíamos que alcançar esses objetivos exigia uma estratégia ponderada, aprendizagem contínua e um compromisso com a melhoria.
Avançando rapidamente para o presente: no último ano, efetuámos mais de 100 lançamentos com falhas de implementação quase nulas e alcançámos uma automação quase total na implementação de alterações. Além disso, registámos progressos significativos nas receitas, equipas mais enxutas e ágeis, e uma mudança global em direção à nossa visão de nos tornarmos uma referência em produtos, soluções e serviços de software. Embora haja sempre mais por alcançar, estamos confiantes de que estabelecemos uma base sólida e estamos prontos para acelerar.
À medida que avançamos, dedicamos um momento a refletir sobre a nossa transformação — o que funcionou, o que não funcionou e as lições que aprendemos. Ao partilhar o nosso percurso, esperamos apoiar outros que navegam por mudanças semelhantes.
Esta série de blogues é essencialmente empírica, partilhando o que fizemos, ao mesmo tempo que liga as nossas ações às melhores práticas e recomendações de vários recursos DevOps e Agile.
Fazer a Coisa Certa no Momento Certo
Um dos aspetos fundamentais da nossa transformação foi identificar as ações certas no momento certo. Com múltiplas iniciativas possíveis, precisávamos de uma abordagem estruturada para garantir um progresso significativo.
Olhando para trás, podemos agrupar estas ações em três categorias: Ferramentas e Processos, Arquitetura de Software e Pessoas. Estas categorias estão profundamente interligadas, sendo que as alterações numa afetam as outras. No entanto, foi possível fazer alterações de forma incremental em cada categoria e medir o progresso rumo aos nossos objetivos gerais.
As iniciativas nestas categorias dependiam frequentemente umas das outras. As alterações numa área abriam possibilidades para mais melhorias noutra.
Os Primeiros Passos
Para estabelecer uma base sólida, concentrámo-nos em três iniciativas principais:
- Integrar as nossas bases de código-fonte com o SonarQube para obter métricas de qualidade de código.
- Transacionar todas as equipas para uma ferramenta comum de gestão de requisitos, código-fonte e planos de teste — no nosso caso, o Azure DevOps.
- Estruturar equipas com responsabilidades claras para melhorar a apropriação e a responsabilização.
Estas três iniciativas deram-nos visibilidade sobre:
- O trabalho a ser realizado (requisitos e tarefas).
- A qualidade do código (métricas do SonarQube).
- As pessoas envolvidas (responsabilidades da equipa).
Entre estes, definir responsabilidades claras para as equipas foi o mais desafiante. Inicialmente, as estruturas das equipas eram fluidas, com pessoas a transitar entre projetos conforme necessário. A transição para equipas dedicadas com áreas funcionais distintas foi um passo necessário, embora complicado pela nossa arquitetura de produto existente, que não estava totalmente desenhada para suportar uma apropriação clara.
O Papel da Arquitetura de Software
Percebemos rapidamente que a arquitetura do produto era uma das áreas mais críticas para a mudança. Uma arquitetura modular era essencial para permitir que equipas independentes assumissem a responsabilidade pelo seu trabalho. Sem isto, os nossos esforços para criar a apropriação por parte das equipas teriam um impacto limitado.
Reestruturar a arquitetura do nosso portefólio foi um processo complexo. Incluiu a transição total para a cloud e o início da construção de aplicações nativas da cloud utilizando uma arquitetura de microsserviços. Este tópico será abordado numa publicação futura. A principal conclusão, no entanto, é que as alterações são incrementais e alguns passos devem preceder outros para desbloquear benefícios e novos progressos.
Métricas e Melhoria Contínua
Após iniciar o trabalho de rearquitetura (um esforço contínuo), redirecionámos o nosso foco para monitorizar métricas e definir objetivos:
- Métricas de qualidade de código no SonarQube.
- Métricas de integração de código no Azure DevOps.
- Métricas de rendimento de funcionalidades para equipas individuais.
- Adoção de serviços nativos da cloud.
Estes objetivos não eram obrigações rígidas, mas sim metas orientadoras para ajudar as equipas a alinhar os seus esforços.
Valorizar as Pessoas
Com as métricas estabelecidas, tornou-se evidente que as equipas precisavam de apoio para alcançar estes objetivos. Por exemplo, embora a definição de metas para a cobertura de testes unitários e automação de testes de API fosse simples, alcançá-las foi desafiante, especialmente para código legado que não tinha sido concebido para ser testável.
Para resolver isto, nós:
- Definimos metas inferiores para código legado.
- Organizámos workshops e formação prática sobre como escrever testes unitários de qualidade e desenhar código testável.
- Fornecemos orientações sobre a construção de stubs para testes de API.
- Realizamos revisões de testes unitários por arquitetos seniores.
O Triângulo de Ferramentas, Arquitetura e Pessoas
Um bom exemplo da interação entre estas categorias foi a gestão de código e repositórios. A integração com o SonarQube, que constitui uma melhoria ao nível das ferramentas, revelou uma baixa cobertura de testes unitários, o que apontava para problemas arquitetónicos que limitavam a testabilidade. As melhorias na arquitetura e nas competências da equipa conduziram a testes unitários de melhor qualidade, mas estes não estavam a ser executados regularmente devido a práticas de ramificação deficientes. Abordámos esta questão através da padronização das estratégias de ramificação e da garantia da integração regular de código na ramificação principal, permitindo que os pipelines de CI executassem todos os testes.
A Sequência Certa de Mudança
Uma abordagem à transformação consiste em implementar as melhores práticas de forma indiscriminada. Embora isto possa trazer benefícios, os resultados muitas vezes não justificam o esforço, gerando frustração.
Seguimos uma abordagem diferente, baseada no princípio do fluxo: analisar o processo End-to-End, identificar estrangulamentos e resolvê-los de forma incremental.
Cada melhoria revelou novos estrangulamentos, exigindo mais ações. Não se tratava de um jogo de acentuação aleatória, mas sim de um processo deliberado de fazer a coisa certa no momento certo.
Por exemplo, exigir a cobertura de testes unitários sem melhorar o design do código teria levado à frustração e a "teatro de cobertura" (testes superficiais escritos apenas para cumprir métricas). Ao abordar primeiro a arquitetura e as competências, garantimos um progresso significativo.
Perspetivas futuras
A verdadeira transformação não se resume a uma única grande mudança; trata-se de decisões inteligentes e oportunas que impulsionam o progresso contínuo. Estamos entusiasmados por partilhar o nosso percurso e perspetivas para ajudar outros a navegar no seu próprio caminho rumo a uma mudança escalável e de alto impacto.
Nos futuros blogs desta série - DevOps para o Sucesso, vamos detalhar cada fase da nossa transformação no Triângulo DevOps - Ferramentas, Arquitetura e Pessoas - ajudando-nos a alcançar um impacto duradouro.
