,
4 min de leitura
O conhecimento é valioso, mas o seu verdadeiro poder reside na forma como o colocamos em prática. Na Freyr Digital, estávamos familiarizados com o DevOps, as suas práticas associadas, e como poderia transformar a nossa organização numa potência de desenvolvimento de produtos de alto desempenho, capaz de entregar produtos e soluções de qualidade aos nossos clientes das ciências da vida. Ao iniciarmos a nossa jornada, os nossos esforços lançaram 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 conhecimento em ação reside em saber quando dar os passos certos. Uma vez que as ações impactam muitas pessoas numa organização, fazer a coisa certa no momento certo depende de onde estamos 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. Como um portefólio de fornecedores de software especializados em soluções personalizadas, tínhamos uma equipa dedicada que se esforçava ao máximo 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 entregáveis. Em vez de nos concentrarmos 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 — 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 para hoje: no último ano, fizemos mais de 100 lançamentos com quase zero falhas de implementação e alcançámos uma automação quase total na implementação de alterações. Além disso, vimos um progresso significativo nas receitas, equipas mais enxutas e ágeis, e uma mudança geral em direção à nossa visão de nos tornarmos uma potência em produtos, soluções e serviços de software. Embora haja sempre mais a alcançar, estamos confiantes de que lançámos uma base sólida e estamos prontos para acelerar.
À medida que avançamos, estamos a tirar um momento para refletir sobre a nossa transformação — o que funcionou, o que não funcionou e as lições que aprendemos. Ao partilhar a nossa jornada, esperamos apoiar outros que estejam a navegar por mudanças semelhantes.
Esta série de blogues é principalmente empírica, partilhando o que fizemos, ao mesmo tempo que conectamos 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 chave 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 altamente interligadas, com mudanças numa a impactar as outras. No entanto, foi possível fazer mudanças incrementais em cada categoria e medir o progresso em direção aos nossos objetivos gerais.
As iniciativas nestas categorias dependiam frequentemente umas das outras. Mudanças numa área abriam possibilidades para melhorias adicionais noutra.
Os Primeiros Passos
Para estabelecer uma base sólida, focámo-nos em três iniciativas principais:
- Integrar as nossas bases de código fonte com SonarQube para métricas de qualidade de código.
- Mover todas as equipas para uma ferramenta comum para gerir requisitos, código fonte e planos de teste — no nosso caso, Azure DevOps.
- Estruturar equipas com responsabilidades claras para aumentar a apropriação e a responsabilização.
Estas três iniciativas deram-nos visibilidade sobre:
- O trabalho que está a ser feito (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 desafiador. Inicialmente, as estruturas das equipas eram fluidas, com as pessoas a moverem-se entre projetos conforme necessário. A transição para equipas dedicadas com áreas funcionais distintas foi um passo necessário, embora complicada pela nossa arquitetura de produto existente, que não foi totalmente projetada 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 um sentido de responsabilidade nas equipas tiveram um impacto limitado.
Reestruturar a arquitetura do nosso portefólio foi um processo complexo. Incluiu a migração total para a nuvem e o início da construção de aplicações nativas da nuvem usando uma arquitetura de microsserviços. Este tópico será abordado numa publicação futura. A principal conclusão, no entanto, é que as mudanças são incrementais, e alguns passos devem preceder outros para desbloquear benefícios e progredir ainda mais.
Métricas e Melhoria Contínua
Após iniciar o trabalho de reestruturação da arquitetura (um esforço contínuo), mudá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 débito de funcionalidades para equipas individuais.
- Adoção de serviços nativos da nuvem.
Estes objetivos não eram mandatos rígidos, mas objetivos orientadores para ajudar as equipas a alinhar os seus esforços.
Capacitar Pessoas
Com as métricas implementadas, tornou-se evidente que as equipas precisavam de apoio para alcançar estes objetivos. Por exemplo, embora definir objetivos para a cobertura de testes unitários e a automação de testes de API fosse simples, alcançá-los era desafiador, especialmente para código legado que não tinha sido projetado para testabilidade.
Para resolver isto, nós:
- Definimos objetivos mais baixos para código legado.
- Organizamos workshops e formação prática sobre como escrever testes unitários de qualidade e projetar código testável.
- Fornecemos orientação sobre a construção de stubs para testes de API.
- Realizámos 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 de repositórios. A integração com o SonarQube, que representa uma melhoria nas ferramentas, revelou uma baixa cobertura de testes unitários, o que indicava problemas arquitetónicos que limitavam a testabilidade. Melhorias na arquitetura e nas competências da equipa levaram a testes unitários de melhor qualidade, mas estes não estavam a ser executados regularmente devido a práticas de ramificação deficientes. Resolvemos isto padronizando as estratégias de ramificação e garantindo a integração regular do código no ramo principal, permitindo que os pipelines de CI executassem todos os testes.
A Sequência Certa da Mudança
Uma abordagem à transformação é implementar as melhores práticas indiscriminadamente. Embora isto possa trazer benefícios, os resultados muitas vezes não justificam o esforço, levando à frustração.
Seguimos uma abordagem diferente, baseada no princípio de fluxo: analisar o processo End-to-End, identificar estrangulamentos e abordá-los de forma incremental.
Cada melhoria revelava novos estrangulamentos, exigindo ações adicionais. Isto não era um jogo de 'whack-a-mole', mas 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 ao 'teatro de cobertura' (testes superficiais escritos 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 trata de uma única grande mudança, mas sim de decisões inteligentes e oportunas que impulsionam o progresso contínuo. Estamos entusiasmados por partilhar a nossa jornada e os nossos conhecimentos para ajudar outros a navegar no seu próprio caminho para uma mudança escalável e de alto impacto.
Nos próximos blogues desta série – DevOps for the Win –, detalharemos cada fase da nossa transformação no Triângulo DevOps – Ferramentas, Arquitetura e Pessoas – que nos ajudou a alcançar um impacto duradouro.
