Um plano é um conjunto ordenado de tarefas agrupadas em fases. Você o aprova antes que o código seja escrito.
Use um quando o trabalho exigir várias alterações em uma ordem específica ou quando quiser ver toda a abordagem antes de se comprometer com alguma delas.
O ciclo de vida
O planejamento é uma etapa própria, não uma transformação instantânea.
- O planejamento começa. O arquiteto analisa o código-fonte e elabora as fases e tarefas.
- Você revisa o rascunho. Este é o ponto de intervenção mais barato em todo o sistema.
- Aprovar, revisar ou reiniciar. Ao aprovar, o plano é liberado para execução; ao revisar, ele retorna com seu feedback; ao reiniciar, o planejamento recomeça.
- Execução. As tarefas são executadas em ordem, respeitando os limites das fases.
Você pode aprovar e executar em uma única etapa ou aprovar e iniciar posteriormente.
Revisar em vez de reiniciar
Quando um plano está quase correto, revisá-lo preserva o que o arquiteto aprendeu sobre seu código-fonte e aplica seu feedback. Reiniciar descarta isso e começa tudo de novo.
Reinicie quando toda a abordagem estiver errada. Revisar quando a abordagem estiver certa, mas os detalhes não. A revisão é muito mais barata, e o conteúdo de um plano rejeitado não se perde — ele serve de base para a próxima tentativa.
Controlando um plano em execução
Um plano em andamento pode ser pausado, retomado ou cancelado, e você pode acompanhar o progresso em suas fases. Os planos também podem ser clonados, o que é a maneira prática de repetir uma estrutura que funcionou — como uma migração aplicada a um segundo serviço, por exemplo.
Os planos concluídos podem ser arquivados para manter a visualização ativa significativa.
Um só pull request, não um por tarefa
As tarefas de um plano não abrem um pull request cada uma. Elas trabalham em ramificações próprias e são mescladas em uma ramificação de lane; essa ramificação é promovida como um único pull request contra sua ramificação base quando o trabalho estiver pronto.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Assim, você revisa o recurso montado de uma só vez, com toda a alteração visível, em vez de aprovar fases incompletas uma a uma.
Os planos entre projetos são a exceção: uma tarefa pertencente a um projeto diferente da lane é promovida separadamente, então você obtém um pull request por repositório. Um pull request não pode abranger dois repositórios.
Fases e paralelismo
As fases definem ordem, não concorrência. As tarefas dentro de uma fase podem ser executadas em paralelo se a capacidade permitir; a fase seguinte aguarda a conclusão da atual.
Um plano com dez tarefas compatíveis com paralelismo e apenas uma vaga de agente ainda as executará uma de cada vez. A estrutura não cria capacidade — veja Capacidade e vagas de agente.
Plano ou tarefa?
Você decide, ao escolher Plano de trabalho em fases ou Uma tarefa executável na etapa de roteamento. Nada analisa seu pedido e decide por você.
O critério é a capacidade de revisão: um pull request que um colega possa ler de uma só vez é uma tarefa; qualquer coisa que exija várias alterações ordenadas constitui um plano.
Adotar uma tarefa para um trabalho realmente grande é o erro mais arriscado — a tarefa pode esgotar seu espaço no meio do caminho, desperdiçando a execução. Escolher um plano implica em uma etapa de aprovação desnecessária.
Portas de entrega
Um plano pode conter uma porta de entrega que define o que deve estar certo antes que seu resultado avance. Veja Portas de qualidade.