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 2022 - Azure DevOps Server 2019
Você pode usar diagramas de fluxo cumulativo (CFDs) para monitorar o fluxo de trabalho através de um sistema. O tempo de ciclo e o prazo de entrega são as duas principais métricas usadas para rastreamento. Você pode extrair essas métricas de um CFD.
Este artigo mostra-lhe como pode utilizar CFDs, tempos de ciclo e prazos de entrega para identificar problemas no seu processo de trabalho e ajudá-lo a mover o trabalho através do seu sistema.
- Para configurar 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.
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 combinam práticas lean com Scrum ou outras metodologias. Como resultado, eles usam práticas de gestão lean durante uma iteração ou sprint. Nesta situação, o diagrama assume uma aparência ligeiramente diferente. Ele fornece duas informações extras e muito valiosas, como mostrado no próximo gráfico, o CFD de período fixo.
CFD de fluxo contínuo
Este CFD de período fixo é para um sprint concluído.
A linha superior representa o escopo definido para o sprint. Como o trabalho deve ser concluído até o último dia do sprint, a inclinação do estado Fechado indica se uma equipe está no caminho certo para concluir o sprint. A maneira mais fácil de pensar nessa visão é como um gráfico de progresso acumulado.
No gráfico, a primeira etapa do processo é representada como a área superior esquerda. A última etapa do processo é representada como a área inferior direita.
CFD de período fixo para um sprint concluído
Métricas do gráfico
Os CFDs exibem a contagem de itens de trabalho agrupados por estado ou coluna ao longo do tempo. As duas principais métricas usadas para o acompanhamento são o tempo de ciclo e o tempo de execução. Você pode extrair 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. O comprimento é medido 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 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: 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 sendo trabalhados ativamente.
Âmbito de aplicação
A quantidade de trabalho comprometido para o período de tempo dado. 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 bem definida entre lead time ou tempo de ciclo e WIP. Mais WIP resulta em tempos de ciclo mais longos, o que leva a prazos de entrega mais longos. O oposto também é verdadeiro: menos WIP resulta em 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 é uma das principais razões pelas quais você deve definir limites de WIP na placa que você usa para acompanhar e gerenciar o trabalho.
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 que está na fila e concluído para um determinado dia.
Categorizar o trabalho em colunas específicas do quadro mostra a quantidade de trabalho em cada área do processo. Esta vista fornece informações sobre onde o trabalho está a decorrer sem problemas, onde existem bloqueios e onde não está a ser feito qualquer trabalho. É difícil decifrar uma visão tabular dos dados. No entanto, o CFD visual ajuda você a entender o que está acontecendo em seu processo de trabalho e por que isso está acontecendo.
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 flatlining sistémico pode ocorrer num CFD de funcionalidades. O trabalho em funcionalidades pode levar significativamente mais tempo do que o trabalho em histórias de utilizadores, uma vez que 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 significativamente 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. Ter um segundo item de trabalho para alternar pode fornecer 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 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 ilustra como o lead time difere do tempo de ciclo. 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 pela primeira vez em uma categoria de estado Em andamento ou Resolvido. O tempo de ciclo termina quando o item de trabalho entra em uma categoria de estado Concluído.
Se um item de trabalho entrar em uma categoria de estado Concluído e, em seguida, for reativado, seus tempos de espera e ciclo serão afetados. Qualquer tempo extra que ele gasta na categoria de estado Proposto, Em Progresso ou Resolvido contribui para os seus tempos de lead e de ciclo.
Se sua equipe usa um quadro para acompanhar e gerenciar o trabalho, isso ajuda a entender como suas colunas são mapeadas para os estados do fluxo de trabalho. Para obter mais informações sobre como configurar o quadro, consulte Gerenciar colunas no quadro.
Para obter mais informações sobre 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.
Estime os tempos de entrega com base nos tempos de espera e de ciclo.
Pode utilizar as médias dos tempos de lead e ciclo, bem como 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 a data de conclusão desse item de trabalho. O desvio padrão da sua equipa indica-lhe a variabilidade da estimativa. Da mesma forma, você pode usar seu 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.
Exemplo do widget Tempo de Ciclo
No gráfico a seguir, o tempo médio de ciclo é de oito dias. O desvio padrão é de seis dias. Usando esses dados, você pode estimar que a equipe conclui histórias de usuários futuros 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.
Identificar problemas de processo
Os valores anómalos representam frequentemente um problema subjacente ao processo. Os exemplos incluem esperar muito tempo para revisar solicitações pull ou não resolver uma dependência externa rapidamente. Revise a tabela de controle da sua equipe para verificar se há valores atípicos.
Exemplo de widget Tempo de Ciclo mostrando vários valores atípicos
O gráfico a seguir apresenta vários outliers, pois diversos bugs demoraram mais do que a média para serem concluídos. Investigar por que esses bugs demoraram mais pode ajudar a descobrir problemas no processo. Resolver problemas de processo pode ajudar a reduzir o desvio padrão da sua equipe e melhorar a previsibilidade da mesma.
Você também pode ver como as mudanças de processo afetam os seus tempos de lead e 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.