- Compartilhamento de casos de aplicação eficaz dos conceitos de DevOps, staff engineering e platform engineering no ambiente de startups
- O palestrante Chad McElligott é Senior Staff Engineer na Smartrr, empresa que oferece serviços de assinatura e fidelidade baseados em Shopify
- Proposta de metodologias de engenharia adaptadas à cultura e às necessidades específicas de startups
[Conceitos centrais]
DevOps
- A definição de DevOps varia de pessoa para pessoa; para alguns é um cargo, para outros é uma forma de trabalhar
- O conceito de "DevOps as No Ops" faz com que engenheiros de software assumam por conta própria todas as tarefas relacionadas a Ops
- DevOps é uma mentalidade de colaboração, automação de trabalho repetitivo e manual (toil) e uso de ferramentas modernas para entregar valor ao cliente rapidamente
- Mais do que elementos técnicos como uso de nuvem, infraestrutura como código e construção de pipelines de CI/CD, o ponto central é derrubar barreiras de comunicação e colaboração para alcançar resultados melhores
Platform Engineering
- Platform Engineering é uma abordagem técnica para reduzir a carga cognitiva dos desenvolvedores
- O objetivo é aumentar ao mesmo tempo a velocidade de desenvolvimento do produto e a estabilidade do sistema, fornecendo componentes fundamentais que apoiam as atividades dos desenvolvedores
- Está aumentando o número de casos em que grandes empresas montam equipes de platform engineering para elevar a eficiência e melhorar a experiência do desenvolvedor
- O tema se popularizou com o livro Team Topologies, de Manuel Pais e Matthew Skelton, e há vários conteúdos mostrando casos de fortalecimento da capacidade de engenharia
Staff Engineering
- Staff Engineering não é uma mentalidade específica nem uma tecnologia, mas sim um papel assumido por engenheiros de software dentro da organização
- É uma etapa de carreira após Senior Software Engineer, e também pode ser descrita como a liderança servidora da engenharia de software
- Engenheiros Staff+ expandem sua responsabilidade para além do trabalho individual, colaborando com gestores e VPs para oferecer execução prática e perspectiva
- No livro Staff Engineer, Will Larson explica o papel de Staff dividindo-o em quatro arquétipos: Architect, Right Hand, Tech Lead e Fixer
[Cultura de startups]
- Startups baseadas em investimento de venture capital muitas vezes gastam mais do que faturam para crescer
- O capital obtido com investimento é usado como "runway" para buscar crescimento rápido, e é preciso atingir crescimento e rentabilidade antes que esse runway acabe
- Esse ambiente cria duas características culturais centrais
- Não há tempo a desperdiçar
- Em startups, desperdiçar tempo é especialmente fatal
- As equipes de desenvolvimento precisam se concentrar nos objetivos estratégicos da organização e executar dentro do runway disponível
- Cada membro da equipe precisa verificar com frequência se suas atividades estão alinhadas aos objetivos e, se necessário, reajustá-las
- Mesmo que um experimento falhe, se houver uma estrutura para aprendizado e as lições desejadas forem obtidas, isso não é desperdício
- Todo mundo exerce vários papéis
- Em organizações pequenas, há muito a fazer, mas faltam pessoas para executar tudo
- Por exemplo, um desenvolvedor frontend pode acumular funções de product designer, redator técnico, gerente de produto, garantia de qualidade e responsável por integrações com terceiros
- Se surgir uma nova ideia para melhorar a experiência do cliente, a própria pessoa que a propôs pode acabar responsável por prototipá-la ou colocá-la em prática
- Essas características culturais determinam as capacidades necessárias ao grupo de desenvolvimento de produto e, em especial, aos líderes de engenharia de software
- Também dão pistas sobre como DevOps, Platform Engineering e Staff Engineering precisam se adaptar ao contexto de startups
[Aplicando meus princípios de engenharia (tenets) à cultura de startups]
DevOps em startups
- Em startups, é fácil mudar processos.
- Como há pouca gente, não existem grandes barreiras para adotar novas formas de trabalho
- Ajustar o processo com base nas ferramentas traz os melhores resultados
- Manter processos rígidos desperdiça tempo, porque exige customizar ferramentas ou desenvolver software adicional
- É preciso evitar ao máximo ferramentas customizadas
- O ideal é aproveitar infraestrutura serverless, ferramentas SaaS, bibliotecas open source etc.
- Deve-se seguir a direção geral da tecnologia e não customizá-la quando isso não oferecer uma vantagem competitiva diferenciada
- Referência: Martin Fowler, Utility vs Strategic Dichotomy
- É preciso escolher "tecnologia entediante"
- Não se deve assumir grandes riscos com soluções que a equipe não conhece ou que têm pouca comunidade
- Em caso de problema, é melhor escolher tecnologias cujas soluções sejam fáceis de encontrar online
- Dan McKinley explica essa ideia em mais detalhe em sua palestra no boringtechnology.club
Platform Engineering em startups
- Conteúdo mencionado por Rebecca Murphey no podcast Engineering Unblocked:
- "A experiência do desenvolvedor em uma empresa é um produto, tenha ela sido projetada ou não"
- Mesmo em escala de startup, ainda são necessários monitoramento, deploy, rastreamento de erros, verificação de logs e alternância de feature flags
- A pergunta importante é: "essas tarefas são dolorosas?"
- Platform Engineering é um papel de meio período em startups
- No início pode ser necessário um ambiente de testes integrado, mas depois isso pode perder prioridade
- O papel de platform engineering acaba sendo exercido apenas quando necessário
- Não há folga para tocar projetos de plataforma de longo prazo
- Em vez disso, é preciso implementar elementos valiosos por meio de trabalhos pequenos
- É importante compartilhar o panorama geral e a visão com a equipe, fazendo todos entenderem como as pequenas partes se conectam
- O trabalho de plataforma em startups é um processo de abrir novos caminhos de produtividade e novas abordagens
- Na maioria dos casos, não se trata de migrar software existente para ferramentas modernas, mas de construir do zero elementos que antes nem existiam
- Mais importante do que decidir o que é possível fazer é decidir o que deve ser feito
- É preciso focar em trabalhos que resolvam problemas atuais da organização ou problemas do futuro próximo
- É preciso identificar o trabalho necessário por meio de experiência prática, conversas com engenheiros, feedback de retrospectivas e análise de métricas de SDLC (ciclo de vida de desenvolvimento de software)
- Às vezes, pode ser melhor adiar o trabalho de plataforma e focar em outras necessidades
- A chave é agir com flexibilidade
Staff Engineering em startups
- O papel de Staff Engineer combina bem com o ambiente de startups
- Profunda especialização técnica, tendência a buscar ampla influência e disposição para agir onde for necessário para resolver problemas de negócio se encaixam bem em startups
- Em organizações grandes, existe a expressão "saber onde a dívida técnica está enterrada"
- O Staff Engineer encontra quem tem esse conhecimento, organiza a situação e conduz decisões sobre como seguir em frente
- Em startups, a dívida técnica e os problemas ficam claramente expostos
- O Staff Engineer pode gerar grande impacto ao organizar esse caos e construir soluções que ajudem a organização no longo prazo
- Em startups, um Staff Engineer não pode ficar preso a um único arquétipo
- Como a organização é pequena, é preciso desempenhar diversas atividades, inclusive execução direta
- Além de desenhar arquitetura, liderar projetos e realizar trabalho tático, também é preciso identificar por conta própria ideias de melhoria e executá-las
- Flexibilidade e senso de responsabilidade proativo são características indispensáveis para engenheiros Staff+ em startups
- Um dos papéis importantes de engenheiros Staff+ é mentoria e sponsorship
- Isso oferece apoio e direcionamento especialmente importantes para talentos júnior em startups
- O Staff Engineer promove o crescimento da equipe e fortalece a capacidade da organização por meio desse suporte
[Aplicando staff engineering moderno em startups]
História 1 de 2 - "Improving DevEx by Removing a Merge Freeze"
Situação do problema
- Processo de QA anterior:
- Antes do release, era aplicado um "merge freeze" por 2 a 3 dias, enquanto a equipe de QA realizava testes de regressão manuais
- Os bugs encontrados eram corrigidos imediatamente e mesclados na branch main
- Os desenvolvedores geravam novos patches, mas precisavam adiar os pedidos de merge até depois do release
- Desvantagens:
- Os testes de regressão manuais eram lentos e imprevisíveis
- O atraso nos merges aumentava a frequência de merge conflicts
- A produtividade e a colaboração dos desenvolvedores eram prejudicadas
Solução
- Integração do código de infraestrutura em um monorepo
- Os projetos Terraform foram integrados ao mesmo repositório do código da aplicação
- Foram conectados a ferramentas automatizadas de linting e gerenciamento de dependências para facilitar o trabalho dos desenvolvedores com a infraestrutura
- Gerenciamento de todos os ambientes com Terraform
- Não apenas os novos ambientes, mas também os ambientes existentes de staging e produção passaram a ser gerenciados com Terraform
- A consistência entre ambientes foi mantida aplicando variáveis diferentes à mesma definição de infraestrutura
- Simplificação do processo de CI/CD
- O template anterior do GitLab Auto DevOps havia se tornado complexo devido a muitas customizações
- O Auto DevOps foi removido e um novo arquivo
.gitlab-ci.yml foi definido de forma clara
- A maior parte dos comandos foi movida para um Makefile, permitindo execução manual quando necessário
- Melhoria no gerenciamento de secrets
- Para reduzir o acoplamento com o GitLab, os secrets da aplicação foram migrados para o Google Cloud Secrets Manager
- Os scripts de deploy foram modificados para atualizar automaticamente o Kubernetes ConfigMap
- Trabalhos fora do escopo
- A aplicação rodava no Kubernetes em uma arquitetura monolítica
- Isso foi mantido, pois alterar esse ponto poderia causar atrasos e riscos
- Não foi construído um pipeline de automação do Terraform
- Como as mudanças de infraestrutura eram relativamente poucas, o processo manual foi mantido
- A abordagem nativa do Kubernetes para acesso a secrets também foi adiada
Resultados e impactos
- Um novo ambiente de testes foi implantado, permitindo que a equipe de QA executasse testes de regressão de forma independente
- Com a remoção do merge freeze, os desenvolvedores puderam mesclar mudanças livremente na branch main
- O processo de release foi simplificado e a velocidade de toda a equipe melhorou
Princípios aplicados
- Princípios de Staff Engineering
- Liderança do projeto em colaboração com várias equipes
- Atuação no papel de "Tech Lead", conduzindo o projeto até a conclusão
- Melhoria da compreensão e da acessibilidade para a equipe por meio de avanços em CI/CD e infraestrutura
- Princípios de Platform Engineering
- Expansão de um projeto de DevOps para um projeto de plataforma
- Garantia de consistência entre ambientes ao gerenciar toda a infraestrutura como código
- Ajuste do escopo do projeto por meio de trade-offs realistas
- Princípios de DevOps
- Operação consistente da infraestrutura em nuvem ao gerenciar a infraestrutura como código
- Melhoria do processo de release e aceleração do desenvolvimento com novas ferramentas
- Adoção do formato de documento RFC (Request For Comment) para tornar o processo de decisão mais inclusivo
Conclusão
- A equipe de QA passou a executar testes automatizados em um ambiente mais estável
- Os desenvolvedores passaram a trabalhar de forma contínua sem merge freeze, fortalecendo a colaboração
- A produtividade da organização melhorou com ferramentas e processos melhores
- No futuro, pretende-se avançar com iniciativas como criação de ambientes de preview e automação de testes de regressão
História 2 de 2 - "Iterating Towards a Productive Engineering Process"
Situação do problema
- Processo anterior:
- Todos os membros da equipe trabalhavam em um único board e compartilhavam o andamento diariamente
- Muitas pessoas não mantinham o foco quando não era sua vez e ficavam em estado de "desconexão"
- A responsabilidade pelo desenvolvimento de funcionalidades era dispersa, e muitas vezes o gerente de produto acabava com a responsabilidade final
- Também faltava uma compreensão clara da arquitetura técnica
- Objetivo:
- Realizar vários experimentos para construir um processo melhor de colaboração e desenvolvimento de software
- Experimento 1: Short-lived Feature Teams
- Objetivo: dar aos engenheiros senso de responsabilidade por todo o ciclo de vida do desenvolvimento de funcionalidades
- Como:
- Foi designado um líder para cada funcionalidade, e equipes foram organizadas com backend, frontend, QA etc.
- Resultados:
- O senso de responsabilidade da equipe melhorou, mas nem todos eram adequados para o papel de líder ou desejavam exercê-lo
- Depois, houve a transição para o "modelo de equipes fixas", formando "Squads", com cada equipe fazendo seu próprio planejamento e retrospectiva
- Experimento 2: Epic Kickoff Documents
- Objetivo: esclarecer requisitos e chegar a um alinhamento da equipe sobre escopo e abordagem do projeto
- Como:
- Todos os membros da equipe escreviam o documento durante a reunião usando o template fornecido
- Resultados:
- A comunicação da equipe melhorou, e a colaboração passou a acontecer melhor desde o início do projeto
- Os membros avaliaram essa reunião como um tempo bem investido
- Experimento 3: Group Code Review
- Objetivo: reduzir o tempo de code review, estimular discussões sobre código e compartilhar conhecimento técnico entre engenheiros
- Como:
- Duas vezes por semana, era realizada uma sessão de code review de uma hora no Slack Huddle
- O desenvolvedor compartilhava a tela, explicava o PR, e os participantes davam feedback
- Resultados:
- O tempo gasto com code review caiu significativamente, mantendo o estado de Inbox 0
- As discussões sobre o código criaram uma cultura em que os desenvolvedores aprendiam uns com os outros e se respeitavam
- Além do code review, os benefícios da programação em par também foram apresentados à equipe
Princípios aplicados
- Princípios de Staff Engineering
- Liderança na melhoria de processos na ausência de um gerente de engenharia
- Introdução de uma cultura de melhoria contínua na equipe, fortalecendo a colaboração autônoma por meio de um processo ágil
- Apoio para que a equipe rompesse com processos estagnados e encontrasse formas melhores de trabalhar
- Princípios de Platform Engineering
- Consideração de que processos também fazem parte da plataforma, e não apenas ferramentas
- Como processos ineficientes prejudicam a produtividade da equipe, melhorá-los é essencial
- Mudanças de processo que eliminam desperdícios podem ter tanto impacto quanto melhorias em ferramentas
- Princípios de DevOps
- Princípios CALMS: colaboração (Collaboration), automação (Automation), lean (Lean), medição (Measurement), compartilhamento (Sharing)
- Um processo lean elimina desperdícios e entrega valor com mais rapidez
- Educação da equipe para melhorar continuamente por meio de processos ágeis
Conclusão
- Ao melhorar o processo da equipe de forma experimental, a produtividade e a colaboração aumentaram bastante
- Melhorias de baixo custo e alta eficiência elevaram a experiência de desenvolvimento de toda a equipe
- Recomenda-se fortemente revisar criticamente seus próprios processos e procurar pontos de melhoria
[Encerramento]
- Ao trabalhar em um ambiente de startup, é possível aplicar tanto especialização quanto paixão no processo de resolver vários problemas e transformar soluções em realidade
- Como há restrições de tempo, isso se torna uma boa oportunidade para desenvolver uma abordagem pragmática, além de permitir gerar grande impacto nos estágios iniciais da empresa
- É possível estabelecer a base para o sucesso da empresa aplicando abordagens modernas de engenharia de software
-
Staff Engineering e startups
- Um Staff Engineer precisa de experiência com amplitude e profundidade
- Startups oferecem a engenheiros Staff+ a oportunidade de expandir seu conhecimento técnico e explorar novas áreas
- Exemplo: um engenheiro de backend pode aprender tecnologias como React ou BigQuery
-
Platform Engineering e startups
- Platform Engineering em startups varia de acordo com a escala
- Por meio de comunicação 1:1, é possível identificar os pontos de dor dos desenvolvedores e melhorar a experiência do desenvolvedor (DevEx) com pequenos projetos
- É preciso construir loops de feedback rápidos para melhorar o processo de desenvolvimento e ajudar os desenvolvedores a resolver problemas por conta própria no futuro
- É importante atender aos fundamentos do ciclo de vida de desenvolvimento de software (SDLC) com ferramentas e técnicas padrão da indústria
- Em startups, Platform Engineering não é uma função dedicada, mas uma abordagem técnica aplicada conforme a necessidade
- Tenha em mente que "a experiência do desenvolvedor na empresa é um produto" e reserve tempo para projetá-la
-
DevOps e startups
- DevOps também desempenha um papel muito importante em startups
- O ponto central é entregar valor ao cliente mais rapidamente e criar um ambiente de trabalho melhor por meio de cultura, processos e ferramentas
- Aumentar a eficiência da empresa e estabelecer uma cultura de colaboração por meio de DevOps é um processo muito recompensador
- Em startups, engenheiros apaixonados por DevOps podem contribuir enormemente com suas habilidades e experiência
- O ambiente de startup é cheio de novos desafios e oportunidades de aprendizado, e por meio disso os engenheiros podem crescer ainda mais e alcançar resultados significativos
3 comentários
Obituário do DevOps
O engenheiro de plataforma que ganha mais do que um engenheiro de DevOps
O que é um engenheiro Staff?
Parece que isso define muito bem os papéis de engenharia necessários daqui para frente nas startups. Acho que organizou bem o trabalho de engenharia que antes era feito sem uma divisão clara. Também parece que cada pessoa poderá entender de forma mais concreta de que tipo de engenharia é responsável e no que quer se especializar melhor no futuro. Assim, as startups também podem estruturar uma engenharia mais sistematizada e contratar melhor os engenheiros de que precisam.