Cycle time

A maioria dos times de engenharia acha que tem um problema de entrega quando, na verdade, tem um problema de visibilidade. O cycle time, que é o tempo total para mover uma unidade de trabalho do desenvolvimento ativo até a produção, é um dos sinais mais claros de quão eficiente é o seu pipeline de entrega. Quando os squads não medem isso, lançamentos lentos parecem um problema de pessoas, não de processo. Esta página cobre a definição de cycle time, como medi-lo, o que é considerado bom, como melhorá-lo e como o DevStats o expõe automaticamente.

• O cycle time é o tempo decorrido entre quando uma unidade de trabalho entra em desenvolvimento ativo e quando chega à produção. Importa porque reflete diretamente a velocidade e a saúde do seu processo de entrega, não apenas o quanto o seu squad está ocupado.
• O cycle time é calculado como: Cycle Time = Data de Conclusão menos Data de Início, medido por item de trabalho. De acordo com o Relatório State of DevOps 2023 do DORA, times de alto desempenho alcançam um lead time para mudanças (uma medida intimamente relacionada) de menos de um dia, enquanto os de baixo desempenho levam entre uma semana e um mês.
• O erro mais comum dos times é confundir um cycle time longo com um problema de produtividade e pressionar por mais output. Um cycle time longo geralmente sinaliza um gargalo de processo, como revisão de código lenta, PRs grandes ou handoffs bloqueados, não falta de esforço dos players individualmente.
• O DevStats rastreia o cycle time automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks comparando mais de 1.000 times de engenharia. Você pode ver o detalhamento do PR cycle time e o issue cycle time em uma única tela. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de cycle time

O cycle time é o tempo total decorrido desde quando o trabalho ativo começa em uma tarefa até quando esse trabalho é entregue em produção. Ele mede a velocidade do seu processo de entrega, não o tempo que um ticket fica esperando para ser pego.

Para times de software, o cycle time é calculado como: Cycle Time = Data de Entrega menos Data de Início do Trabalho, medido por pull request ou issue. Ele usa dados do seu provedor Git e do seu issue tracker. Quando o cycle time é longo, sinaliza atrito em algum ponto do pipeline: filas de revisão, gargalos de deployment ou critérios de aceitação pouco claros. Cycle times menores se correlacionam com loops de feedback mais rápidos e cronogramas de lançamento mais previsíveis, dois fatores que importam para os stakeholders de negócio, não só para a engenharia.

Por que o cycle time importa para times de engenharia

Quando os squads não rastreiam o cycle time, as lentidões nas entregas ficam invisíveis até virarem compromissos de sprint perdidos ou lançamentos de produto atrasados. Um time pode parecer ocupado enquanto o trabalho se acumula em revisão, fica bloqueado em uma dependência ou espera dias por uma janela de deployment. Sem os dados, você gerencia por intuição, não por sinal.

O cycle time se conecta diretamente aos KPIs pelos quais os líderes de engenharia são responsáveis: entrega no prazo, previsibilidade de releases e throughput do time. Ele também se relaciona com o framework DORA, onde "lead time for changes" é uma das quatro métricas centrais de desempenho de entrega. Times que monitoram ativamente o cycle time conseguem identificar onde o trabalho para antes que isso vire um padrão. Se você está olhando para DORA metrics como parte do seu programa de saúde de engenharia, o cycle time é um dos primeiros lugares para começar. Você pode explorar como o DevStats expõe esses sinais na página de DORA metrics.

A medição é o ponto de partida. Quando você sabe para onde o tempo está indo de verdade, toma uma decisão informada sobre o que mudar. Os dados não consertam nada. Você conserta.

Como medir o cycle time

O cycle time começa quando um player faz o primeiro commit ou move um ticket para "em andamento" e termina quando esse trabalho vai para produção. Você precisa de pelo menos duas fontes de dados: seu provedor Git (GitHub, GitLab, Bitbucket) e seu issue tracker (Jira, Linear, GitHub Issues). Se quiser incluir a confirmação de deployment, também vai precisar dos dados do seu pipeline de CI/CD.

Os benchmarks abaixo são baseados no Relatório State of DevOps 2023 do DORA para lead time de mudanças, que é o benchmark publicado mais próximo do cycle time. Os benchmarks exatos de cycle time variam conforme o tamanho do time, a complexidade do codebase e o modelo de release. Use esses números como referência direcional, não como metas fixas. O DevStats oferece benchmarks entre pares com base em times comparáveis para você calibrar com contexto relevante.

Para uma visão mais granular, divida o cycle time em suas sub-etapas: tempo de codificação, tempo de code review e tempo de deployment. Esse detalhamento mostra exatamente onde o tempo está sendo perdido.

Cycle time na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a velocidade do sprint parecia estável, mas o time continuava perdendo as metas de release. Ela puxou os dados de cycle time e descobriu que os PRs ficavam em revisão por uma média de quatro dias antes de receber uma primeira resposta. A fase de codificação era rápida. O gargalo estava inteiramente na fila de revisão.

Ela fez uma mudança estrutural: o squad concordou com um SLA de primeira revisão em 24 horas, e ela incluiu a revisão de código na daily standup como item fixo de pauta. Nos dois sprints seguintes, o cycle time médio caiu cerca de 40%. Ela acompanhou o PR cycle time e as taxas de conclusão de sprint semana a semana para confirmar que a melhora se manteve. Os dados disseram onde olhar. Ela decidiu o que fazer.

Como melhorar o cycle time

1. Reduza o tamanho dos PRs. Pull requests grandes demoram mais para revisar e mais para fazer merge com segurança. Defina uma norma de tamanho de PR para o time, geralmente menos de 400 linhas alteradas, e veja o tempo de revisão cair. Acompanhe o tamanho médio dos PRs junto com o PR cycle time para ver a correlação nos seus próprios dados.

2. Defina um SLA de revisão e cumpra. Se os PRs ficam sem revisão por mais de 24 horas, o cycle time aumenta independentemente de quão rápido os players escrevem código. Combine uma janela de primeira resposta e deixe a profundidade da fila de revisão visível nas standups.

3. Faça uma auditoria do seu pipeline de deployment. Se o deployment em si leva horas ou exige etapas manuais, o cycle time será longo mesmo quando o código estiver pronto. Identifique a etapa mais lenta no seu pipeline de CI/CD e direcione esforços de automação para ela. O DevStats expõe a frequência e velocidade de deployment para você ver se o deployment é o gargalo.

4. Quebre issues grandes antes do início do sprint. Tickets muito amplos criam cycle times longos porque os players precisam interpretar o escopo no meio do sprint. Melhorar a precisão do planejamento antes do sprint reduz a ambiguidade que infla o cycle time depois.

5. Fique de olho em padrões de trabalho bloqueado. Se o cycle time é longo mas o tempo de codificação é curto, o tempo está sendo perdido em espera, não em trabalho. Use um activity heatmap para identificar quando e onde o trabalho para ao longo da semana.

Cycle time vs. lead time

O cycle time e o lead time são relacionados, mas medem janelas diferentes. O lead time começa quando uma solicitação é criada, antes do trabalho começar. O cycle time começa quando o trabalho ativo começa. Confundir os dois leva a diagnósticos errados: um lead time longo pode indicar um problema de priorização, enquanto um cycle time longo indica um problema no processo de entrega.

Use o lead time ao reportar para stakeholders sobre capacidade de resposta geral. Use o cycle time ao diagnosticar o que está travando o processo de entrega do seu squad.