Processo de DevOps: como trabalhar em lotes pequenos

Trabalhar em pequenos lotes é essencial em qualquer prática em que os ciclos de feedback sejam importantes. Além disso, você consegue aprender rapidamente com suas decisões. É possível testar a probabilidade de uma mudança específica ter o efeito desejado com rapidez. Caso não tenha, é possível corrigir ou rever as suposições. Embora este artigo se aplique a qualquer tipo de mudança que inclua transformação organizacional e melhoria de processos, ele se concentra principalmente na entrega de software.

O trabalho em pequenos lotes faz parte do gerenciamento otimizado de produto. Unido a capacidades como visibilidade do trabalho no fluxo de valor, experimentação em equipe e visibilidade do feedback do cliente, trabalhar em lotes pequenos ajuda a prever o desempenho organizacional e da entrega de software.

Um dos motivos que levam as pessoas a trabalhar com grandes lotes é o alto preço fixo da entrega de mudanças. Em abordagens tradicionais de desenvolvimento de software, entregas do desenvolvimento para o teste ou do teste para as operações de TI consistem em versões inteiras: meses de trabalho de equipes formadas por dezenas ou centenas de pessoas. Dessa forma, coletar feedback sobre uma mudança pode levar semanas ou meses.

Em contrapartida, as práticas de DevOps utilizam equipes multifuncionais e abordagens leves. Assim, o software vai do desenvolvimento à produção em questão de minutos, por meio de testes e operações. No entanto, para essa rápida progressão, é necessário trabalhar com código em pequenos lotes.

O trabalho em lotes pequenos oferece muitos benefícios:

  • Ele reduz o tempo necessário para receber feedback sobre alterações, facilitando a triagem e a solução de problemas.
  • Há um aumento da eficiência e da motivação.
  • Isso evita que sua organização sucumba à falácia do custo irrecuperável.

É possível aplicar a abordagem de pequenos lotes no nível do recurso e do produto. Por exemplo, um produto viável mínimo (MVP, na sigla em inglês) é um protótipo de um produto com recursos suficientes para permitir um aprendizado válido sobre o ele e o modelo de negócios.

A entrega contínua é gerada em pequenos lotes e busca conseguir todas as alterações no controle de versões o quanto antes. Uma meta da entrega contínua é alterar a economia do processo de entrega de software, tornando viável trabalhar em pequenos lotes. Essa abordagem fornece um feedback rápido e abrangente às equipes para que elas possam melhorar seu trabalho.

Como trabalhar em pequenos lotes

Ao planejar novos recursos, tente dividi-los em unidades de trabalho que possam ser concluídas de forma independente e em curto espaço de tempo. Recomendamos que cada recurso ou lote de trabalho siga o conceito de agilidade do princípio INVEST:

  • Independente: faça com que os lotes sejam o mais independentes possível entre si. Assim, as equipes podem trabalhar, implantar e validá-los em qualquer ordem, sem depender de outros lotes.
  • Negociável: cada lote é iterável e pode ser renegociado de acordo com feedbacks.
  • Valioso: lotes de trabalho discretos podem ser usados e agregam valor às partes interessadas.
  • Estimável: há informações suficientes sobre os lotes de trabalho para fazer facilmente uma estimativa sobre o escopo.
  • Pequeno: durante um sprint, é possível concluir lotes de trabalho em pouco tempo, como algumas horas ou dias.
  • Testável: cada lote de trabalho pode ser testado, monitorado e verificado quanto a funcionalidade esperada pelos usuários.

Quando os recursos são de tamanho adequado, é possível dividir o desenvolvimento em lotes ainda menores. Esse processo pode ser difícil e requer experiência para ser desenvolvido. O ideal é que os desenvolvedores verifiquem várias pequenas alterações que podem ser liberadas no tronco pelo menos uma vez por dia.

A chave é iniciar o desenvolvimento na camada da API ou do serviço, não na camada da interface do usuário. Assim, fazer adições à API que inicialmente não estarão disponíveis para os usuários do app e verificar essas alterações no tronco. Inicie essas alterações na produção sem torná-las visíveis para os usuários. Essa abordagem, chamada lançamento no escuro, permite aos desenvolvedores verificar o código de pequenos lotes que foram concluídos e de recursos que ainda não estão totalmente completos. Em seguida, é possível executar testes automatizados com essas alterações para verificar se elas se comportam da maneira esperada. Dessa forma, as equipes ainda estão trabalhando rapidamente e desenvolvendo fora do tronco, e não nas ramificações de recursos de longa duração.

Também é possível fazer mudanças por lançamento no escuro usando a alternância de recursos (em inglês), que é uma instrução condicional com base nas configurações. Por exemplo, é possível tornar elementos de IU visíveis ou invisíveis e ativar ou desativar a lógica do serviço. A configuração da alternância de recursos pode ser lida no momento da implantação ou no ambiente de execução. Use essas configurações para mudar o comportamento do novo código mais adiante na pilha. Também é possível usar uma técnica similar conhecida como ramificação por abstração (em inglês) para fazer mudanças maiores no sistema enquanto continua a desenvolver e fazer lançamentos fora do tronco sem o uso de ramificações de longa duração.

Nessa abordagem, os lotes de trabalho não são concluídos até que sejam implantados na produção e o processo de feedback tenha começado a validar as alterações. Os feedbacks vêm de muitas fontes e de várias formas, incluindo usuários, monitoramento do sistema, controle de qualidade e testes automatizados. Sua meta é otimizar a velocidade a fim de reduzir o tempo do ciclo para que as alterações cheguem aos usuários. Dessa forma, é possível validar sua hipótese o mais rápido possível.

Armadilhas comuns no trabalho em pequenos lotes

Ao dividir o trabalho em pequenos lotes, você encontra duas armadilhas:

  • Não dividir o trabalho em partes pequenas o suficiente: sua primeira tarefa é dividir o trabalho de forma significativa. Recomendamos que você confirme um código independente do status do recurso e que os recursos individuais levem no máximo alguns dias para serem desenvolvidos. Qualquer lote de código que leve mais de uma semana para ser concluído e verificado é grande demais. Durante o processo de desenvolvimento, é essencial analisar como dividir ideias em segmentos que podem ser desenvolvidos iterativamente.

  • Trabalhar em pequenos lotes, mas reagrupá-los antes de enviá-los ao downstream para teste ou lançamento: reagrupar o trabalho desse modo atrasa o feedback sobre defeitos nas alterações e se os usuários e a organização concordam que as mudanças foram a melhor decisão.

Maneiras de reduzir o tamanho dos lotes de trabalho

Quando você divide o trabalho em pequenos lotes que podem ser concluídos em horas, normalmente é possível testar e implantar esses lotes na produção em menos de uma hora (arquivo PDF em inglês). A chave é decompor o trabalho em pequenos recursos que permitem um rápido desenvolvimento, em vez de desenvolver recursos complexos em ramificações e liberá-los com pouca frequência.

Para melhorar o desenvolvimento de pequenos lotes, verifique seu ambiente e confirme se as seguintes condições são verdadeiras:

  • O trabalho é decomposto de forma a permitir que as equipes façam lançamentos de produção com mais frequência.
  • Os desenvolvedores têm experiência em dividir o trabalho em pequenas alterações que podem ser concluídas em horas, não em dias.

Para se especializar no desenvolvimento de pequenos lotes, procure atender a todas essas condições em todas as suas equipes de desenvolvimento. Essa prática é uma condição necessária para a integração contínua e o desenvolvimento baseado em tronco.

Formas de medir o tamanho dos lotes de trabalho

Ao compreender a integração contínua e o monitoramento, é possível descrever formas viáveis de medir o desenvolvimento de pequenos lotes nos sistemas e no ambiente de desenvolvimento.

  • Os recursos do aplicativo são decompostos para serem compatíveis com lançamentos frequentes. Com que frequência os lançamentos são possíveis? Como esse ritmo de lançamento difere entre as equipes? Há atrasos na produção relacionados a elementos maiores?
  • Os recursos do aplicativo são divididos de forma que os desenvolvedores possam concluir o trabalho em até uma semana. Que proporção dos recursos é possível concluir em uma semana ou menos? Quais recursos não é possível concluir em até uma semana? É possível confirmar e liberar alterações antes que o recurso seja concluído?
  • Os MVPs são definidos como metas para as equipes. O trabalho é decomposto em recursos que permitem MVPs e desenvolvimento rápido, em vez de processos complexos e demorados?

Para responder a essas perguntas, você precisa:

  • conhecer os processos da sua organização;
  • traçar metas para reduzir o desperdício;
  • buscar maneiras de reduzir a complexidade no processo de desenvolvimento.

A seguir