Uma das grandes questões que um Agile Coach pode enfrentar durante sua carreira, é: como posso ajudar a equipe a melhorar continuamente o processo de desenvolvimento?

Neste artigo, apresentarei duas valiosas técnicas para que você possa compreender de forma holística, o fluxo de desenvolvimento de software de uma equipe.

1. CFD

Segundo Brodzinski, Cumulative Flow Diagram (CDF) é um dos gráficos que oferece rápida visão geral do que está acontecendo num projeto ou produto.

O CFD é um instrumento valioso para rastrear e prever projetos ágeis. Ao usá-lo, você pode verificar rapidamente o status atual: quanto trabalho foi feito, o que está em andamento e quanto tempo será necessário para que determinado escopo seja concluído.

A estrutura do gráfico é muito simples. O eixo horizontal representa um período de tempo (semanas, sprints, etc) e o vertical indica, de forma acumulada, o número de itens no processo (total de tarefas, total de histórias, etc). Cada área pintada no gráfico está relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado, etc) e as curvas são basicamente o número de itens acumulados em tais etapas.

Para demonstrar como usamos o CFD na Plataformatec, descreverei o exemplo de um projeto. Nesse caso, tivemos um fluxo de desenvolvimento composto pelas seguintes etapas:

• Backlog: Itens que precisavam ser refinados.
• Ready to Dev: Itens com critérios de aceite definidos e com uma definição explícita de “feito”.
• Developing: Itens em desenvolvimento.
• Testing: Itens sendo verificados e validados.
• Accepted: Itens lançados em produção.

Neste projeto, utilizamos o CFD para: (1) comunicar o progresso; (2) identificar os gargalos do processo; (3) gerenciar as filas.

Escolhemos acompanhar o andamento semanalmente, pois precisávamos informar o status do projeto para o CTO nessa frequência.

Os próximos três diagramas representam o projeto no início (primeiras sete semanas), no meio (11ª semana) e no final (semana 22).

O começo

No início do projeto, a equipe enfrentou uma situação na qual a relação entre a chegada e a saída dos itens não era proporcional – o throughput médio da equipe era de três itens por semana e o escopo aumentava sete itens por semana. Este comportamento é ruim, porque significa que o número de itens entregues dificilmente será igual ao número de itens do escopo. Naquele instante, a equipe e a PO discutiram soluções para que a taxa de crescimento do escopo acompanhasse a cadência de entrega.

Outra informação que pode ser extraída do gráfico, é que alguns itens foram criados (estágio de Backlog), mas não foram detalhados (Ready to Dev). Neste caso, o time refinou junto da PO, um conjunto de itens e os deixou prontos para serem trabalhados.

O meio

Ao analisar o CFD no meio do projeto, é possível observar que as etapas de desenvolvimento (Developing) e testes (Testing) não apresentavam acúmulo entre as etapas (sobrecarga). Comparado com as primeiras seis semanas (início do projeto), a relação entre itens criados e entregues passou a ser a mesma: três itens por semana.

A equipe sabia que o throughput precisava aumentar. Além disso, o projeto ainda apresentava indefinições — 15 itens não estavam preparados para serem desenvolvidos. Um dos causadores de tal situação foi a alta incerteza no design da aplicação.

O fim

Uma coisa interessante que percebemos no final deste projeto, foi que o trabalho na etapa de teste fluiu bem. Olhando para o gráfico, é possível reconhecer que as linha azuis (etapa de Teste) desapareciam rapidamente. Isso ocorreu porque a interação dentro do time foi intensa. Na semana 19, a equipe e a PO alinharam que nenhum novo item seria incluído no escopo, porque o prazo de entrega estava chegando.

Outra informação que pode ser observada no gráfico de CFD acima, é que a equipe não concluiu todas as histórias previstas no escopo — a etapa “Accepted” não ocupou todo o diagrama. Nesse caso, a equipe de desenvolvimento do nosso cliente assumiu os cinco itens que estavam em progresso (dois em desenvolvimento e três em testes).

Vale compartilhar que os itens entregues geraram uma solução de qualidade e alinhada com o que nosso cliente precisava.

Adotamos como boa prática, verificar o CFD semanalmente para impulsionar melhorias dos nossos processos. Tal diagrama se mostrou um excelente companheiro para discussões sobre limitação e gerenciamento de WIP.

2. Lead time breakdown

Para aprimorar reuniões de acompanhamento do projeto ou retrospectivas, criamos uma visualização chamada “lead time breakdown“.

Resumidamente, este gráfico permite que o time avalie, compare e analise, em detalhes, a latência entre o início e o término de cada uma das etapas do processo de desenvolvimento, para cada item de trabalho que passa pelo fluxo (bugs, histórias do usuário, etc).

Esse tipo de visualização permite analisar o processo com mais detalhes, se comparado com a análise do CFD. Geralmente, o lead time breakdown é utilizado para responder questões como:

• O que está acontecendo com os itens que estão em progresso?
• Existe algum tipo de impedimento atrapalhando a fluidez do time?
• O time está lidando com algum gargalo no processo (exemplo: sobrecarga na etapa de testes)?

Criar a visualização é bem simples. No eixo vertical estão os dias de trabalho; no horizontal, os itens de trabalho em progresso ou já entregues pelo time (exemplo: o montante de histórias do usuário monitorados pelo quadro Kanban). Para representar cada uma das etapas do processo, é utilizado o gráfico de barra acumulado.

Vamos ver um exemplo a partir de um projeto real. A equipe tinha o fluxo de trabalho com as seguintes etapas:

Neste fluxo, há etapas com o objetivo de medir gargalos criados pelas etapas de QA (Waiting for QA) ou pelo responsável pelas aprovações das entregas dos itens (Waiting for Review). O gráfico de lead time breakdown do exemplo ficou assim representado:

Podemos identificar que quase todas os itens do exemplo necessitam de mais de três dias para serem revisados (comportamento visto pela barra roxa). Em alguns casos, tal tempo de passagem pode ser inaceitável, dado a criticidade da entrega.

Outro ponto interessante, é a alta variabilidade no lead time da etapa de codificação (barra azul). Neste caso, o time provavelmente trazia para o fluxo de desenvolvimento, itens com pouca padronização.

Durante este projeto, a equipe sofreu, pois tinha que compartilhar um especialista de teste (repare na altura das barras exibidas em amarelo no gráfico). À medida em que a equipe e os stakeholders acessavam periodicamente o gráfico, o problema ficava evidente para todos, e soluções foram discutidas para resolvê-los. Uma delas foi o Scrum Master exercer o papel de especialista em teste, em alguns períodos do ciclo de vida do projeto.

Como boa prática, em todos os projetos que atuamos, temos utilizado o gráfico de lead time breakdown periodicamente para entender o status atual da equipe. Tal ferramenta tem sido útil para:

• Guiar discussões recorrentes de como remover desperdícios no processo.
• Promover melhorias no processo baseadas em dados.
• Deixar evidente o tempo de espera ao longo do desenvolvimento dos itens de trabalho.
• Analisar mais facilmente as demandas que estão próximas de serem finalizadas.
• Utilizar as informações para apoiar retrospectivas quando a pauta é relacionada ao processo.
• O que o time precisa manter?
• O que o time precisa mudar?

Concluindo

A visualização do fluxo através do CFD ou do lead time breakdown fornece uma visão quantitativa e qualitativa de problemas potenciais no processo de desenvolvimento de software. Encontrar soluções é uma outra história.

Para aprender mais sobre o CFD, recomendo quatro boas referências:

• O excelente artigo, Cumulative Flow Diagram do Pawel Brodzinski.
• O livro do Daniel Vacanti, Actionable Agile Metrics for Predictability.
• The Cumulative Flow Diagram in a nutshell.
• Minha publicação recente e em português, Métricas Ágeis – Obtenha melhores resultados em sua equipe.

E você, como tem utilizado o CFD? Qual a sua opinião sobre a visualização do lead time breakdown? Compartilhe sua opinião nos comentários abaixo!

***

Este artigo foi publicado originalmente em: http://blog.plataformatec.com.br/2017/10/metricas-ageis-cumulative-flow-diagrams-e-lead-time-breakdown/