Estimativa de uma reformulação do CI/CD

O trabalho no pipeline não tem demonstração. Selecione com base no critério “qual versão pode ser excluída hoje” para que a estimativa seja viável.

As reformulações de CI/CD são as tarefas mais difíceis de definir no backlog. Não há resultado visível para o usuário, nem demonstração, nem captura de tela que alguém possa incluir nas notas de lançamento. O trabalho é estrutural: substituir um pipeline por outro, migrar um sistema de compilação, consolidar três executores de teste em um único, passar de um script de shell feito manualmente para um arquivo de fluxo de trabalho adequado. A equipe sabe que o trabalho precisa ser feito. A equipe também sabe que isso levará um trimestre, e que esse trimestre será invisível para quem está fora da organização de engenharia.

O modo de falha na estimativa é previsível. A equipe vota em 13 porque “é uma refatoração, é algo grande”. Após três sprints, o pipeline antigo ainda está funcionando paralelamente ao novo, dois sistemas estão parcialmente configurados e cada engenheiro tem um modelo mental diferente sobre qual deles usar. A história não está concluída porque não há uma definição de “concluído” — pipelines não são lançados; eles são adotados, e a adoção é uma questão distinta de “a novidade existe”.

O que se fala na sala

SRE: “Precisamos sair do runner antigo. Dois sprints.”

Líder: “Qual é a definição de ‘concluído’?”

SRE: “…o novo funciona.”

Líder: “O novo já dá conta de metade do nosso trabalho.”

Backend: “Mas o antigo ainda funciona para a outra metade.”

Lead: “Certo. Então, terminamos quando pudermos excluir o antigo.”

É essa a jogada. A tarefa não é “construir o novo pipeline” — a equipe provavelmente já o construiu há meses, em um projeto rápido feito por alguém no tempo livre. A tarefa é “excluir o pipeline antigo”. Enquanto o sistema de compilação antigo não for removido, a reformulação não estará concluída; trata-se de uma infraestrutura paralela com todos os custos e nenhum benefício. Definir a tarefa como remoção em vez de criação dá à equipe uma definição de “concluído” sobre a qual ela pode votar.

Como fatiar

Faça um levantamento das tarefas que ainda estão em execução no sistema antigo. Para cada tarefa: o que seria necessário para excluir a versão antiga? Isso já é uma história. Algumas são triviais (a tarefa já foi espelhada para o novo pipeline; basta remover o YAML antigo). Outras exigem um trabalho mais complexo (o conjunto de testes tem um caminho codificado; a etapa de implantação depende de uma variável de ambiente antiga). Cada remoção é uma pequena parte que a equipe pode entregar e demonstrar. “Excluímos o Jenkinsfile do serviço de autenticação” é um resultado que pode ser demonstrado.

Cada remoção pode ser estimada da maneira habitual: identifique primeiro as incógnitas (será que esse trabalho tem usuários que a gente não conhece?), depois estime a remoção comparando-a com uma remoção de referência que você já tenha implementado. A maioria das fatias fica em 2 ou 3 pontos. A história que era “13, refatoração, grande” era, na verdade, quinze “2” e um “3” disfarçado.

Perguntas que vale a pena fazer antes de votar

• O que será excluído quando essa matéria for publicada?
• Quais funções ainda dependem do sistema antigo?
• Existe algum usuário do pipeline antigo que não conhecemos — uma equipe externa, uma tarefa agendada?
• Qual seria a reversão se o novo pipeline apresentasse um retrocesso depois que excluirmos o antigo?
• Quem tem autoridade para afirmar que “o novo canal é a fonte da verdade”?
• Alguém está acompanhando, semana a semana, quais tarefas são executadas no sistema antigo e quais no novo?

Se a resposta para “o que será excluído” for “nada neste sprint”, a equipe ainda está na fase de infraestrutura paralela e a história não passa no gate de prontidão.

O trabalho no pipeline é feito quando a versão antiga já foi removida. Faça a remoção em etapas; faça uma estimativa de cada remoção separadamente.

Consulte segmentação horizontal x vertical para entender por que “construir o novo sistema” é o eixo de segmentação incorreto, bem como os outros exemplos de estimativas bem-sucedidas. Inicie uma sessão gratuita de Planning Poker assim que a equipe tiver uma lista de itens a serem removidos.