O CFD \u00e9 um instrumento valioso para rastrear e prever projetos \u00e1geis. Ao us\u00e1-lo, voc\u00ea pode verificar rapidamente o status atual: quanto trabalho foi feito, o que est\u00e1 em andamento e quanto tempo ser\u00e1 necess\u00e1rio para que determinado escopo seja conclu\u00eddo.<\/p>\n
A estrutura do gr\u00e1fico \u00e9 muito simples. O eixo horizontal representa um per\u00edodo de tempo (semanas, sprints, etc) e o vertical indica, de forma acumulada, o n\u00famero de itens no processo (total de tarefas, total de hist\u00f3rias, etc.). Cada \u00e1rea pintada no gr\u00e1fico est\u00e1 relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado, etc) e as curvas s\u00e3o basicamente o n\u00famero de itens acumulados em tais etapas.<\/p>\n
![\"Gr\u00e1fico](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/10\/grafico-cfd-1024x408.png\")
<\/p>\n
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:<\/p>\n
- \n
- Backlog:<\/strong> itens que precisavam ser refinados.<\/li>\n
- Ready to Dev:<\/strong> itens com crit\u00e9rios de aceite definidos e com uma defini\u00e7\u00e3o expl\u00edcita de “feito”.<\/li>\n
- Developing:<\/strong> itens em desenvolvimento.<\/li>\n
- Testing:<\/strong> itens sendo verificados e validados.<\/li>\n
- Accepted:<\/strong> itens lan\u00e7ados em produ\u00e7\u00e3o.<\/li>\n<\/ul>\n
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\u00e1vamos informar o status do projeto para o CTO nessa frequ\u00eancia.<\/p>\n
Os pr\u00f3ximos 3 diagramas representam o projeto no in\u00edcio (primeiras 7 semanas), no meio (11\u00aa semana) e no final (semana 22).<\/p>\n
O come\u00e7o<\/h2>\n
![\"Global](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2016\/03\/global-cumulative-flow-diagram-beginning-1024x389.jpeg\")
<\/p>\nNo in\u00edcio do projeto, a equipe enfrentou uma situa\u00e7\u00e3o em que a rela\u00e7\u00e3o entre a chegada e a sa\u00edda dos itens n\u00e3o era proporcional — o throughput<\/em> <\/a>m\u00e9dio da equipe era de 3 itens por semana e o escopo aumentava 7 itens por semana. Este comportamento \u00e9 ruim, porque significa que o n\u00famero de itens entregues dificilmente ser\u00e1 igual ao n\u00famero de itens do escopo. Naquele instante, a equipe e a PO discutiram solu\u00e7\u00f5es para que a taxa de crescimento do escopo acompanhasse a cad\u00eancia de entrega.<\/p>\n
Outra informa\u00e7\u00e3o que pode ser extra\u00edda do gr\u00e1fico \u00e9 que alguns itens foram criados (est\u00e1gio de Backlog), mas n\u00e3o foram detalhados (Ready to Dev). Neste caso, o time refinou junto da PO um conjunto de itens e os deixou prontos para serem trabalhados.<\/p>\n
O meio<\/h2>\n
![\"Global](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2016\/03\/global-cumulative-flow-diagram-middle-1024x453.jpeg\")
<\/p>\nAo analisar o CFD no meio do projeto, \u00e9 poss\u00edvel observar que as etapas de desenvolvimento (Developing) e testes (Testing) n\u00e3o apresentavam ac\u00famulo entre as etapas (sobrecarga). Comparado com as primeiras 6 semanas (in\u00edcio do projeto), a rela\u00e7\u00e3o entre itens criados e entregues passou a ser a mesma: 3 itens por semana.<\/p>\n
A equipe sabia que o throughput<\/em> <\/a>precisava aumentar. Al\u00e9m disso, o projeto ainda apresentava indefini\u00e7\u00f5es — 15 itens n\u00e3o estavam preparados para serem desenvolvidos. Um dos causadores de tal situa\u00e7\u00e3o foi a alta incerteza no design da aplica\u00e7\u00e3o.<\/p>\n
O fim<\/h2>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2016\/03\/global-cumulative-flow-diagram-end.png\")
<\/p>\nUma coisa interessante que percebemos no final deste projeto foi que o trabalho na etapa de teste fluiu bem. Olhando para o gr\u00e1fico, \u00e9 poss\u00edvel reconhecer que as linha azuis (etapa de Teste) desapareciam rapidamente. Isso ocorreu porque a intera\u00e7\u00e3o dentro do time foi intensa. Na semana 19, a equipe e a PO alinharam que nenhum novo item seria inclu\u00eddo no escopo, porque o prazo de entrega estava chegando.<\/p>\n
Outra informa\u00e7\u00e3o que pode ser observada no gr\u00e1fico de CFD acima \u00e9 que a equipe n\u00e3o concluiu todas as hist\u00f3rias previstas no escopo — a etapa “Accepted” n\u00e3o ocupou todo o diagrama. Nesse caso, a equipe de desenvolvimento do nosso cliente assumiu os 5 itens que estavam em progresso (2 em desenvolvimento e 3 em testes).<\/p>\n
Vale compartilhar que os itens entregues geraram uma solu\u00e7\u00e3o de qualidade e alinhada com o que nosso cliente precisava.<\/p>\n
Adotamos como boa pr\u00e1tica verificar o CFD semanalmente para impulsionar melhorias dos nossos processos. Tal diagrama se mostrou um excelente companheiro para discuss\u00f5es sobre limita\u00e7\u00e3o e gerenciamento de WIP<\/a>.<\/p>\n
2. Lead time breakdown<\/h2>\n
Para aprimorar reuni\u00f5es de acompanhamento do projeto ou retrospectivas, criamos uma visualiza\u00e7\u00e3o chamada “lead time breakdown<\/em>“.<\/p>\n
Resumidamente, este gr\u00e1fico permite que o time avalie, compare e analise em detalhes a lat\u00eancia entre o in\u00edcio e o t\u00e9rmino de cada uma das etapas do processo de desenvolvimento, para cada item de trabalho que passa pelo fluxo (bugs, hist\u00f3rias do usu\u00e1rio, etc).<\/p>\n
Esse tipo de visualiza\u00e7\u00e3o permite analisar o processo com mais detalhes se comparado com a an\u00e1lise do CFD. Geralmente, o lead time breakdown<\/em> \u00e9 utilizado para responder quest\u00f5es como:<\/p>\n
- \n
- O que est\u00e1 acontecendo com os itens que est\u00e3o em progresso?<\/li>\n
- Existe algum tipo de impedimento atrapalhando a fluidez do time?<\/li>\n
- O time est\u00e1 lidando com algum gargalo no processo (exemplo: sobrecarga na etapa de testes)?<\/li>\n<\/ul>\n
Criar a visualiza\u00e7\u00e3o \u00e9 bem simples. No eixo vertical est\u00e3o os dias de trabalho; no horizontal, os itens de trabalho em progresso ou j\u00e1 entregues pelo time (exemplo: o montante de hist\u00f3rias do usu\u00e1rio monitorados pelo quadro Kanban). Para representar cada uma das etapas do processo, \u00e9 utilizado o gr\u00e1fico de barra acumulado.<\/p>\n
Vamos ver um exemplo a partir de um projeto real. A equipe tinha o fluxo de trabalho com as seguintes etapas:<\/p>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2016\/03\/lead-time-breakdown-label.jpeg\")
<\/p>\nNeste fluxo, h\u00e1 etapas com o objetivo de medir gargalos criados pelas etapas de QA (Waiting for QA) ou pelo respons\u00e1vel pelas aprova\u00e7\u00f5es das entregas dos itens (Waiting for Review). O gr\u00e1fico de lead time breakdown<\/em> do exemplo ficou assim representado:<\/p>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2016\/03\/lead-time-breakdown.png\")
<\/p>\nPodemos identificar que quase todas os itens do exemplo necessitam de mais de 3 dias para serem revisados (comportamento visto pela barra roxa). Em alguns casos, tal tempo de passagem pode ser inaceit\u00e1vel, dado a criticidade da entrega.<\/p>\n
Outro ponto interessante \u00e9 a alta variabilidade no lead time<\/em> da etapa de codifica\u00e7\u00e3o (barra azul). Neste caso, o time provavelmente trazia para o fluxo de desenvolvimento itens com pouca padroniza\u00e7\u00e3o.<\/p>\n
Durante este projeto, a equipe sofreu pois tinha que compartilhar um especialista de teste (repare na altura das barras exibidas em amarelo no gr\u00e1fico). \u00c0 medida que a equipe e os stakeholders acessavam periodicamente o gr\u00e1fico, o problema ficava evidente para todos e solu\u00e7\u00f5es foram discutidas para resolv\u00ea-lo. Uma delas foi o Scrum Master exercer o papel de especialista em teste, em alguns per\u00edodos do ciclo de vida do projeto.<\/p>\n
Como boa pr\u00e1tica, em todos os projetos que atuamos, temos utilizado o gr\u00e1fico de lead time breakdown<\/em> periodicamente para entender o status atual da equipe. Tal ferramenta tem sido \u00fatil para:<\/p>\n
- \n
- Guiar discuss\u00f5es recorrentes de como remover desperd\u00edcios no processo.<\/li>\n
- Promover melhorias no processo baseadas em dados.<\/li>\n
- Deixar evidente o tempo de espera ao longo do desenvolvimento dos itens de trabalho.<\/li>\n
- Analisar mais facilmente\u00a0as demandas que est\u00e3o pr\u00f3ximas de serem finalizadas.<\/li>\n
- Utilizar as informa\u00e7\u00f5es para apoiar retrospectivas quando a pauta \u00e9 relacionada ao processo.<\/li>\n
- O que o time precisa manter?<\/li>\n
- O que o time precisa mudar?<\/li>\n<\/ul>\n
Concluindo<\/h2>\n
A visualiza\u00e7\u00e3o do fluxo atrav\u00e9s do CFD ou do lead time breakdown<\/em> fornece uma vis\u00e3o quantitativa e qualitativa de problemas potenciais no processo de desenvolvimento de software. Encontrar solu\u00e7\u00f5es \u00e9 uma outra hist\u00f3ria.<\/p>\n
Para aprender mais sobre o CFD, recomendo 4 boas refer\u00eancias:<\/p>\n
- \n
- O excelente artigo, Cumulative Flow Diagram<\/a> do Pawel Brodzinski.<\/li>\n
- O livro do Daniel Vacanti, Actionable Agile Metrics for Predictability<\/a>.<\/li>\n
- The Cumulative Flow Diagram in a nutshell<\/a>.<\/li>\n
- Minha publica\u00e7\u00e3o recente e em portugu\u00eas, M\u00e9tricas \u00c1geis \u2013 Obtenha melhores resultados em sua equipe<\/a>.<\/li>\n<\/ul>\n
E voc\u00ea, como tem utilizado o CFD? Qual a sua opini\u00e3o sobre a visualiza\u00e7\u00e3o do lead time breakdown<\/em>? Compartilhe sua opini\u00e3o nos coment\u00e1rios abaixo!<\/p>\n
\nCurso: M\u00e9tricas para Projetos Agile<\/h3>\n
Em 7 e-mails voc\u00ea vai aprender neste curso o que medir e como interpretar os dados. Curso gratuito<\/strong> criado pelo autor do livro \u201cM\u00e9tricas \u00c1geis\u201d, Raphael Albino.<\/p>\n
INSCREVA-SE GRATUITAMENTE<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Uma das grandes quest\u00f5es que um Agile Coach pode enfrentar durante sua carreira \u00e9: como posso ajudar a equipe a melhorar continuamente o processo de desenvolvimento? Neste blog post, apresentarei 2 valiosas t\u00e9cnicas para que voc\u00ea possa compreender de forma hol\u00edstica o fluxo de desenvolvimento de software de uma equipe. 1. CFD Segundo Brodzinski, Cumulative … \u00bb<\/a><\/p>\n","protected":false},"author":43,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123,254,257,263,243],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6839"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/43"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=6839"}],"version-history":[{"count":22,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6839\/revisions"}],"predecessor-version":[{"id":6871,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6839\/revisions\/6871"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=6839"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=6839"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=6839"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- O livro do Daniel Vacanti, Actionable Agile Metrics for Predictability<\/a>.<\/li>\n
- O excelente artigo, Cumulative Flow Diagram<\/a> do Pawel Brodzinski.<\/li>\n
- Ready to Dev:<\/strong> itens com crit\u00e9rios de aceite definidos e com uma defini\u00e7\u00e3o expl\u00edcita de “feito”.<\/li>\n