Estimativa de uma reformulação do CI/CD

O trabalho no pipeline não tem demonstração. Selecione com base no critério “qual build pode ser excluída hoje” para que seja possível estimar o tempo necessário.

As reformulações de CI/CD são as tarefas mais difíceis de definir no backlog. Não há nenhum resultado visível para o usuário, nenhuma demonstração, nenhuma 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 só, 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, é um trabalho 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 é dito na sala

SRE: “Precisamos trocar o corredor antigo. Duas corridas de sprint.”

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.”

Líder: “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 pontual realizado no tempo livre de alguém. 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 trabalho de verdade (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 usual: identifique primeiro as incógnitas (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 concluída?
• Quais funções ainda dependem do sistema antigo?
• Existe algum usuário do pipeline antigo que não conhecemos, como uma equipe externa ou uma tarefa agendada?
• Qual seria a reversão caso o novo pipeline apresente regressão depois que excluirmos o antigo?
• Quem tem autoridade para afirmar que “o novo canal de informações é 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 é realizado quando a versão antiga já foi removida. Faça a remoção em etapas; faça uma estimativa individual para cada remoção.

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