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 cumulativo (CFD) para monitorar o fluxo de trabalho através de um sistema. As duas principais métricas a serem rastreadas, tempo de ciclo e tempo de espera, podem ser extraídas do gráfico. Para configurar ou exibir gráficos de CFD, consulte Configurar um fluxograma cumulativo.
Ou você pode adicionar os gráficos de controle Lead time e cycle time aos seus painéis.
Gráficos de exemplo e métricas principais
O CFD de fluxo contínuo fornece o gráfico mais favorecido pelas equipes que seguem um processo lean.
No entanto, muitas equipes começaram a combinar práticas lean com Scrum ou outras metodologias, o que significa que elas praticam 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 concluir 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 o canto superior esquerdo e a última etapa do processo como o canto inferior direito.
CFD de período fixo para um sprint concluído
Métricas do gráfico
Os gráficos CFD exibem a contagem de itens de trabalho agrupados por estado/coluna ao longo do tempo. As duas principais métricas a serem rastreadas, tempo de ciclo e tempo de espera, 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 meio de um único processo ou estado de fluxo de trabalho. O cálculo é do início de um processo ao início do próximo processo.
Prazo de execução 1
Para um processo de fluxo contínuo: mede o tempo que leva desde o momento em que 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 o início do trabalho em uma solicitação até a conclusão do trabalho (ou seja, o tempo de Ativo a 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 confirmada para um determinado período de tempo. Aplica-se apenas a processos de período fixo.
1 O widget CFD (Analytics) e o gráfico CFD integrado (armazenamento de dados de rastreamento de trabalho) não fornecem números discretos sobre o tempo de entrega e o tempo de ciclo. No entanto, os widgets Lead Time e Cycle Time fornecem esses números.
Há uma correlação bem definida entre o Lead Time/Cycle Time e o 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 tempo de espera. 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 os limites de trabalho em andamento no quadro.
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, indica a quantidade total de trabalho na fila e concluído em um determinado dia.
A decomposição do trabalho em colunas de quadro específicas fornece uma exibição de onde o trabalho está em andamento. Essa exibiçã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.
Identifique problemas, tome as medidas 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 pelo sistema. Vejamos cada uma dessas questões aqui.
A equipe concluirá o trabalho a tempo?
Esta pergunta se aplica apenas a CFDs de período fixo. Você obtém uma compreensão observando a curva (ou progressão) do trabalho na última coluna do quadro.
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 observando outros dados no gráfico.
Como está progredindo 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 do gráfico. Eles estão a uma distância semelhante ou uniforme um do outro do começo ao fim? Uma coluna parece plana durante um período de vários dias? Ou parece "inchar"?
Mura, o termo magro para linhas planas e protuberâncias, significa desnível e indica uma forma de desperdício (Muda) no sistema. Qualquer irregularidade no sistema fará com que apareçam protuberâncias 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. Proteger a área mais lenta do sistema é chamado de processo tambor-buffer-corda e faz parte de como o trabalho é planejado.
Dois problemas aparecem visualmente como linhas planas e protuberâncias.
As linhas planas aparecem quando a equipe não atualiza seu trabalho com uma cadência regular. O quadro fornece a maneira mais rápida de fazer a transição do 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 por 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 de tempo mais curto, 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 você corrige problemas de fluxo?
Você pode resolver o problema da falta de atualizações oportunas por meio de:
- Stand-ups diários.
- Outras reuniões regulares.
- Agendamento de 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 parou. 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 recursos. 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 de várias histórias. Nessas situações, ou a inclinação é esperada (como no exemplo acima) ou o problema é bem conhecido e já está sendo levantado 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 ocorre a protuberância, 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 fazem a transição contínua 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ê execute uma análise real do problema. O CFD dirá que há um problema e aproximadamente onde ele está, mas você deve investigar para chegar à(s) causa(s) raiz(is). 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 se aplicam 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 acompanhar as alterações de escopo com um CFD ocorre quando o mesmo número de itens de trabalho é adicionado e 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 as alterações de escopo.
Muito WIP?
Você pode monitorar facilmente se os limites de WIP foram excedidos na placa. 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 oval. É uma indicação de que o WIP está afetando negativamente o ciclo e o tempo de espera.
Aqui está uma boa regra para trabalhos em andamento. Não deve haver mais de dois itens em andamento por membro da equipe a qualquer momento. A principal razão para dois itens versus limites mais rígidos é porque a realidade freqüentemente se intromete em 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. Existem várias razões pelas quais o trabalho pode ser interrompido. Ter um segundo item de trabalho para girar fornece alguma margem de manobra. Se ambos os itens estiverem bloqueados, é hora de levantar uma bandeira vermelha para desbloquear algo - 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 em alternar o contexto. É mais provável que eles esqueçam o que estavam fazendo e erros possam ocorrer.
Lead time versus tempo de ciclo
O diagrama abaixo ilustra como o lead time difere do tempo de ciclo. O lead time é 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 do tempo de espera 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 avanço/ciclo quando ele entrar em uma categoria de estado Concluído pela segunda vez.
Se sua equipe usa o quadro, você vai querer entender como suas colunas são mapeadas para os estados do fluxo de trabalho. Para obter mais informações sobre como configurar seu quadro, consulte Adicionar colunas.
Para obter mais informações sobre como o sistema usa as categorias de estado — Proposto, Em andamento, Resolvido e Concluído — consulte Estados de fluxo de trabalho e categorias de estado.
Planejar usando prazos de entrega estimados com base em prazos de entrega/ciclo
Você pode usar os tempos médios de avanço/ciclo e desvios padrão para estimar os prazos de entrega.
Ao criar um item de trabalho, você pode usar o tempo médio de entrega da sua equipe para estimar quando sua equipe concluirá esse item de trabalho. O desvio padrão da sua equipe informa a variabilidade da estimativa. Da mesma forma, é possível usar o tempo de ciclo e seu desvio padrão para estimar a conclusão de um item de trabalho depois que o trabalho for iniciado.
No gráfico a seguir, o tempo médio do ciclo é de oito dias. O desvio padrão é de +/- seis dias. Usando esses dados, podemos estimar que a equipe concluirá 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
Identifique problemas de processo
Revise o gráfico de controle da sua equipe em busca de valores discrepantes. Os valores discrepantes geralmente representam um problema de processo subjacente. Por exemplo, esperar muito tempo para concluir as revisões de PR 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 no processo. Resolver os problemas do processo pode ajudar a reduzir o desvio padrão de sua equipe e melhorar a previsibilidade de sua equipe.
Exemplo de widget de tempo de ciclo mostrando vários valores discrepantes
Você também pode ver como as mudanças no processo afetam seu lead e tempo de ciclo. Por exemplo, em 15 de maio, a equipe fez um esforço conjunto para limitar o WIP e resolver bugs obsoletos. Você pode ver que o desvio padrão diminui após essa data, mostrando maior previsibilidade.