Software cycle time

A maioria dos líderes de engenharia sabe que os sprints estão atrasando, mas não consegue identificar onde o tempo está indo. O cycle time de software é o tempo decorrido desde quando um desenvolvedor começa a trabalhar ativamente em um item até quando esse trabalho vai para produção. Monitorá-lo dá ao seu squad um sinal claro sobre a velocidade de entrega e onde o trabalho trava. Esta página cobre a definição, como medi-lo, benchmarks do mercado, como melhorá-lo e como o DevStats faz isso automaticamente.

Pontos principais

• O cycle time de software é o tempo entre um desenvolvedor começar a trabalhar ativamente em uma tarefa e essa tarefa chegar à produção. É uma medida direta da eficiência do seu pipeline de entrega. Times que o monitoram de forma consistente identificam gargalos antes que eles virem datas perdidas ou perda de confiança dos stakeholders.
• O cycle time é calculado como o tempo decorrido desde o início do trabalho em progresso até o deployment em produção. Segundo o relatório DORA State of DevOps 2023, times de elite alcançam um change lead time (uma métrica diretamente relacionada) menor que um dia, enquanto times de baixo desempenho podem levar mais de seis meses. O seu benchmark de cycle time varia conforme o tamanho do time e o modelo de release, mas a direção é clara: menor é melhor.
• O erro mais comum dos times é confundir cycle time com lead time. O cycle time começa quando o desenvolvimento ativo inicia, não quando um ticket é criado ou solicitado pela primeira vez. Medir a partir da criação do ticket infla o número com o tempo de espera na fila, dificultando o diagnóstico de se o problema está no trabalho em si ou na priorização e no planejamento.
• O DevStats monitora o cycle time de software automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks comparando mais de 1.000 times de engenharia. Você vê os números do seu squad detalhados por etapa, incluindo codificação, revisão e deployment, sem nenhuma coleta manual de dados. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de cycle time de software

O cycle time de software é o tempo total decorrido desde quando um desenvolvedor começa a trabalhar ativamente em uma tarefa até quando esse trabalho é feito o deploy em produção. Ele exclui o tempo que o item passa esperando no backlog antes de o trabalho começar. Em termos simples: ele diz quanto tempo o seu time leva para terminar algo depois que começou.

A fórmula é direta: Cycle Time de Software = Timestamp do Deployment menos Timestamp do Início do Trabalho. As fontes de dados geralmente incluem o seu provedor Git (para o primeiro commit ou criação de branch), o seu issue tracker (para transições de status para "em progresso") e o seu pipeline de CI/CD (para os timestamps de deployment). Você pode monitorar isso no nível do pull request usando o PR cycle time ou no nível do issue usando o issue cycle time, dependendo da granularidade que você precisa. Quando o cycle time diminui, o seu time entrega valor aos clientes mais rápido e o negócio responde ao feedback do mercado em ciclos mais curtos.

Por que o cycle time de software importa para times de engenharia

Quando squads não monitoram o cycle time de software, os gargalos ficam invisíveis. O trabalho se acumula em revisão, os deployments viram releases arriscados em lote, e os compromissos do sprint escorregam sem que ninguém saiba exatamente por quê. Quando o problema aparece em uma retrospectiva, a causa raiz já tem dois ou três sprints de atraso. Líderes de engenharia que medem o cycle time enxergam os pontos de travamento em tempo real, antes que afetem a entrega do roadmap ou o moral do time.

O cycle time se conecta diretamente aos KPIs mais importantes para os seus stakeholders: entrega no prazo, previsibilidade de releases e throughput de engenharia. Ele também é um sinal central no framework DORA, que liga o desempenho de entrega a resultados organizacionais como receita e retenção de pessoas. Times que fazem ship em lotes menores e mais rápidos tendem a ter taxas de falha de mudança menores e se recuperam de incidentes mais rapidamente. Você pode ver como o cycle time se encaixa junto com a frequência de deployment e outras DORA metrics na página de DORA metrics do DevStats, que exibe as quatro métricas principais em uma só tela.

A medição é o ponto de partida, não o destino. Quando você tem dados confiáveis de cycle time, você como líder de engenharia decide o que eles significam para o seu time e o que mudar.

Como medir o cycle time de software

Para calcular o cycle time de software com precisão, você precisa de três pontos de dados: quando o trabalho ativo começou, quando o código foi mergeado e quando o deployment chegou à produção. A maioria dos times extrai o sinal de "trabalho iniciado" do primeiro commit em uma branch ou do timestamp em que um issue foi movido para "em progresso" no issue tracker. O ponto final é o timestamp do deployment em produção do seu pipeline de CI/CD. Combinar essas fontes dá uma visão completa de onde o tempo é gasto entre codificação, code review e deployment.

Não existe um único benchmark publicado que cubra o cycle time de software de forma universal, já que ele varia conforme o tamanho do time, a complexidade do código e o modelo de release. O relatório DORA State of DevOps 2023 usa o "change lead time" como proxy, que inclui o cycle time como componente principal. A tabela abaixo usa as faixas de lead time do DORA como guia direcional. Você pode comparar os números do seu squad com outros times usando os benchmarks do DevStats, que usam dados de mais de 1.000 times de engenharia.

Fonte: DORA State of DevOps 2023. Essas faixas se aplicam ao change lead time conforme definido pelo DORA. A sua medição de cycle time pode variar dependendo de onde você define o início da contagem.

Cycle time de software na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que os compromissos de sprint eram cumpridos consistentemente em torno de 70% de conclusão. Ela extraiu dados de cycle time segmentados por etapa e descobriu que o tempo de codificação estava estável em aproximadamente um dia por ticket, mas a etapa de revisão até o merge estava com média de quatro dias. Os dados mostraram que os PRs ficavam sem revisão por longos períodos, não porque os players eram revisores lentos, mas porque as solicitações de revisão chegavam durante blocos de codificação de alta concentração sem uma rotação clara de responsabilidade.

Ela introduziu uma norma no squad: todo PR aberto com mais de 24 horas recebe um revisor nomeado no daily standup. Ela também definiu uma meta de trazer o cycle time mediano de PR abaixo de dois dias nos próximos dois sprints. Quatro semanas depois, o cycle time caiu e a taxa de conclusão do sprint subiu. Os dados mostraram onde olhar. Ela decidiu o que fazer.

Como melhorar o cycle time de software

1. Reduza o tamanho dos PRs. Pull requests grandes demoram mais para revisar e têm mais chance de gerar vai e vem. Defina uma norma de tamanho de PR no squad, como menos de 400 linhas de código alterado, e monitore se PRs menores se correlacionam com tempos de merge mais rápidos. Acompanhe o seu throughput junto com o tamanho dos PRs para confirmar que lotes menores também aumentam o volume de trabalho entregue.
2. Defina SLAs explícitos de revisão. Se PRs ficam sem revisão por mais de 24 horas, o cycle time aumenta sem que ninguém escreva uma linha de código. Combine uma janela de resposta de revisão como squad e exponha PRs parados no seu daily standup. Isso é uma mudança de processo, não um julgamento de desempenho.
3. Automatize o seu pipeline de deployment. Etapas manuais de deployment adicionam horas ou dias ao cycle time depois que o código já foi mergeado. Audite o seu pipeline de deployment em busca de gates manuais e substitua-os por verificações automatizadas onde possível. O objetivo é tornar o deploy algo chato e rotineiro.
4. Quebre o trabalho em issues menores. Se os issues rotineiramente levam mais de uma semana para concluir, o trabalho provavelmente é grande demais. Decomponha epics em tarefas que um player consiga entregar em um ou dois dias. Isso também facilita a melhora da acurácia do planejamento, já que itens menores são mais fáceis de estimar.
5. Revise a alocação do seu sprint. O cycle time frequentemente aumenta quando os players fazem context-switching entre workstreams paralelos demais. Use dados de allocation para ver como o tempo do seu squad está distribuído e se trabalho não planejado está engolindo os compromissos do sprint.

Cycle time de software vs. lead time

O cycle time de software e o lead time são relacionados, mas medem janelas diferentes do seu processo de entrega. O cycle time começa quando o desenvolvimento ativo inicia. O lead time começa quando uma solicitação ou ticket é criado pela primeira vez, incluindo todo o tempo que ele passa esperando em um backlog antes de alguém tocá-lo.

Use o cycle time para encontrar fricção dentro do seu processo de entrega e o lead time para entender a experiência completa do ponto de vista do cliente ou stakeholder. As duas métricas juntas dão uma visão completa de onde o tempo é perdido.