Diretrizes de fluxo cumulativo, prazo de entrega e tempo de ciclo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Você usa diagramas de fluxo cumulativos (CFD) para monitorar o fluxo de trabalho através de um sistema. As duas métricas principais a serem rastreadas, tempo de ciclo e lead time, podem ser extraídas do gráfico. Para configurar ou exibir gráficos CFD, consulte Configurar um fluxograma cumulativo.

Ou, você pode adicionar os gráficos de controle de tempo de execução e tempo de ciclo aos seus painéis.

Gráficos de exemplo e métricas primárias

O CFD de fluxo contínuo fornece o gráfico mais favorecido pelas equipes que seguem um processo enxuto.

No entanto, muitas equipes começaram a combinar práticas lean com Scrum ou outras metodologias, o que significa que praticam o lean dentro do período de uma iteração ou sprint. Nessa situação, o diagrama assume uma aparência ligeiramente diferente e fornece duas informações adicionais e muito valiosas, conforme mostrado no próximo gráfico.

Fluxo contínuo

O CFD de período fixo mostrado aqui é para um sprint concluído.

A linha superior representa o escopo definido para o sprint. E, como o trabalho deve ser concluído até o último dia do sprint, a inclinação do estado Fechado indica se uma equipe está ou não no caminho certo para completar o sprint. A maneira mais fácil de pensar nessa exibição é como um gráfico de burnup.

Os dados são sempre representados com a primeira etapa do processo como a parte superior esquerda e a última etapa do processo como a parte inferior direita.

CFD de período fixo para um sprint concluído

Métricas de gráfico

Os gráficos CFD exibem a contagem de itens de trabalho agrupados por estado/coluna Kanban ao longo do tempo. As duas métricas principais a serem rastreadas, tempo de ciclo e lead time, podem ser extraídas do gráfico.

---

Métrica

Definição

---

Tempo^{de ciclo 1}

Mede o tempo necessário para mover o trabalho por um único processo ou estado de fluxo de trabalho. O cálculo é do início de um processo até o início do próximo processo.

Prazo de execução¹

Para um processo de fluxo contínuo: mede a quantidade de tempo que leva desde quando uma solicitação é feita (como adicionar uma história de usuário proposta) até que a solicitação seja concluída (fechada).

Para um processo de sprint ou período fixo: mede o tempo desde quando o trabalho em uma solicitação começa até que o trabalho seja concluído (ou seja, o tempo de Ativo para Fechado).

Trabalho em Andamento

Mede a quantidade de trabalho ou o número de itens de trabalho que estão sendo trabalhados ativamente.

Escopo

Representa a quantidade de trabalho comprometido para o período de tempo determinado. Aplica-se apenas a processos por período fixo.

---

1 O widget CFD (Analytics) e o gráfico CFD integrado (armazenamento de dados de acompanhamento de trabalho) não fornecem números discretos em Lead Time e Cycle Time. No entanto, os widgets Lead Time e Cycle Time fornecem esses números.

Há uma correlação bem definida entre Lead Time/Cycle Time e Work in Progress (WIP). Quanto mais WIP, maior o tempo de ciclo, o que também leva a prazos de entrega mais longos. O oposto também é verdadeiro: quanto menos WIP, menor o ciclo e o lead time. Quando a equipe de desenvolvimento se concentra em menos itens, eles reduzem o ciclo e os prazos de entrega. Essa correlação é um dos principais motivos pelos quais você pode e deve definir limites de Trabalho em Andamento no quadro Kanban.

A contagem de itens de trabalho indica a quantidade total de trabalho em um determinado dia. Em um CFD de período fixo, uma alteração nessa contagem indica mudança de escopo para um determinado período. Em um CFD de fluxo contínuo, ele indica a quantidade total de trabalho na fila e concluído para um determinado dia.

A decomposição do trabalho em colunas específicas do quadro Kanban fornece uma exibição de onde o trabalho está em processo. Essa visão fornece insights sobre onde o trabalho está se movendo sem problemas, onde há bloqueios e onde nenhum trabalho está sendo feito. É difícil decifrar uma visão tabular dos dados, no entanto, o gráfico CFD visual fornece evidências de que algo está acontecendo de uma determinada maneira.

Identificar problemas, tomar as ações apropriadas

O CFD responde a várias perguntas específicas e, com base na resposta, ações podem ser tomadas para ajustar o processo para mover o trabalho através do sistema. Vejamos cada uma dessas perguntas aqui.

A equipe concluirá o trabalho a tempo?

Esta pergunta aplica-se apenas a CFDs de período fixo. Você ganha uma compreensão observando a curva (ou progressão) do trabalho na última coluna do quadro Kanban.

Nesse cenário, pode ser apropriado reduzir o escopo do trabalho na iteração se estiver claro que o trabalho, em um ritmo constante, não está sendo concluído com rapidez suficiente. Isso pode indicar que o trabalho foi subestimado e deve ser levado em consideração no planejamento dos próximos sprints.

No entanto, pode haver outras razões que podem ser determinadas olhando para outros dados no gráfico.

Como está o fluxo de trabalho?

A equipe está concluindo o trabalho em um ritmo constante? Uma maneira de saber é observar o espaçamento entre as diferentes colunas no gráfico. Eles têm uma distância semelhante ou uniforme um do outro do início ao fim? Uma coluna parece ter uma linha plana durante um período de vários dias? Ou parece "protuberância"?

Mura, termo enxuto para linhas planas e protuberâncias, significa desnível e indica uma forma de desperdício (Muda) no sistema. Qualquer desnível no sistema fará com que protuberâncias apareçam no CFD.

O monitoramento do CFD para linhas planas e protuberâncias suporta uma parte fundamental do processo de gerenciamento de projetos da Teoria das Restrições. A proteção da área mais lenta do sistema é conhecida como o processo tambor-tampão-corda e faz parte de como o trabalho é planejado.

Dois problemas aparecem visualmente como linhas planas e como protuberâncias.

As linhas planas aparecem quando a equipe não atualiza seu trabalho com uma cadência regular. O quadro Kanban fornece a maneira mais rápida de fazer a transição de trabalho de uma coluna para outra.
As linhas planas também podem aparecer quando o trabalho em um ou mais processos leva mais tempo do que o planejado. Linhas planas aparecem em muitas partes do sistema porque se apenas uma parte do sistema ou duas partes de um sistema tiverem problemas, você verá uma protuberância.

Linhas planas

As protuberâncias ocorrem quando o trabalho se acumula em uma parte do sistema e não está se movendo através de um processo.
Por exemplo, uma protuberância pode ocorrer quando o teste leva um longo período de tempo, enquanto o desenvolvimento leva um período mais curto de tempo, fazendo com que o trabalho se acumule no estado de desenvolvimento (protuberâncias indicam que uma etapa subsequente está tendo um problema, não necessariamente a etapa em que a protuberância está ocorrendo).

Protuberâncias

Como corrigir problemas de fluxo?

Você pode resolver o problema da falta de atualizações oportunas através de:

• Stand-ups diários.
• Outras reuniões periódicas.
• Agendar um e-mail de lembrete diário da equipe.

Problemas sistêmicos de linha plana indicam um problema mais desafiador, embora tais problemas sejam raros. As linhas planas indicam que o trabalho em todo o sistema foi interrompido. As causas subjacentes podem ser:

• Bloqueios em todo o processo.
• Processos demorados.
• Trabalho mudando para outras oportunidades que não são capturadas no quadro.

Um exemplo de linha plana sistêmica pode ocorrer com um CFD de características. O trabalho de recursos pode levar muito mais tempo do que o trabalho em histórias de usuários, porque os recursos são compostos por várias histórias. Nessas situações, ou a inclinação é esperada (como no exemplo acima) ou a questão é bem conhecida e já está sendo levantada pela equipe como um problema. Se for um problema conhecido, a resolução do problema está fora do escopo deste artigo.

As equipes podem corrigir proativamente problemas que aparecem como protuberâncias de CFD. Dependendo de onde a protuberância ocorre, a correção pode ser diferente. Como exemplo, vamos supor que a protuberância ocorra no processo de desenvolvimento. A protuberância pode estar acontecendo porque a execução de testes está demorando muito mais do que escrever código. Os testadores também podem estar encontrando um grande número de bugs. Quando eles continuamente fazem a transição do trabalho de volta para os desenvolvedores, os desenvolvedores herdam uma lista crescente de trabalho ativo.

Duas maneiras potencialmente fáceis de resolver esse problema são: 1) Mudar os desenvolvedores do processo de desenvolvimento para o processo de teste até que a protuberância seja eliminada ou 2) alterar a ordem do trabalho de modo que o trabalho que pode ser feito rapidamente seja entrelaçado com o trabalho que leva mais tempo para ser feito. Procure soluções simples para eliminar as protuberâncias.

Observação

Como podem ocorrer muitos cenários diferentes que fazem com que o trabalho prossiga de forma desigual, é fundamental que você realize uma análise real do problema. O CFD irá dizer-lhe que há um problema e aproximadamente onde ele está, mas você deve investigar para chegar à(s) causa(s) raiz(s). As orientações fornecidas aqui indicam ações recomendadas que resolvem problemas específicos, mas que podem não se aplicar à sua situação.

O escopo mudou?

As alterações de escopo aplicam-se apenas a CFDs de período fixo. A linha superior do gráfico indica o escopo do trabalho. Um sprint é pré-carregado com o trabalho a ser feito no primeiro dia. As alterações na linha superior indicam que o trabalho foi adicionado ou removido.

O único cenário em que você não pode controlar as alterações de escopo com um CFD ocorre quando o mesmo número de itens de trabalho é adicionado como removido no mesmo dia. A linha continuaria plana. Compare vários gráficos entre si. Monitore os problemas específicos. Use Exibir/configurar burndown de sprint para monitorar alterações de escopo.

Muito WIP?

Você pode monitorar facilmente se os limites de WIP foram excedidos a partir do quadro Kanban. Você também pode monitorá-lo a partir do CFD.

Uma grande quantidade de WIP geralmente aparece como uma protuberância vertical. Quanto mais tempo houver uma grande quantidade de WIP, mais a protuberância se expandirá para se tornar um oval. É uma indicação de que o WIP está afetando negativamente o ciclo e o lead time.

Aqui está uma boa regra prática para obras em andamento. Não deve haver mais de dois itens em andamento por membro da equipe em um determinado momento. A principal razão para dois itens versus limites mais rígidos é porque a realidade frequentemente invade qualquer processo de desenvolvimento de software.

Às vezes, leva tempo para obter informações de uma parte interessada, ou leva mais tempo para adquirir o software necessário. Há várias razões pelas quais o trabalho pode ser interrompido. Ter um segundo item de trabalho para pivotar fornece alguma margem de manobra. Se ambos os itens forem bloqueados, é hora de levantar uma bandeira vermelha para que algo seja desbloqueado — e não apenas mudar para outro item. Assim que houver um grande número de itens em andamento, a pessoa que trabalha nesses itens terá dificuldade para mudar de contexto. É mais provável que eles esqueçam o que estavam fazendo, e erros podem ocorrer.

Lead time versus tempo de ciclo

O diagrama abaixo ilustra como o lead time difere do tempo de ciclo. O prazo de entrega é calculado desde a criação do item de trabalho até a entrada em um estado Concluído. O tempo de ciclo é calculado desde a primeira inserção de uma categoria de estado Em Andamento ou Resolvido até a inserção de uma categoria de estado Concluído .

Ilustração de lead time versus tempo de ciclo

Se um item de trabalho entrar em um estado Concluído e, em seguida, for reativado, qualquer tempo extra gasto em um estado Proposto, Em andamento ou Resolvido contribuirá para seu tempo de espera/ciclo quando entrar em uma categoria de estado Concluído pela segunda vez.

Se sua equipe usa o quadro Kanban, convém entender como suas colunas Kanban são mapeadas para estados de fluxo de trabalho. Para obter mais informações sobre como configurar seu quadro Kanban, consulte Adicionar colunas.

Para saber mais sobre como o sistema usa as categorias de estado — Proposto, Em andamento, Resolvido e Concluído — consulte Estados e categorias de estado do fluxo de trabalho.

Planeje usando prazos de entrega estimados com base em tempos de lead/ciclo

Você pode usar os tempos médios de lead/ciclo e os desvios padrão para estimar os tempos de entrega.

Ao criar um item de trabalho, você pode usar o tempo médio de execução da sua equipe para estimar quando ela concluirá esse item de trabalho. O desvio padrão da sua equipe informa a variabilidade da estimativa. Da mesma forma, você pode usar o tempo de ciclo e seu desvio padrão para estimar a conclusão de um item de trabalho após o início do trabalho.

No gráfico a seguir, o tempo médio de ciclo é de oito dias. O desvio padrão é de +/- seis dias. Usando esses dados, podemos estimar que a equipe completará futuras histórias de usuários cerca de 2 a 14 dias após o início do trabalho. Quanto mais estreito o desvio padrão, mais previsíveis serão suas estimativas.

Exemplo de Widget de Tempo de Ciclo

Identificar problemas de processo

Revise o gráfico de controle da sua equipe para verificar se há valores atípicos. Os outliers geralmente representam um problema subjacente ao processo. Por exemplo, esperar muito tempo para concluir revisões de RP ou não resolver uma dependência externa rapidamente.

Como você pode ver no gráfico a seguir, que mostra vários outliers, vários bugs levaram mais tempo para serem concluídos do que a média da equipe. Investigar por que esses bugs demoraram mais pode ajudar a descobrir problemas de processo. Resolver os problemas do processo pode ajudar a reduzir o desvio padrão da sua equipe e melhorar a previsibilidade da sua equipe.

Exemplo de widget Tempo de Ciclo mostrando vários outliers

Você também pode ver como as alterações de processo afetam seu lead e o tempo de ciclo. Por exemplo, em 15 de maio, a equipe fez um esforço concentrado para limitar o WIP e resolver bugs obsoletos. Você pode ver que o desvio padrão diminui após essa data, mostrando melhor previsibilidade.

Próximas etapas

Configurar seus fluxogramas cumulativos ou Configurar um gráfico de tempo de execução ou de ciclo