O Ritmo de Caracol dos Pull Requests
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
O Ritmo de Caracol dos Pull Requests
Esse post faz parte de uma mini série sobre os desafios de trabalhar com feature branching. Você pode encontrar a introdução da série aqui.
A velocidade de mudança para times de entrega de produto continua aumentando. Empresas estão fazendo deploy várias vezes ao dia. Estão testando em produção e iterando rápido para lançar novas funcionalidades de produto.
Enquanto isso, quando você olha para um time de engenharia, há uma quantidade significativa de tempo onde o trabalho está simplesmente ali, esperando.
Conforme a indústria converge para times eficientes, uma das métricas mais importantes em entrega de software é o lead/cycle time. Essa métrica é conhecida em Sistemas de Produção Lean há muitos anos e está ganhando força na área de tecnologia. O recém-lançado livro Accelerate na verdade o coloca dentro das 4 principais métricas com as quais devemos nos preocupar.
Lead/cycle time faz sentido. O objetivo do desenvolvimento de software iterativo é entregar funcionalidades do início ao fim o mais rápido possível. Quanto tempo leva para mover algo da ideia à produção é a principal coisa com a qual um time deveria se preocupar.
Além disso, se terminamos o trabalho rapidamente, temos menos trabalho em progresso. Isso leva a menos troca de contexto e dá aos negócios mais opções para mudar de direção rapidamente. Tudo se acumula em mais produtividade.
Mas, em vez disso, minha experiência com times de software recentes tem sido majoritariamente assim:
Linha do tempo de uma funcionalidade real
O gráfico acima mostra uma funcionalidade real que foi entregue por um time com o qual trabalhei recentemente. Levou 56 horas para ficar pronta para ser lançada, mas dessas, apenas 27 foram realmente codificando/revisando. E por 29 horas (51% do tempo) aquele trabalho estava apenas esperando por múltiplas rodadas de revisão.
É um padrão. Um engenheiro termina de trabalhar em uma funcionalidade, submete um PR. Ele então vai trabalhar em outra coisa e várias horas depois aquele PR é revisado. Nesse ponto, o engenheiro original está no meio de algum outro trabalho. Muitas horas se passam novamente até ele voltar ao primeiro PR. Já se passou um dia e ele não lembra de todos os detalhes. Há uma discussão rápida sobre a revisão, ele corrige os comentários e submete outro PR.
E esse ciclo se repete. Uma, duas, três vezes. É tudo desperdício.