Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
Os diagramas de fluxo cumulativo (CFDs) ajudam-no a monitorizar o seu processo de trabalho, visualizando o fluxo de trabalho através do seu sistema. Este artigo explica como usar CFDs, tempos de ciclo e prazos de entrega para identificar problemas e melhorar a eficiência do fluxo de trabalho.
- Para instalar ou visualizar um CFD, consulte Exibir e configurar um diagrama de fluxo cumulativo.
- Para adicionar um gráfico de controle de tempo de espera ou de ciclo a um painel, consulte Widgets de tempo de entrega e tempo de ciclo.
- Para instalar ou visualizar um CFD, consulte Exibir e configurar um diagrama de fluxo cumulativo.
- Para adicionar um gráfico de controle de tempo de espera ou de ciclo a um painel, consulte Widgets de tempo de entrega e tempo de ciclo.
O CFD de fluxo contínuo é o gráfico que a maioria das equipes que seguem um processo lean preferem.
Mas muitas equipes combinam práticas lean com Scrum ou outros métodos. Eles usam práticas enxutas durante uma iteração ou sprint. Neste caso, o diagrama parece um pouco diferente. Ele mostra dois extras, O CFD de fluxo contínuo é o gráfico que a maioria das equipes que seguem um processo enxuto prefere.
Mas muitas equipes combinam práticas lean com Scrum ou outros métodos. Eles usam práticas enxutas durante uma iteração ou sprint. Neste caso, o diagrama parece um pouco diferente. Ele mostra duas informações extras e valiosas, como mostrado no gráfico seguinte, o CFD de período fixo.
CFD de fluxo contínuo
Este CFD de período fixo mostra um sprint concluído.
A linha superior mostra o escopo definido para o sprint. Como o trabalho precisa terminar até o último dia, a inclinação do Estado Fechado mostra se uma equipe está no caminho certo. Considere esta visualização como um gráfico de burnup.
No gráfico, a primeira etapa do processo está na área superior esquerda. O último passo está na área inferior direita.
CFD de período fixo para um sprint concluído
Métricas do gráfico
Os CFDs mostram a contagem de itens de trabalho agrupados por estado ou coluna ao longo do tempo. As duas principais métricas para acompanhamento são o tempo de ciclo e o tempo de entrega. Você extrai essas métricas do gráfico.
Métrica
Definição
Tempo de ciclo1
O tempo necessário para mover o trabalho através de um único processo ou estado de fluxo de trabalho. Meça a duração desde o início de um processo até o início do processo seguinte.
Prazo de execução1
Para um processo de fluxo contínuo: o tempo desde 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 sprint ou fi Para um processo de fluxo contínuo: o tempo desde 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: o tempo desde o início do trabalho em uma solicitação até a conclusão do trabalho (por exemplo, o tempo do estado Ativo para o estado Fechado).
Trabalhos em curso (WIP)
A quantidade de trabalho ou o número de itens de trabalho que estão ativamente em andamento.
Âmbito de aplicação
A quantidade de trabalho autorizado para o período determinado. Esta métrica aplica-se apenas a processos de período fixo.
1 O widget CFD que usa dados do Google Analytics e o CFD integrado que você pode visualizar a partir de uma lista de pendências ou quadro da equipe não fornecem valores discretos de tempo de espera e tempo de ciclo. No entanto, os widgets Lead Time e Cycle Time fornecem esses valores.
Há uma correlação clara entre o lead time ou o tempo de ciclo e o WIP. Um maior número de WIP leva a tempos de ciclo mais longos e a prazos de entrega mais longos. O oposto também é verdadeiro: menos WIP leva a ciclos e prazos de entrega mais curtos. 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 para definir limites de WIP na placa que você usa para acompanhar e gerenciar o trabalho.
A contagem de itens de trabalho mostra a quantidade total de trabalho em um determinado dia. Em um CFD de período fixo, uma mudança nessa contagem significa uma mudança de escopo para esse período. Num CFD de fluxo contínuo, o gráfico mostra a quantidade total de trabalho que está na fila e o que foi concluído para um determinado dia.
A categorização do trabalho em colunas específicas do quadro mostra a quantidade de trabalho em cada área do processo. Esta visão dá uma ideia de onde o trabalho está a decorrer sem problemas, onde existem bloqueios e onde nenhum trabalho está a ser feito. É difícil compreender uma vista tabular dos dados, mas o CFD visual ajuda-o a ver o que está a acontecer no seu processo de trabalho e porquê.
Identificar problemas e tomar as medidas apropriadas
O CFD fornece respostas às seguintes perguntas. Com base nas respostas, você pode ajustar o processo para mover o trabalho através do sistema.
A equipa concluirá o trabalho a tempo?
Esta pergunta aplica-se apenas a CFDs de período fixo. Você pode obter uma compreensão observando a curva (ou progressão) do trabalho na última coluna do quadro.
Nesse cenário, você pode considerar a redução do escopo do trabalho na iteração. Esta ação é apropriada se for claro que o trabalho não está sendo concluído com rapidez suficiente, supondo que continue em um ritmo constante. Esse cenário pode indicar que o trabalho foi subestimado e deve ser levado em conta no planejamento do próximo sprint.
No entanto, pode haver outras razões pelas quais o trabalho não está sendo concluído com rapidez suficiente. Você pode determinar esses motivos observando 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 várias colunas no gráfico. Estão a uma distância semelhante ou uniforme entre si do princípio ao fim? Alguma coluna parece nivelar ao longo de um período de vários dias? Ou algum parece protuberante?
Mura, ou desnível, é o termo enxuto para linhas planas e protuberâncias. Mura indica uma forma de resíduo (Muda) no sistema. Qualquer desnível no sistema faz 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 o status de seus itens de trabalho com uma cadência regular. O quadro que você usa para acompanhar e gerenciar o trabalho 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 ou duas partes tiverem problemas, você verá uma protuberância.
Linhas planas
As acumulações ocorrem quando o trabalho se acumula numa parte do sistema e não avança no processo.
Por exemplo, uma protuberância pode ocorrer quando o teste leva muito tempo, mas o desenvolvimento leva menos tempo. O resultado é que o trabalho se acumula na fase 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 tomando as seguintes ações:
- Realizar stand-ups diários
- Realização de outras reuniões periódicas
- Agendando 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. Linhas planas indicam que o trabalho em todo o sistema está parado. As causas subjacentes podem incluir os seguintes problemas:
- Bloqueios em todo o processo
- Processos que demoram muito tempo
- Mudança de trabalho para outras oportunidades que não ficam registadas no quadro
Um exemplo de revestimento plano sistémico pode ocorrer num CFD de características. O trabalho em funcionalidades pode levar mais tempo do que o trabalho em histórias de utilizadores, porque as funcionalidades são compostas por várias histórias. Nestas situações, ou se espera a inclinação (como num exemplo anterior), ou o problema é bem conhecido e a equipa já o levantou. 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. A correção apropriada pode depender de onde a protuberância ocorre. Como exemplo, suponha que a protuberância ocorre no processo de desenvolvimento. A protuberância pode estar acontecendo porque o teste está demorando mais do que escrever código. Os testadores também podem estar encontrando um grande número de bugs. Quando transferem continuamente o trabalho de volta aos desenvolvedores, estes herdam uma lista crescente de atividades ativas.
Há duas maneiras potencialmente fáceis de resolver esse problema:
- Mude os desenvolvedores do processo de desenvolvimento para o processo de teste até que a protuberância seja eliminada.
- Alterar a ordem de trabalho. Especificamente, entrelaça o trabalho que pode ser feito rapidamente com o trabalho que leva mais tempo para ser feito.
Procure soluções básicas para eliminar as protuberâncias.
Nota
Como podem ocorrer vários cenários que fazem com que o trabalho prossiga de forma desigual, é fundamental que você execute uma análise real do problema. O CFD pode dizer-lhe que existe um problema. Ele também pode dizer aproximadamente onde está o problema, mas você deve investigar para chegar às causas profundas. Esta orientação fornece ações recomendadas que resolvem problemas específicos, mas as soluções podem não se aplicar à sua situação.
O âmbito mudou?
As alterações de escopo 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. Alterações na linha superior indicam a adição ou remoção de trabalho.
Em um cenário específico, você não pode acompanhar as alterações de escopo com um CFD. Esse cenário ocorre quando o mesmo número de itens de trabalho são adicionados e removidos no mesmo dia. Neste caso, a linha permanece plana.
Para controlar as alterações de escopo nesse caso, execute as seguintes ações:
- Compare vários gráficos entre si.
- Monitorizar questões específicas.
- Use sprint burndown para monitorizar as alterações de escopo.
Há demasiado trabalho em progresso?
Você pode facilmente monitorar a placa para determinar se os limites de WIP são excedidos. Você também pode monitorar os níveis de WIP usando o 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 expande para uma forma oval. Esse comportamento é uma indicação de que a WIP está afetando negativamente o ciclo e o tempo de execução.
Aqui está uma boa regra geral para WIP: Não deve haver mais de dois itens em andamento por membro da equipe em um determinado momento. A principal razão para usar um limite de dois itens, não um limite mais estrito, é que a realidade frequentemente se intromete no processo de desenvolvimento de software.
Às vezes, leva tempo para obter informações de uma parte interessada ou para adquirir o software necessário. Existem várias razões pelas quais os trabalhos podem ser interrompidos. A manutenção de um segundo item de trabalho proporciona flexibilidade operacional durante atrasos inesperados. 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 há um grande número de itens em andamento, a pessoa que trabalha nesses itens pode ter dificuldade em mudar de contexto. É provável que se esqueçam do que estavam a fazer, o que pode levar a erros.
Prazo de entrega versus tempo de ciclo
O diagrama a seguir mostra como o tempo de entrega e o tempo de ciclo diferem. O prazo de entrega começa quando um item de trabalho é criado e termina quando o item de trabalho entra em uma categoria de estado Concluído. O tempo de ciclo começa quando um item de trabalho entra em uma categoria de estado Em andamento ou Resolvido e termina quando entra em uma categoria de estado Concluído.
Se sua equipe usa um quadro para acompanhar e gerenciar o trabalho, entender como suas colunas são mapeadas para os estados do fluxo de trabalho ajuda você a gerenciar o trabalho de forma mais eficaz. Para saber como configurar o quadro, consulte Gerir colunas no quadro.
Para saber como o sistema usa as categorias de estado — Proposto, Em andamento, Resolvido e Concluído — consulte Sobre os estados do fluxo de trabalho em listas de pendências e quadros.
Como o tempo de ciclo lida com itens de trabalho reativados
Para itens de trabalho que são reativados (movidos de um estado Concluído de volta para um estado Em Andamento ), o tempo de ciclo começa a partir da primeira vez que o item de trabalho entra em uma categoria de estado Em Andamento ou Resolvido e termina na última vez que entra em uma categoria de estado Concluído . O tempo de ciclo inclui todo o período de trabalho ativo, incluindo qualquer momento após a reativação.
Exemplo de cenário:
- Novo → Ativo → Resolvido → Concluído → Novo → Ativo → Concluído
- Cálculo do tempo de ciclo: Da primeira transição para Ativo à transição final para Fechado
- Tempo total do ciclo: Inclui períodos de trabalho ativos e o tempo no estado Fechado antes da reativação
Este método de cálculo dá uma imagem completa do tempo total necessário para concluir o item de trabalho, incluindo qualquer retrabalho ou esforço extra após a reativação. O cálculo do lead time segue o mesmo princípio — abrange todo o período desde a criação do item de trabalho até a conclusão final, independentemente de quaisquer estados intermediários concluídos.
Estime os tempos de entrega com base nos tempos de espera e de ciclo.
Use os seus tempos médios de lead e os de ciclo e os desvios padrão para estimar os tempos de entrega.
Ao criar um item de trabalho, use o tempo médio de entrega da sua equipe para estimar a data de conclusão. O desvio padrão da equipe mostra a variabilidade da estimativa. Da mesma forma, use o tempo de ciclo e seu desvio padrão para estimar quando um item de trabalho termina após o início do trabalho.
Exemplo do widget Tempo de Ciclo
No gráfico a seguir, o tempo médio de ciclo é de oito dias e o desvio padrão é de seis dias. Com esses dados, estima-se que a equipe conclua futuras histórias de usuários cerca de 2 a 14 dias após o início do trabalho. Um desvio padrão mais estreito torna suas estimativas mais previsíveis.
Identificar problemas de processo
Outliers geralmente significam que há um problema de processo subjacente. Por exemplo, esperar muito tempo para rever pull requests ou não corrigir rapidamente uma dependência externa. Verifique se há valores atípicos na tabela de controle da sua equipe.
Exemplo de widget de tempo de ciclo mostrando vários valores atípicos
O gráfico a seguir mostra vários valores atípicos porque alguns erros levaram mais tempo do que a média para serem resolvidos. Verificar por que esses bugs demoraram mais pode ajudá-lo a encontrar problemas de processo. A correção de problemas de processo ajuda a reduzir o desvio padrão da sua equipe e melhora a previsibilidade da mesma.
Você também observa como as mudanças de processo afetam o lead time e o tempo de ciclo. Por exemplo, em 15 de maio, a equipe trabalhou para limitar a WIP e corrigir bugs obsoletos. O desvio padrão diminui após essa data, mostrando melhor previsibilidade.