Como construir um gráfico CFD

Compartilhe:

Como construir um gráfico CFD? Um dos gráficos mais importantes para acompanhamento do desenvolvimento de produtos e serviços é o Cumulative Flow Diagram (CFD) ou, em tradução livre, Diagrama de Fluxo Cumulativo. 

Não perca a sequência desse artigo: Métricas Ágeis no Cumulative Flow Diagram (CFD): como analisar e Como identificar padrões (e evitar disfunções) no Cumulative Flow Diagram (CFD)

Objetivo do CFD

Seu principal objetivo é auxiliar na gestão do fluxo de trabalho. Ele apresenta o comportamento dos itens no fluxo de valor ao longo do tempo. Essas informações nos permitem observar disfuncionalidades e atuar de forma objetiva nos problemas que estão atrapalhando o andamento do trabalho. 

O que é o CFD

É um gráfico de área cumulativo. Isso significa que cada etapa do fluxo estará representada por uma área no gráfico.  Por ser cumulativo, as áreas estão empilhadas umas sobre as outras. A etapa mais próxima à conclusão do fluxo de trabalho é a etapa que estará na parte mais interna do gráfico (canto inferior direito). Do mesmo modo, a área mais externa é a etapa inicial (canto superior esquerdo).

Quais as unidades de medida do CFD?

No eixo X, como qualquer gráfico de acompanhamento, temos o tempo. Esse eixo pode estar expresso em dias, semanas, quinzenas, meses, trimestres etc. Tudo depende da informação que queremos extrair no momento.

Se estamos fazendo uma observação sobre algo pontual, utilizamos uma granularidade fina (dias ou semanas). Se estamos vendo a evolução do time e buscando o comportamento do sistema como um todo, podemos ter uma granularidade grossa (meses e trimestres).

Quanto mais fina a granularidade, menor o período, mais detalhes conseguimos enxergar. Quanto mais grossa a granularidade, maior o período e menos detalhes conseguimos enxergar, porém visualizamos um período mais largo. 

O Eixo Y é a quantidade de trabalho que temos. Tradicionalmente é expresso em quantidade de itens de valor. É preciso deixar claro que chamamos de item de valor todo incremento de produto ou serviço que o meu cliente consegue utilizar (valor para o cliente).

Se você utiliza o formato de História de Usuário, cada história é um item de valor. As tarefas técnicas NÃO são itens de valor.

Cuidado que há uma certa confusão com relação a esse tema causado pelas nomenclaturas utilizadas por ferramentas de acompanhamento. Dê uma olhada nesse artigo sobre Product Backlog.

Outra dúvida comum é se podemos tratar as dívidas técnicas como histórias técnicas. Dá uma olhada nesse outro artigo sobre como tratar e priorizar itens técnicos.

Posso utilizar Pontos de História de Usuário (User Story Points) ao invés de quantidade de itens de valor?

Você não está proibido de fazê-lo, mas confesso que nunca o vi. Você pode continuar utilizando Planning Poker e Pontos de História de Usuário (User Story Points), mas essa informação não é relevante para o CFD. 

Talvez você esteja se perguntando, se a informação não é relevante, então por que eu deveria usar essas técnicas? O principal benefício do Planning Poker é fazer com que os desenvolvedores discutam sobre como construirão o item de valor. Como ele deixará de ser ideia e se torna incremento de produto e serviço.

O CFD é parecido com os gráficos de Burnup e Burndown?

Sim e não. O CFD guarda similaridades com o gráfico de Burnup. Inclusive, no treinamento Kanban System Design, conversamos como sair do Burnup e chegar no CFD. Todavia, a forma como as pessoas fazem uso deles tende a ter algumas diferenças. 

  1. Quem utiliza o Burndown e Burnup tradicionalmente utiliza como unidade de medida do eixo Y os Pontos de História de Usuário (subjetivo), já no CFD é a quantidade de itens de valor (objetivo).
  2. Normalmente quem utiliza o Burnup e Burndown busca prever como será a próxima Sprint (futuro). O CFD mostra o histórico do time, o que permite analisar os pontos de disfunções e comportamento concreto no fluxo do trabalho (passado)
  3. Habitualmente, Burndown e Burnup apresentam menos informações (trabalho total, trabalho planejado na iteração e trabalho realizado). O CFD detalha todo o fluxo de valor. 

Existem outras  diferenças, mas acredito que essas sejam as mais relevantes. Percebam que utilizei palavras como: tradicionalmente, normalmente e habitualmente. Isso porque nenhum gráfico possui uma limitação. A criatividade das pessoas que usam a informação é o verdadeiro limite.

Cenário

Já falamos bastante, agora vamos para a prática. Para o nosso exemplo ficar mais didático, vamos utilizar uma versão simplificada tanto no tamanho do time, quanto na quantidade de etapas do fluxo de trabalho. 

Para facilitar a compreensão, optei por não separar os estágios de Ação (Action, por exemplo: Priorizando, Construindo, Avaliando, Entregando) e Espera (Waiting, por exemplo: Priorizado, Construído, Avaliado). O melhor seria representá-los, mas deixaria o nosso exemplo menos didático.

Fluxo de Valor

O fluxo de trabalho que vamos utilizar no exemplo está mapeado no quadro de tarefas abaixo:

Nesse quadro, temos o ponto de compromisso na passagem do item da etapa de Backlog para Priorizados (sinal verde). Quando o item sai da Entrega e vai para a etapa Na mão do cliente, significa que o consumidor final já pode utilizar aquele incremento se desejar.

Então, a linha que separa essas duas etapas (bandeira quadriculada) representa o ponto de entrega para o cliente e encerra o fluxo. 

Time

O time é composto por 4 pessoas. Um Product Owner (PO) , uma construtora, um avaliador e uma pessoa que cuida da entrega (delivery)

Figura 2, time que atua no nosso quadro. Product Owner (PO), Construtora, Avaliador e Entregadora.

Olhando para o nosso fluxo, podemos dizer que o Product Owner atua mais nas etapas de Backlog e Priorizados. A Construtora na construção, o Avaliador na avaliação e a Entregadora na entrega. Lembrando que queremos que o nosso time seja formado por profissionais do tipo T ou M. As ultra especializações aqui são só para facilitar a compreensão do CFD. 

Montando o CFD

Relembrando o nosso cenário. Temos 1 time com 4 pessoas e o fluxo de trabalho representado no quadro da Figura 1.

CFD Dia zero

Digamos que esse time comece o seu trabalho com 10 itens no Backlog dele. O Quadro de Tarefas (comumente, mas erroneamente chamado Quadro Kanban) está assim: 

Figura 3: Quadro do time no dia zero.

Já no CFD, no dia zero, marcamos apenas um ponto no valor 10 (Eixo Y) no dia 0 (Eixo X). 

Aqui temos outro ponto apenas para facilitar a didática. No eixo X marcamos a quantidade de dias que o desenvolvimento está sendo realizado. Dia 0, 1, 2, 3…. O mais correto seria utilizar as datas (01/12/2021, 02,12/2021… ) em que os eventos  ocorrem, pois dela podemos facilmente chegar na quantidade de dias, mas o contrário não é possível. Salvo você fique armazenando informações adicionais. 

Figura 4: CFD no dia zero.

CFD Terceiro dia – priorização

Esse time passou três dias discutindo sobre como desenvolveria essa solução: quais frameworks, linguagem de programação, qual o problema eles queriam resolver, quem eram as personas que seriam atendidas primeiro etc.

Eles priorizaram quatro itens para serem desenvolvidos. O quadro do time e o CFD ficariam representando as seguintes informações:

Figura 5: Quadro de Tarefas no terceiro dia. Quatro itens priorizados e seis itens no backlog com as demais etapas vazias.
Figura 6: CFD no terceiro dia com 4 itens que foram movidos do Backlog para a etapa de Priorizados.

Se 4 itens saíram do Backlog e foram para os priorizados, a linha azul não deveria diminuir? 

Não. É um gráfico de área CUMULATIVO, logo, a redução da área azul (“engolida” pela área laranja – priorizados) é que nos informa que os itens foram movidos de uma etapa para a outra.

A única coisa que justificaria uma queda no gráfico, é se nós removermos um item de valor do fluxo de trabalho. Por exemplo, descartar uma história de usuário ainda no backlog. 

CFD quarto dia – início da construção

No dia seguinte, aquele time começou a construção de dois dos quatro itens que foram priorizados. O quadro e o gráfico ficaram:

Figura 7: Quadro mapeando o fluxo de trabalho do time no quarto dia.
Figura  8: CFD no dia 4. Agora ele apresenta os itens que se moveram ao longo de três etapas do fluxo de trabalho.

Repare que a área da etapa Priorizados reduziu e a de Construção aumentou. Como não foram priorizados novos itens, a diferença entre o backlog e priorizados permanece inalterada.

CFD quinto dia – novos itens no Backlog

No Dia 5, o Product Owner chega com três novos itens. Os demais permanecem onde estão.

Figura 9: Quadro no quinto dia, agora com mais três itens no backlog. 
Figura 10: CFD no dia 5 representando a chegada de novos itens no Backlog.

Repare que, com a chegada de novos itens, a área do backlog aumenta. Caso fossem descartados itens no backlog, ela diminuiria.

CFD dia 10 – representando todas as etapas no CFD.

Esse time continuou o desenvolvimento e no dia 10, temos o seguinte cenário:

Figura 11: Quadro de Tarefas no dia 10. 
Figura 12: CFD no décimo dia.

Pergunte ao CFD e ele responderá!

O CFD nos mostra um “filme” em que conseguimos dizer o que aconteceu com os itens de trabalho e como eles se movimentaram no fluxo ao longo do período visualizado. Ele é bem diferente do Quadro de Tarefas que nos dá apenas uma “foto” do presente.

Quando o trabalho chegou para mim (chegada de itens em uma etapa)? 

Toda vez que a linha relativa à etapa aumenta, isso indica que “puxamos” itens para aquela etapa. Vamos analisar a perspectiva da nossa Construtora. Quando ela puxou o trabalho para ela?

Figura 13: Dias em que a construtora puxou trabalho. Os círculos vermelhos indicam toda vez que ela trouxe itens da etapa Priorizados para a etapa de Construção.

Logo, se olharmos para a Figura 12, conseguimos identificar exatamente quantos itens chegaram em cada etapa, em cada dia. Para tal, faça a subtração.

Por exemplo, quantos itens entraram na etapa de construção no sétimo dia. Olhando para o eixo X, ele aponta o valor 4, anteriormente, no sexto dia, estava marcado o valor 2. Logo para saber quantos itens chegaram no sétimo dia, subtraia 4 – 2 = 2 itens.

Dia Backlog Priorizados Construção Avaliação Entrega Na mão do cliente
0 +10          
1            
2            
3   +4        
4     +2      
5 +3          
6       +1    
7   +3 +2 +1 +1  
8     +1 +1 +1  
9 +1 +3 +1 +1 +1 +2
10 +1 +2 +2 +1 +1 +1
Tabela 1: Quantos itens chegaram em cada etapa por dia.

Quando entreguei a minha parte do trabalho (saída de itens de uma etapa)?

A saída de trabalho é indicada pelo aumento da área posterior à etapa que você está analisando. Isso indica que saíram itens daquela etapa e foram para a próxima. Vamos observar o caso da nossa construtora novamente. Quando ela terminou a construção?

Figura 14: Desde o sexto dia até o décimo dia, entregou 1 item por dia. Por isso temos uma entrega linear.
Dia Backlog Priorizados Construção Avaliação Entrega Na mão do cliente
0           Estado final.
Nada sai daqui
1            
2            
3 -4          
4   -2        
5            
6     -1      
7 -3 -2 -1 -1    
8   -1 -1 -1    
9 -3 -1 -1 -1 -2  
10 -2 -2 -1 -1 -1  
Tabela 2: Quantos itens saíram de cada etapa por dia.

Por curiosidade, compare os valores da Tabela 1 e da Tabela 2. Perceba que entradas e saídas estão sempre relacionadas.

Estamos “parados”?

Como falamos anteriormente, a saída de trabalho é indicada pelo aumento da área posterior à etapa que você está analisando. Caso a linha posterior forme uma reta horizontal, o trabalho está “parado” na etapa analisada.

Olhando para o trabalho do nosso amigo Product Owner, entre os dias 4 e 6 os itens ficaram “parados” na priorização e não foram para a construção. 

Figura 15: Trabalho “parado” na priorização sem caminhar para construção.

Atenção: o parado aqui não significa que não tem ninguém fazendo nada. Apenas que os itens entraram ali, mas não saíram. É provável que as pessoas estejam trabalhando neles. 

Continue perguntando e o CFD continuará respondendo.

As perguntas acima são o básico para entender como o CFD demonstra o comportamento dos itens de valor nas etapas. Entretanto, há outras informações importantes que ele também consegue te dar.

Está chegando mais trabalho do que estamos conseguindo entregar?

Apenas para facilitar a visualização desses dados, vamos olhar como foi o 11º dia de trabalho desse time.

Figura 16: CFD apresentando os onze dias de trabalho do time. Algumas áreas estão maiores em relação a um período anterior.

Toda vez que a área de uma etapa aumentar em relação à próxima, podemos dizer que estamos puxando mais itens do que conseguimos entregar para o próximo estágio. Há muito Trabalho em Progresso, do inglês Work in Progress (WIP).

Figura 17: Aumento da área de itens priorizados sem que haja saída dos itens para construção.

Na figura 17 vemos que estamos priorizando muitos itens, mas eles não estão indo para a construção.

Não estamos fazendo nada (sem trabalho)? 

Sempre que uma linha encosta na outra, como foi o caso das etapas Entrega e Na mão do Cliente no dia 11, significa que não há nenhum item ali. 

Estamos mais rápidos?

Vamos acrescentar mais dois dias de trabalho no nosso time.

Figura 18: CFD mostrando até o 13º dia de trabalho do time. Com aumento de velocidade.

Você consegue perceber que a velocidade da entrega aumentou no dia 13? Veja que o ângulo da etapa subsequente (Na mão do cliente) diminuiu e a subida dessa linha ficou mais acentuada. Isso significa que a vazão, comumente chamada de velocidade de maneira errada, da Entrega aumentou. 

Estamos mais lentos?

Já quando o ângulo da linha da etapa subsequente aumenta, a linha fica mais horizontal do que vertical, o que significa que mais lenta está aquela etapa analisada.

Por exemplo, se olharmos para a etapa Priorizados, vemos que no dia 4 a velocidade dela aumenta porque 2 dos 4  itens que estavam nela passam para a etapa subsequente, Construção. Entretanto, nos dias 5 e 6, a velocidade diminuiu. Nesses dois dias, a linha da etapa de construção permaneceu estática com 2 itens.

Figura 19: No CFD, o ângulo da etapa subsequente diz a “velocidade” da etapa anterior.

Estamos tendo refluxo? O trabalho está voltando para etapas anteriores?

Vamos andar mais dois dias de trabalho. Veja o que aconteceu no 14º dia. A área da etapa de Construção aumenta e as áreas de Avaliação e Entrega são reduzidas. Na verdade, as linhas que representam essas etapas “caem”. 

Figura 20: Refluxo no 14º dia.

Isso é um caso típico de refluxo. O trabalho andou para trás. No 13º dia havia 1 item em Avaliação e 1 item em Entrega. Algo ocorreu e esses itens voltaram para Construção.

ATENÇÃO: Isso não é uma boa prática. O ideal em um fluxo é que não haja refluxo. Vamos visualizar no quadro o que aconteceu.

Figura 21: Quadro no 13º Dia. Tudo indo normal.
Figura 22: Quadro no 14º Dia. Os itens que estavam em avaliação e entrega retornaram (refluxo) para construção.

O que perdemos com refluxo:

  1. Dificulta a compreensão do CFD
  2. Como há várias entradas na etapa que sofreu o refluxo, qual é a prioridade dos itens que estão nela?
  3. Como há várias entradas na etapa que sofreu o refluxo, as pessoas que cuidam dela não sabem de onde virão os itens, pois de qualquer ponto do fluxo eles podem reentrar nela.
  4. O item que estava na Entrega precisa realmente ser avaliado? Para onde ele vai depois que a construção acabar?
  5. E se já tivéssemos atingido o limite do Trabalho em Progresso? Escanteia o limite? Ele servirá para o propósito dele?

Estamos fazendo uma gestão de FLUXO. Imagine um rio. A água não volta. Logo, qual seria a melhor forma de tratar esses casos?

Figura 23: Movimentando pessoas e não os itens.

O item que está na entrega está quase gerando valor, logo, a prioridade do time é terminá-lo. A pessoa de Construção se desloca até ele. A pessoa vai até o item e não o item até a pessoa.

O item que está na entrega está quase gerando valor, logo, a prioridade do time é terminá-lo. A pessoa de Construção se desloca até ele. A pessoa vai até o item e não o item até a pessoa.

“Imagine que o seu fluxo de trabalho é um rio. Quando uma árvore cai no rio. Você pega a árvore e traz a árvore até os lenhadores ou leva os lenhadores até a árvore.” (Avelino, 2022)

Se necessário, podemos até deslocar o pessoal de avaliação para esse item que está na Entrega. Uma vez que o problema tenha sido resolvido, eles atacam a segunda prioridade que é o item que estava em Avaliação e quando terminarem, retomam o fluxo normal. 

Mal comparando, é como se tivesse caído uma árvore próxima à foz do rio (entrega) e outra quase na foz (avaliação). Você não pega a árvore e manda ela para a nascente do rio porque os lenhadores estão lá. Os lenhadores têm que ir até o local onde a árvore está para removê-la. 

Conclusão

Ainda temos muito para falar sobre o CFD, como métricas e identificação de padrões, mas esse artigo está muito grande e vamos pará-lo por aqui. Continue acompanhando nosso blog para saber mais sobre gestão de fluxo e CFD. 

Veja o nosso artigo sobre Métricas no CFD. Na sequência, não esqueça de aprender a identificar os Padrões do CFD.

Quer aprender CFD na prática e muito mais sobre Kanban? Faça o treinamento de Kanban System Design aqui na K21. Nos vemos em breve e até a próxima.

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…