{"id":9145,"date":"2019-07-01T11:08:52","date_gmt":"2019-07-01T14:08:52","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=9145"},"modified":"2019-07-01T15:13:33","modified_gmt":"2019-07-01T18:13:33","slug":"burndown-para-scrumban-uma-nova-ideia-para-acompanhar-suas-sprints","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2019\/07\/burndown-para-scrumban-uma-nova-ideia-para-acompanhar-suas-sprints\/","title":{"rendered":"Burndown para Scrumban: uma nova ideia para acompanhar suas Sprints"},"content":{"rendered":"

Ap\u00f3s um tempo consider\u00e1vel trabalhando focado com o m\u00e9todo Kanban, tive o prazer de voltar a trabalhar usando Scrum. Praticamente acompanhei um time utilizando esse framework em seu formato by the book<\/em>, ou seja, na sua \u00edntegra, sem adapta\u00e7\u00f5es.<\/p>\n

Em uma determinada ocasi\u00e3o, percebi que poder\u00edamos aprimorar as m\u00e9tricas que o time estava utilizando. Nesse momento, ainda n\u00e3o est\u00e1vamos utilizando o Burndown<\/em>, um dos gr\u00e1ficos mais famosos para times que utilizam o framework Scrum. Por\u00e9m, quando come\u00e7amos a falar sobre ele, lembrei de algo que me incomodava um pouco nesse gr\u00e1fico: o time s\u00f3 consegue perceber o progresso quando o item de trabalho \u00e9 conclu\u00eddo e, por consequ\u00eancia, seu valor \u00e9 debitado no gr\u00e1fico. Podemos perceber essa situa\u00e7\u00e3o neste exemplo:<\/p>\n

\"\"<\/p>\n

Na imagem acima, o eixo X representa o tempo da Sprint em dias corridos e, no eixo Y, temos o valor de pontos das hist\u00f3rias que fazem parte da Sprint. A barra azul representa a proje\u00e7\u00e3o que dever\u00edamos entregar na linha do tempo. Por fim, a linha vermelha \u00e9 o que efetivamente entregamos e, sempre que ela decresce, significa que um ou mais itens de trabalho foram entregues naquele respectivo dia. At\u00e9 aqui, nenhuma novidade.<\/p>\n

A ideia de criar um novo Burndown<\/strong><\/p>\n

\n

Nesta ocasi\u00e3o, entendi que t\u00ednhamos uma oportunidade de aprimorar esse gr\u00e1fico, testando uma nova forma de acompanhar o progresso do time (no exemplo anterior, a linha vermelha). Validei a seguinte ideia com algumas pessoas: e se a gente considerasse o valor proporcional da evolu\u00e7\u00e3o do time, de acordo com a etapa em que o item de trabalho est\u00e1 no quadro kanban? Sim, est\u00e1vamos utilizando o Scrum, mas, por ele ser um framework<\/em>, agregamos algumas outras pr\u00e1ticas, sendo uma delas um quadro para o time gerenciar as etapas de desenvolvimento de todos os itens de trabalho.<\/p>\n

A l\u00f3gica \u00e9 simples: imagine um item de trabalho (uma hist\u00f3ria de usu\u00e1rio, por exemplo) de tamanho 8. Essa demanda est\u00e1 dentro de uma Sprint com 29 pontos de hist\u00f3ria no total. O que aconteceria se a gente debitasse uma propor\u00e7\u00e3o deste item de trabalho no Burndown<\/em> quando ele fosse movido de uma etapa para outra? Na pr\u00e1tica, quando come\u00e7amos a fazer isso em todos os itens de trabalho da Sprint, aconteceu algo semelhante a este exemplo hipot\u00e9tico:<\/p>\n

\"\"<\/p>\n

A linha laranja no exemplo acima representa a ideia do Burndown para Scrumban<\/strong> (n\u00e3o achei um nome melhor, ent\u00e3o esse ficou autoexplicativo). \u00c9 poss\u00edvel perceber que ela est\u00e1 mais flu\u00edda e decresce de uma forma mais constante se compararmos com a linha vermelha.<\/p>\n

Nesta ocasi\u00e3o, nosso quadro kanban era composto por 10 etapas para acompanhar os itens de trabalho, sendo que 7 dessas etapas eram consideradas como WIP<\/em> (Work In Progress, ou trabalho em progresso). Utilizando novamente o exemplo do item de trabalho com tamanho 8, n\u00f3s come\u00e7amos a debitar a propor\u00e7\u00e3o deste valor toda vez que o item passava para a etapa seguinte no quadro. Ou seja, o gr\u00e1fico debitava 1,14<\/strong> pontos sempre que o item se movesse para a etapa seguinte (8\/7, que \u00e9 igual ao tamanho do item [8] dividido pela quantidade de etapas consideradas como WIP<\/em> [7]).<\/p>\n

Por exemplo: quando o time levou o item (de tamanho 8) da etapa “Em Desenvolvimento” para a etapa “Revis\u00e3o do C\u00f3digo”, o gr\u00e1fico (linha laranja) considerou 1,14 pontos entregues. Quando passou de “Revis\u00e3o do C\u00f3digo” para “Pronto para Testar”, debitou mais 1,14 pontos, e assim sucessivamente at\u00e9 que, quando o item foi levado para “Conclu\u00eddo”, o gr\u00e1fico debitou os \u00faltimos 1,14 pontos, totalizando assim 8 pontos de hist\u00f3ria conclu\u00eddos. Esse mesmo racioc\u00edcio aconteceu para todas as outras demandas: 0,42<\/strong> (3\/7) para itens com tamanho 3, 0,71<\/strong> (5\/7) para itens de tamanho 5, e assim por diante.<\/p>\n

Inclusive h\u00e1 um detalhe importante na imagem anterior. \u00c9 poss\u00edvel perceber que a linha laranja (a que est\u00e1 abaixo da linha reta, a azul) come\u00e7ou com 24,8 pontos, um pouco a menos dos 29,0 pontos do total da Sprint. Isso ocorreu porque, neste exemplo, o time pode ter herdado itens de trabalho n\u00e3o finalizados de uma Sprint anterior e, neste caso, elas j\u00e1 come\u00e7aram na nova Sprint em uma etapa mais avan\u00e7ada no quadro kanban, como em “Testando”, por exemplo. Logo, elas j\u00e1 tiveram seus pontos debitados e, com isso, a equipe come\u00e7ou a Sprint com uma leve vantagem em determinadas demandas (algumas prontas para serem desenvolvidas, outras j\u00e1 em andamento).<\/p>\n

Aprimorando a ideia do Burndown para Scrumban<\/strong><\/p>\n

\n

Por\u00e9m, havia um problema: considerar a propor\u00e7\u00e3o do item pode trazer mais precis\u00e3o na avalia\u00e7\u00e3o do gr\u00e1fico, como tamb\u00e9m do progresso do time ao longo da Sprint, mas ser\u00e1 que \u00e9 correto entender que cada etapa do quadro kanban tem o mesmo peso? Em outras palavras, \u00e9 correto dizer que o tempo alocado para desenvolver (c\u00f3digo)<\/strong> um item de trabalho vale o mesmo tanto do que o tempo que ele ficou aguardando para ser testado<\/strong>, por exemplo?<\/p>\n

Conversei com algumas pessoas e fiquei convencido de que essa l\u00f3gica estava equivocada, mesmo trazendo um pouco mais de precis\u00e3o para a avalia\u00e7\u00e3o do gr\u00e1fico. Solu\u00e7\u00e3o: come\u00e7amos a utilizar a propor\u00e7\u00e3o do tempo de desenvolvimento em cada etapa do quadro kanban, e, para conseguir esse valor proporcional, extra\u00ed o hist\u00f3rico de dados do gr\u00e1fico Lead time Breakdown<\/strong> e obtive a propor\u00e7\u00e3o de tempo em que cada item ficava em cada uma das etapas do quadro kanban. Para obter esse valor, considerei todos os itens de trabalho conclu\u00eddos em Sprints anteriores e calculei a mediana da amostra de dados. Se voc\u00ea ainda n\u00e3o conhece o Lead time Breakdown, sugiro a leitura da segunda se\u00e7\u00e3o do artigo M\u00e9tricas \u00c1geis: Cumulative Flow Diagrams e Lead Time Breakdown<\/a>, escrito por Raphael Albino.<\/p>\n

Deixando a explica\u00e7\u00e3o acima menos t\u00e9cnica e mais pr\u00e1tica: de 100% do tempo que eu demoro para entregar um item de trabalho, quanto tempo ele fica em desenvolvimento? E em testes? E em revis\u00e3o do c\u00f3digo? Foi essa propor\u00e7\u00e3o que eu obtive e inseri no gr\u00e1fico, a fim de deix\u00e1-lo mais preciso. O resultado:<\/p>\n

\"\"<\/p>\n

Na extra\u00e7\u00e3o desses dados, por exemplo, descobri que os itens dessa equipe ficavam 48% do tempo em desenvolvimento. Lembra a hist\u00f3ria de usu\u00e1rio de tamanho 8 da explica\u00e7\u00e3o anterior? Ent\u00e3o, ao inv\u00e9s de eu debitar no gr\u00e1fico acima 1,14 pontos quando este item de trabalho passou de “Em desenvolvimento” para “Revis\u00e3o do C\u00f3digo”, eu debitei 3,84 pontos, pois isso \u00e9 48% de 8 pontos. E esse mesmo racioc\u00ednio foi aplicado para todas as outras etapas do quadro kanban, bem como para todos os outros itens de trabalho.<\/p>\n

Para facilitar a visualiza\u00e7\u00e3o da diferen\u00e7a entre cada um, coloquei, no mesmo gr\u00e1fico, as tr\u00eas formas que consideram o progresso da Sprint:<\/p>\n

\"\"<\/p>\n

Resumindo tudo o que foi falado at\u00e9 aqui atrav\u00e9s da imagem acima:<\/p>\n