Tempo de ciclo


O Tempo de Ciclo é uma medida de quanto tempo leva para obter um novo recurso em um sistema de software program da ideia à execução em produção. Nos círculos Agile, tentamos minimizar o tempo de ciclo. Fazemos isso definindo e implementando recursos muito pequenos e minimizando atrasos no processo de desenvolvimento. Embora a noção aproximada de tempo de ciclo e a importância de reduzi-lo sejam comuns, há muitas variações em como o tempo de ciclo é medido.

Tempo de ciclo

Uma característica elementary do desenvolvimento ágil de software program é a mudança de uma
Processo em cascataonde o trabalho é decomposto com base na atividade (análise, codificação, teste) para um Processo Iterativo onde o trabalho é baseado em um subconjunto de funcionalidade (preço simples, desconto em massa, desconto para clientes valorizados). Fazer isso gera um loop de suggestions onde podemos aprender colocando pequenos recursos na frente dos usuários. Esse aprendizado nos permite melhorar nosso processo de desenvolvimento e nos permite entender melhor onde o produto de software program pode fornecer valor para nossos clientes.

Este suggestions é um benefício essencial de uma abordagem iterativa e, como a maioria desses ciclos de suggestions, quanto mais rápido eu recebo o suggestions, mais feliz eu fico. Assim, pessoas ágeis colocam muita ênfase em quão rápido podemos obter um recurso por todo o fluxo de trabalho e em produção. A frase tempo de ciclo é uma medida disso.

Mas aqui nos deparamos com dificuldades. Quando iniciamos e paramos o relógio no tempo do ciclo?

O tempo de parada é o mais fácil, mais fluente, é quando o recurso é colocado em produção e ajuda seus usuários. Mas há circunstâncias em que isso pode ficar confuso. Se uma equipe estiver usando um Lançamento Canáriodeveria ser quando usado pela primeira coorte, ou somente quando lançado para a população completa? Contamos somente quando a app retailer aprovou seu lançamento, adicionando assim um atraso imprevisível que está principalmente fora do controle da equipe de desenvolvimento?.

O horário de início tem ainda mais variações. Um marcador comum é quando um desenvolvedor faz um primeiro compromisso com esse recurso, mas isso ignora qualquer tempo gasto em análise preparatória. Muitas pessoas voltariam mais e diriam: “quando o cliente tem a ideia para um recurso pela primeira vez”. Tudo isso é muito bom para um recurso de alta prioridade, mas que tal algo que não é tão urgente e, portanto, fica em uma área de triagem por algumas semanas antes de estar pronto para entrar em desenvolvimento. Começamos o relógio quando a equipe coloca o recurso pela primeira vez na parede de cartões e começamos a trabalhar seriamente nele?

Eu também entro na fase tempo de esperaàs vezes em vez de “tempo de ciclo”, mas frequentemente juntos – onde as pessoas fazem uma distinção entre os dois, frequentemente com base em um horário de início diferente. No entanto, não há nenhuma consistência entre como as pessoas os distinguem. Então, em geral, eu trato “lead time” como um sinônimo de “tempo de ciclo”, e se alguém estiver usando ambos, eu me certifico de entender como esse indivíduo está fazendo a distinção.

As diferentes faixas de tempo de ciclo têm suas vantagens, e geralmente é útil usar faixas diferentes na mesma situação, para destacar as diferenças. Nessa situação, eu usaria um adjetivo distintivo (por exemplo, “tempo de ciclo do primeiro commit” vs “tempo de ciclo da ideia”) para diferenciá-los. Não há termos geralmente aceitos para tais adjetivos, mas acho que eles são melhores do que tentar criar uma distinção entre “tempo de ciclo” e “tempo de lead”.

O que essas perguntas nos dizem é que o tempo de ciclo, embora seja um conceito útil, é inerentemente escorregadio. Devemos ter cuidado ao comparar tempos de ciclo entre equipes, a menos que possamos ter certeza de que temos noções consistentes de seus tempos de parada e início.

Mas, apesar disso, pensar em termos de tempo de ciclo e tentar minimizá-lo é uma atividade útil. Geralmente vale a pena construir um mapa de fluxo de valor que mostre cada etapa da ideia à produção, identificando as etapas no fluxo de trabalho, quanto tempo é gasto nelas e quanto tempo de espera entre elas. Entender esse fluxo de trabalho nos permite encontrar maneiras de reduzir o tempo de ciclo. Duas intervenções comumente eficazes são reduzir o tamanho dos recursos e (contraintuitivamente) aumentar Folga. Trabalhar para entender o fluxo e melhorá-lo vale a pena porque quanto mais rápido colocamos as ideias em produção, mais rapidamente obtemos os benefícios dos novos recursos e recebemos o suggestions para aprender e melhorar nossas formas de trabalhar.

Agradecimentos

Andrew Harmel-Legislation, Chris Ford, James Lewis, José Pinar, Kief Morris, Manoj Kumar M, Matteo Vaccari e Rafael Ferreira discutiram esta publicação em nossa lista de discussão interna

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *