Lead time de entrega quase nunca trava no compile. Trava no pull request aberto, no revisor em reunião, no lote de trezentas linhas, no “olho amanhã”. O pipeline verde mede a máquina. DORA honesto mede a fila humana. Se o planning só olha o build, o número mente.

DevOps e entrega contínua já pediu lote pequeno. Este texto é o gargalo de maio: review. Daily que não terceiriza impedimento deveria falar do PR de três dias. Deploy na sexta piora quando o review empurra o merge para o fim da semana.

Onde o relógio realmente anda

Defina lead time do “PR pronto para review” até produção — ou do primeiro commit da fatia, mas aí separe espera de coding. Misturar os dois esconde o review. Time que “codifica rápido” e entrega lento está no review ou no ambiente. Compile é o suspeito mais inocente.

Sinais:

  • mediana de tempo em “aguardando review” maior que em “CI”;
  • PRs grandes demais para leitura honesta;
  • um único aprovador;
  • review só no fim do sprint.

Agente que gera patch enorme piora o gargalo. Recusar tamanho é política de lead time, não de gosto.

O que cabe no sprint sem “projeto de cultura”

  • SLA de first response no PR (horas, não “quando der”);
  • limite de arquivos ou de linhas;
  • pair nas fatias arriscadas em vez de review teatro;
  • dois aprovadores só onde o risco pede — não em todo typo.

Não inventamos o número de horas da sua empresa. Combinem na retro e meçam duas semanas. Se não medir, o SLA é slogan.

Review e medo

Review lento às vezes é medo de produção: ninguém quer ser o nome no merge da sexta. Aí o problema não é o GitHub. É rollback e dono de serviço. Trate os dois. Encurtar review sem rede de segurança só move o medo para o incidente.

Duas pessoas no notebook da capa não estão “perdendo tempo”. Estão tirando o PR da fila que o compile nunca viu. SLA de first response em horas, lote lível, pair no que é arriscado. Agente que gera trezentas linhas é o inimigo desse SLA — recuse o tamanho no DoD. Lead time honesto começa nessa recusa, não num plugin de DORA.

Como a Tech Coders trata lead time na fábrica

Na fábrica de software, lead time entra no sprint de 15 dias como fila de PR: tamanho, SLA, pair. Pipeline é o básico. O quadro mostra a espera humana. Sustentação 24×7 não espera review de três dias para hotfix — e o rito de hotfix não deveria ser o único jeito de mergear rápido.

Perguntas frequentes

CI mais rápido resolve lead time?

Resolve a parte da máquina. Se a mediana está no review, CI mais rápido quase não mexe o DORA. Meça a fila.

PR pequeno demais não vira overhead?

Vira se a fatia não tem sentido. O teto é “lível em uma sessão”. Trezentas linhas de agente não são sessão. Vinte PRs de uma linha de formatação também não — agrupe com critério.

Posso mandar o agente revisar o PR?

Como linter, sim. Como único aprovador, não. Lead time não é desculpa para merge sem entendimento.

Daily deve listar PRs abertos?

Deve listar o impedimento: “PR X há três dias”. Lista automática ajuda. Fala humana combina a ação.