Gerenciando Entregas em Scrum: Além da Liberação Após Cada Sprint
Em geral, a expectativa no contexto de Scrum é que uma nova versão seja lançada logo após a conclusão de um sprint, idealmente após uma apresentação bem-sucedida ao cliente. No entanto, essa automatização levanta questionamentos quando consideramos as várias atividades que devem ser realizadas em paralelo ou antes da liberação.
É fundamental ponderar sobre os seguintes pontos:
- O desenvolvimento e conclusão de todas as histórias do sprint, que, frequentemente, são finalizadas pouco antes do término, ou até mesmo depois da demonstração.
- A execução completa dos testes planejados para o conteúdo do sprint, assegurando a qualidade do código a ser lançado.
- O rastreamento e correção de bugs identificados dentro do prazo, antes da liberação.
- A verificação de que o pipeline de implementação esteja atualizado com o conteúdo mais recente e que sua execução seja confiável.
- A implementação do pipeline em todos os ambientes necessários, para garantir a atualização de código e dados.
- A preparação das notas de lançamento e a comunicação com o cliente sobre os impactos e mudanças que a liberação trará.
- A sincronização com outras equipes Scrum para garantir que todos os componentes interdependentes sejam liberados simultaneamente, evitando falhas.
- A participação em todas as cerimônias do Scrum, tanto as do sprint atual quanto as que se referem ao sprint seguinte.
Agora, imagine tudo isso acontecendo em um sprint de apenas duas semanas.
As atividades de lançamento exigem tempo e a dedicação de membros da equipe. No entanto, não podem ser excessivamente demoradas, dado que o novo sprint começa imediatamente após o término do anterior, reiniciando o ciclo.
Diante disso, a expectativa de uma liberação ao final de cada sprint ainda parece viável?
O Processamento do Conteúdo da Liberação
Se todos os processos dentro de um sprint fossem totalmente automatizados, seria possível liberar a versão mais recente do código para produção ao final de cada sprint com um simples “clique”. No entanto, essa perfeição é rara em equipes Scrum. Embora algumas pequenas empresas possam ter alcançado tal nível de eficiência, a realidade corporativa é que os processos de liberação muitas vezes envolvem atividades complexas que se estendem para o sprint seguinte, afetando seu conteúdo e métricas. A liberação acaba sendo um processo estressante para a equipe.
Portanto, busquei uma alternativa para gerenciar as liberações de forma mais eficiente.
A solução encontrada foi designar o segundo sprint como “Sprint de Liberação”. Veja o que isso implica:
Isolando o Código para a Próxima Liberação
A estratégia envolve o uso de ramificações separadas no repositório GIT. Embora existam diversas maneiras de abordar essa questão, vamos simplificar o conceito para melhor compreensão.
Para minimizar o impacto sobre o desenvolvimento em curso, o conteúdo da próxima liberação deve ser isolado em uma ramificação separada, chamada “Ramo de Liberação”. Isso permite:
- Que a equipe de desenvolvimento continue trabalhando e integrando novas histórias à ramificação principal sem interrupções.
- Que o conteúdo da liberação não seja afetado por mudanças inesperadas no código.
- Que os testes sejam realizados em um ambiente isolado, introduzindo apenas as alterações necessárias para corrigir bugs.
- Que o pipeline de liberação implante apenas o conteúdo do Ramo de Liberação, garantindo controle e evitando a inclusão de commits não testados.
Assim, o conteúdo da próxima liberação é mantido à parte, em um estado estável, pronto para ser lançado.
Programando as Liberações para Funcionar de Forma Consistente
A ideia de liberar após cada sprint foi abandonada, pois claramente não seria eficaz, gerando os seguintes problemas:
- Impacto no conteúdo do próximo sprint de desenvolvimento.
- Dificuldade em estabilizar o conteúdo da liberação.
- Complexidade na atualização das atividades de teste necessárias.
O objetivo passou a ser realizar a liberação ao final de cada segundo sprint, o que traz:
- Uma liberação contendo as histórias dos dois últimos sprints concluídos. O conteúdo do sprint atual não é incluído na liberação.
- Um sprint inteiro para testes e correções de bugs.
- Tempo para o responsável pela liberação coletar informações relevantes (casos de teste, notas de lançamento) com o sprint sem liberação, permitindo que o restante da equipe trabalhe em novas histórias.
- Em caso de bugs, o responsável pela liberação pode rapidamente contatar o desenvolvedor para corrigi-los, alocando parte da capacidade da equipe para isso.
Os usuários não recebem o conteúdo do sprint mais recente na última liberação, mas, com o tempo, isso se torna irrelevante, pois recebem o conteúdo de dois sprints a cada lançamento.
Essa abordagem representa um bom equilíbrio entre entregas rápidas e o acompanhamento das atividades Scrum sem interrupções.
Executando a Implantação da Liberação
Após a conclusão dos testes, correção de bugs e verificação da prontidão do pipeline, a execução do pipeline de produção e a liberação se tornam processos diretos.
Como a implantação é feita a partir de uma ramificação isolada, ela pode passar despercebida. Essa é a melhor forma de implementação de uma liberação.
É essencial ter um pipeline DevOps automatizado, utilizado não apenas para a implantação em produção, mas também em todos os outros ambientes, como desenvolvimento, sandbox, teste, qualidade e desempenho. A implantação para todos os ambientes deve ser feita com um simples clique.
A liberação não deve ser um momento de dor ou estresse, mas sim um processo imperceptível. Se ninguém notar a liberação, este é o sinal de sucesso.
Reintegrando o Ramo de Liberação ao Ramo de Desenvolvimento
O Ramo de Liberação contém correções implementadas durante o período de teste que não estão no ramo de desenvolvimento. Esse conteúdo precisa ser reintegrado para que as correções permaneçam mesmo após a próxima liberação.
Nesse ponto, o Ramo de Liberação mais recente serve como um código de produção pronto para uma nova implementação emergencial. Se um problema urgente precisar ser corrigido após a implantação em produção, essa ramificação pode ser usada, pois é uma cópia exata do código de produção atual.
Por fim, após o início do novo período de teste, o ramo da versão anterior pode ser excluído e substituído por um novo, criado como cópia do ramo de desenvolvimento atual.
Estabelecendo Liberações Regulares
E assim, temos um processo sólido para lidar com as liberações. A única coisa que falta é manter o compromisso de realizá-las de forma regular, neste caso, a cada segundo sprint.
Ao manter a regularidade, facilitamos o processo, pois:
- Como o intervalo entre liberações é curto, a quantidade de conteúdo novo a ser instalado em produção é pequena e estável.
- Menos conteúdo novo implica menos atividades de teste e criação de casos de teste. Menos comunicação e colaboração com os stakeholders.
- A equipe se acostuma com o ciclo, e a liberação se torna uma parte natural do trabalho.
- Os ambientes de desenvolvimento e teste são atualizados com dados, o que já é necessário para cada ciclo de teste, tornando essa atividade parte do processo.
Conclusão
Este artigo encerra a discussão sobre o ciclo de vida do Scrum, mostrando o que tem funcionado na prática.
Muitas equipes iniciam a jornada ágil cometendo erros, mas evoluem e ajustam suas práticas. Esta série de artigos pode ajudar outras equipes a fazerem essa mudança mais rapidamente.
Essa abordagem de liberação não é a única válida e não está isenta de problemas. As equipes precisarão lidar com eles, melhorar o que for possível e descartar o que não funciona.
Esta abordagem, apesar de simples, demonstra que a mudança é possível, transformando sprints caóticos e imprevisíveis em entregas estáveis, com liberações regulares. Não exige uma metodologia complicada, apenas regras simples e a vontade de seguir o plano.