4 min ler
O conhecimento é valioso, mas o seu verdadeiro poder reside na forma como o colocamos em prática. Na Freyr , estávamos familiarizados com o DevOps, as suas práticas associadas e como ele 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 da área das ciências da vida. Quando iniciámos a nossa jornada, 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 adaptável.
O principal desafio na tradução do conhecimento em ação consiste em saber quando dar os passos certos. Uma vez que as acções têm impacto em muitas pessoas numa organização, fazer a coisa certa no momento certo depende do ponto em que nos encontramos enquanto organização, dos nossos processos e práticas actuais e das competências e capacidades dos nossos colaboradores.
Isto marcou um ponto de viragem na nossa transformação. Como uma carteira de fornecedores de software especializados em soluções personalizadas, tínhamos uma equipa dedicada que se esforçava ao máximo para obter resultados. No entanto, vimos uma oportunidade para melhorar a qualidade, aumentar a produtividade e acelerar a conversão dos requisitos comerciais em resultados. Em vez de nos concentrarmos em correcções de última hora, o nosso objetivo era passar da resolução reactiva de problemas para a inovação proactiva, criando soluções escaláveis e de elevado 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 para atingir esses objectivos era necessária uma estratégia ponderada, uma 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 automatização quase total na implementação de alterações. Além disso, assistimos a um progresso significativo nas receitas, a equipas mais ágeis e mais simples e a uma mudança geral no sentido da nossa visão de nos tornarmos uma potência em produtos, soluções e serviços de software. Embora haja sempre mais para alcançar, estamos confiantes de que estabelecemos uma base sólida e estamos prontos para acelerar.
À medida que avançamos, estamos a reservar um momento para refletir sobre a nossa transformação - o que funcionou, o que não funcionou e as lições que aprendemos. Ao partilharmos o nosso percurso, esperamos apoiar outras pessoas que estejam a passar por mudanças semelhantes.
Esta série de blogues é sobretudo empírica, partilhando o que fizemos, ao mesmo tempo que relaciona as nossas acções com as melhores práticas e recomendações de vários recursos DevOps e Agile.
Fazer a coisa certa na altura certa
Um dos principais aspectos da nossa transformação foi identificar as acções certas no momento certo. Com várias iniciativas possíveis, precisávamos de uma abordagem estruturada para garantir um progresso significativo.
Olhando para trás, podemos agrupar estas acções em três categorias: Ferramentas e Processos, Arquitetura de Software e Pessoas. Estas categorias estão altamente interligadas, com as alterações numa delas a afetar as outras. No entanto, foi possível fazer alterações incrementais em cada categoria e medir o progresso em direção aos nossos objectivos gerais.
As iniciativas nestas categorias dependem frequentemente umas das outras. As mudanças num domínio abriram a possibilidade de novas melhorias noutro domínio.
Os primeiros passos
Para estabelecer uma base sólida, concentrámo-nos em três iniciativas fundamentais:
- Integrar as nossas bases de código-fonte com o SonarQube para medir a qualidade do código.
- Transferir 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 reforçar a apropriação e a responsabilização.
Essas três iniciativas us deram us sobre:
- O trabalho que está a ser realizado (requisitos e tarefas).
- A qualidade do código (métricas SonarQube).
- As pessoas envolvidas (responsabilidades da equipa).
Entre estas, a definição clara das responsabilidades da equipa foi a mais difícil. Inicialmente, as estruturas das equipas eram fluidas, com as pessoas a transitarem entre projectos 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 foi totalmente concebida para suportar uma responsabilidade clara.
O papel da arquitetura de software
Rapidamente nos apercebemos que a arquitetura do produto era uma das áreas mais críticas para a mudança. Uma arquitetura modular era essencial para permitir que as equipas independentes assumissem a responsabilidade pelo seu trabalho. Sem isso, o impacto dos nossos esforços para criar a propriedade da equipa era limitado.
Re-arquitetar o nosso portfólio foi um processo complexo. Incluiu a mudança total para a nuvem e o início da criação de aplicações nativas da nuvem utilizando 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 algumas etapas devem preceder outras para desbloquear os benefícios e o progresso.
Métricas e melhoria contínua
Depois de começarmos a trabalhar na re-arquitetura (um esforço contínuo), mudámos a nossa atenção para a monitorização das métricas e a definição de objectivos:
- 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 recursos para equipas individuais.
- Adoção de serviços nativos da nuvem.
Estas metas não eram mandatos rígidos, mas sim objectivos orientadores para ajudar as equipas a alinhar os seus esforços.
Capacitar as pessoas
Com as métricas implementadas, tornou-se evidente que as equipas precisavam de apoio para atingir estes objectivos. Por exemplo, embora a definição de objectivos para a cobertura de testes unitários e a automatização de testes de API fosse simples, atingi-los era um desafio, especialmente para o código antigo que não tinha sido concebido para ser testado.
Para resolver este problema, nós:
- Definir objectivos mais baixos para o código herdado.
- Organizou workshops e formação prática sobre a escrita de testes unitários de qualidade e a conceção de código testável.
- Forneceu orientação sobre a criação de stubs para testes de API.
- Realização de revisões de testes unitários por arquitectos seniores.
O triângulo ferramentas, arquitetura e pessoas
Um bom exemplo da interação entre estas categorias foi a gestão do código e do repositório. A integração com o SonarQube, que é uma melhoria nas ferramentas, revelou uma baixa cobertura dos testes unitários, o que apontava para problemas de arquitetura 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. Resolvemos isso padronizando as estratégias de ramificação e garantindo a integração regular do código na ramificação principal, permitindo que os pipelines de CI executassem todos os testes.
A sequência correta da mudança
Uma das abordagens à transformação é a implementação indiscriminada das melhores práticas. Embora isso 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 do fluxo: analisar o processo de ponta a ponta, identificar os estrangulamentos e resolvê-los de forma progressiva.
Cada melhoria revelou novos estrangulamentos, exigindo novas acções. Não se tratou de um jogo de "whack-a-mole", mas de um processo deliberado de fazer a coisa certa no momento certo.
Por exemplo, obrigar a cobertura de testes unitários sem melhorar o design do código teria levado à frustração e ao "teatro da cobertura" (testes superficiais escritos para cumprir métricas). Ao abordar primeiro a arquitetura e as competências, garantimos um progresso significativo.
Olhando para o futuro
A verdadeira transformação não tem a ver com uma única grande mudança - tem a ver com decisões inteligentes e oportunas que impulsionam o progresso contínuo. Estamos entusiasmados por partilhar o nosso percurso e os nossos conhecimentos para ajudar os outros a percorrer o seu próprio caminho para uma mudança escalável e de grande impacto.
Nos próximos blogs desta série - DevOps para o sucesso, iremos detalhar cada fase da nossa transformação no Triângulo DevOps - Ferramentas, Arquitetura e Pessoas - que us ajudou us um impacto duradouro.
