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)
Neste artigo
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.
- 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).
- 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)
- 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).
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:
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.
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:
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:
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.
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:
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?
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 |
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?
| 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 |
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.
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.
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).
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.
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.
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”.
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.
O que perdemos com refluxo:
- Dificulta a compreensão do CFD
- Como há várias entradas na etapa que sofreu o refluxo, qual é a prioridade dos itens que estão nela?
- 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.
- O item que estava na Entrega precisa realmente ser avaliado? Para onde ele vai depois que a construção acabar?
- 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?
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.
