Orientação 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 métricas principais para acompanhar, tempo de ciclo e tempo de execução, podem ser extraídas do gráfico. Para configurar ou visualizar gráficos CFD, consulte Configurar um fluxograma cumulativo.
Ou, você pode adicionar os gráficos de controle de tempo de espera 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 lean.
No entanto, muitas equipes começaram a combinar práticas lean com Scrum ou outras metodologias, o que significa que praticam lean dentro do período de uma iteração ou sprint. Nesta situação, o diagrama assume uma aparência ligeiramente diferente e fornece duas informações adicionais e muito valiosas, conforme mostrado no gráfico seguinte.
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 visã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 do gráfico
Os gráficos CFD exibem a contagem de itens de trabalho agrupados por estado/coluna ao longo do tempo. As duas métricas principais para acompanhar, tempo de ciclo e tempo de execução, podem ser extraídas do gráfico.
Métricas
Definição
Tempo de Ciclo 1
Mede o tempo necessário para mover o trabalho através de um único processo ou estado de fluxo de trabalho. O cálculo é desde o início de um processo até o início do processo seguinte.
Prazo de execução 1
Para um processo de fluxo contínuo: mede o 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 o início do trabalho em uma solicitação até a conclusão do trabalho (ou seja, o tempo de Ativo para Fechado).
Trabalhos em Curso
Mede a quantidade de trabalho ou o número de itens de trabalho que estão sendo trabalhados ativamente.
Scope
Representa a quantidade de trabalho comprometido 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 incorporado (armazenamento de dados de acompanhamento de trabalho) não fornecem números discretos sobre 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 tempo de execução. Quando a equipe de desenvolvimento se concentra em menos itens, eles reduzem o ciclo e os prazos de entrega. Essa correlação é uma das principais razões pelas quais você pode e deve definir 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 mudança 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 fornece uma visão de onde o trabalho está em processo. Esta visão fornece informações sobre onde o trabalho está a avançar sem problemas, onde existem bloqueios e onde nenhum trabalho está a ser 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 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 através do sistema. Vejamos cada uma dessas perguntas aqui.
A equipa concluirá o trabalho a tempo?
Esta pergunta aplica-se 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 conta no próximo planejamento de sprints.
No entanto, pode haver outras razões que podem ser determinadas olhando para outros dados no gráfico.
Como está a evoluir o fluxo de trabalho?
A equipa está a concluir o trabalho a um ritmo constante? Uma maneira de saber é olhar para o espaçamento entre as diferentes colunas no gráfico. Estão a uma distância semelhante ou uniforme entre si do princípio ao fim? Uma coluna parece ser plana durante um período de vários dias? Ou parece "protuberância"?
Mura, o 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 as 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 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. As 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 ordinárias.
- Agendamento de um e-mail diário de lembrete da equipe.
Os problemas sistémicos de linha plana indicam um problema mais difícil, 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 que demoram muito tempo.
- Trabalhe 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 ocorre 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) Deslocar 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.
Nota
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 existe um problema e aproximadamente onde ele está, mas você deve investigar para chegar à(s) causa(s) raiz(es). 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 âmbito mudou?
As alterações de âmbito aplicam-se apenas a CFDs de período fixo. A linha superior do gráfico indica o âmbito do trabalho. Um sprint é pré-carregado com o trabalho a fazer no primeiro dia. As alterações na linha superior indicam que o trabalho foi adicionado ou removido.
O único cenário em que não é possível 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. Monitorizar as questões específicas. Use Exibir/configurar burndown de sprint para monitorar alterações de escopo.
Muito WIP?
Você pode facilmente monitorar se os limites de WIP foram excedidos a partir da 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 um oval. É uma indicação de que o WIP está afetando negativamente o ciclo e o tempo de entrega.
Aqui está uma boa regra geral 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 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 os trabalhos podem ser interrompidos. Ter um segundo item de trabalho para pivotar fornece alguma margem de manobra. Se ambos os itens estiverem bloqueados, é hora de levantar uma bandeira vermelha para obter algo desbloqueado — 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 mudar de contexto. É mais provável que eles esqueçam o que estavam fazendo, e erros podem ocorrer.
Prazo de entrega 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 no estado Concluído. O tempo de ciclo é calculado desde a primeira entrada em uma categoria de estado Em Andamento ou Resolvido até a entrada em 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 que ele passar 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, convém 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.
Planeje usando tempos de entrega estimados com base nos tempos de entrega/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 entrega da sua equipe para estimar quando sua equipe concluirá esse item de trabalho. O desvio padrão da sua equipa indica-lhe 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 depois que o trabalho tiver começado.
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 concluirá futuras histórias de usuários cerca de 2 a 14 dias após o início do trabalho. Quanto mais estreito for o desvio padrão, mais previsíveis serão as suas estimativas.
Exemplo de widget Tempo de ciclo
Identificar problemas de processo
Revise a tabela de controle da sua equipe para verificar se há valores atípicos. Os valores anómalos representam frequentemente 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 no processo. Resolver os problemas do processo pode ajudar a reduzir o desvio padrão da sua equipe e melhorar a previsibilidade da mesma.
Exemplo de widget Tempo de Ciclo mostrando vários valores atípicos
Você também pode ver como as mudanças de processo afetam seu lead e o tempo de ciclo. Por exemplo, em 15 de maio, a equipe fez um esforço concertado para limitar o WIP e resolver bugs obsoletos. Você pode ver que o desvio padrão diminui após essa data, mostrando melhor previsibilidade.