Pressione enter para ver os resultados ou esc para cancelar.

A Ciência do Burn-Up

Como a matemática pode ajudar no entendimento desta ferramenta?

O burn-up é uma das principais ferramentas disponíveis para gestores lidarem com a previsibilidade de uma forma simples, utilizando a relação direta entre 3 importantes variáveis da gestão de projetos de software: escopo conhecido versus prazo para entrega versus escopo entregue. O eixo X representa alguma unidade temporal – dias, semanas – e o eixo Y, o escopo analisado. Interessante observar aqui que o burn-up é muito utilizado para análise de itens de trabalho individuais ou para pontos de esforço para sprints. Ele também pode ser muito útil em um dado utilizado para avaliação da eficácia da operação, os pontos de valor de negócio, ou simplesmente BVP.

Vamos olhar um exemplo:

burnup1.png

O gráfico acima foi definido para ter o eixo X dividido por semanas e o eixo Y representa as opções. Entregas já estão previstas na primeira semana. As linhas, representando os dados, são o escopo esperado, o escopo realizado (atual) e a linha ideal, que diz, linearmente, quanto de trabalho precisa ser realizado para que o escopo combinado seja atingido na data combinada atual. 

O objeto central deste post é a chamada “linha ideal” e o seu ângulo em relação ao eixo X. Percebam que quanto maior o ângulo, mais agressivo é o projeto e, quanto maior o limite do eixo X e menor o limite do eixo Y, menor será o ângulo. Esta movimentação é bem conhecida das empresas que decidiram gerenciar os seus riscos através de lotes menores, isto é, mais manobráveis, e chamamos de corte de escopo ou aumento de prazo.

Vamos explorar aqui a relação do corte de escopo e do aumento de prazo com o ângulo que a linha ideal faz com o eixo X.

Observe a imagem abaixo, vamos destrinchá-la:

 

Burn-Up

Reproduzindo aqui as conclusões na imagem:

  • O modelo está representado pela hipotenusa r no ponto (30, 15) no plano cartesiano, tendo um ângulo alfa (𝛼) desta hipotenusa (h) com o eixo X de 27º;
  • Alteração para 5 unidades a mais no eixo X resulta em s em (35, 15) com 𝛼 de 24º, computando uma redução de 3º;
  • Alteração para 5 unidades a menos no eixo X resulta em t em (40, 15) com 𝛼 de 20º, computando uma redução total de 7º;

Agora, uma redução de apenas 5 unidades no eixo Y resulta em g em (30, 10) com um 𝛼 de 18º, resultando em uma redução total de 9º !! Esta redução é maior que a redução obtida com a ampliação de 10 unidades de X.

Uma combinação entre cortar escopo e ampliar o prazo também pode ser viável. Vejamos. O ponto (37, 13) produz uma angulação de 19º que representa uma redução de 8º na agressividade do projeto. Resultado obtido com a redução de 2 unidades de escopo e um aumento de 7 unidades no prazo.

O eixo X, como já vimos, acomoda o prazo e o eixo Y acomoda o escopo. Este estudo estabelece que “a redução de 10 unidades do escopo é melhor que o aumento de 10 unidades do prazo“? De forma alguma, porque os burn-ups do mundo real estão em unidades diferentes, diferente do modelo. Por exemplo, podemos ter o eixo X em semanas e estar falando de 80 opções para 8 semanas, por exemplo.

Putz. Li até aqui e esse negócio é inútil.

Esperamos que não. O objetivo deste modelo era provar que um esforço de redução no eixo Y pode resultar em um resultado mais de 3x superior que uma redução no eixo X. Se o seu sistema de trabalho processa, por exemplo, 30 opções por semana e o seu eixo X está em semanas, você terá uma escala aproximada de 30 pra 1 no teu gráfico.

Quando for tomar a decisão, na review de análise deste gráfico, tenha em mente essa proporção, que deve coincidir aproximadamente com throughput do sistema. Entenda que o objetivo principal dos cortes é corrigir uma anomalia entre o planejado e o realizado até aquele momento. Você quer aproximar a linha “ideal” da linha “real”.

Imagina que o sistema de trabalho da empresa SpaceY tem um throughput de aproximadamente 30 itens por semana. Agora imagina a empresa Testa que está operando com um throughput de 5 opções por semana. Ambas estão trabalhando em projetos de 3 meses de prazo estimado e acordado.

Se as pessoas responsáveis por dirigir esses desafios são conscientes, inteligentes e estão de fato preocupados com entregas importantes, que de fato irão mudar a SpaceY e a Testa de patamar, eles estão lidando com escopos em torno de 360 e 60 opções respectivamente. Lembrando que são 12 semanas de prazo inicial dos projetos.

Perceba que temos mais manobra na SpaceY e menos na Testa. Sem contexto, isso não significa absolutamente nada pois, por exemplo, não podemos garantir que a primeira faça melhores negócios que a segunda. Importante aqui é notar que a cada corte de semana, equivale ao corte de 10 itens de escopo na SpaceY, lembrando que numa semana da SpaceY cabem 30 opções e, em uma relação direta, um corte de 30 opções equivale a uma ampliação de 3 semanas. Lembrando que não é soma. Se cortarmos o equivalente a 2 semanas de escopo, 60 opções, precisaríamos de uma adição de 6 semanas para obter o mesmo resultado.

Exercite o contexto da Testa e você notará o mesmo padrão, apenas com números menores.

Voltando, isso significa que você precisará sempre cortar escopo? Claro que não. Significa que você precisa escolher, neste cenário hipotético, entre cortar 60 opções de 360 ou aumentar em 6 semanas o prazo. Se o projeto tem 1 mês e meio de folga, aumente o prazo e na semana seguinte faça a mesma análise. Não existem garantias entre as semanas e o objetivo principal deste post é fornecer ferramentas para uma análise semanal pragmática, quinzenal no máximo.

Você pode fazer uma regressão linear dos pontos que compõem o “real” no gráfico e ter a noção exata sobre o que fazer, podendo testar diversos cenários.

As coisas não acontecem da mesma maneira em todos os dias, todas as semanas ou todos os meses. O modelo precisa ser frequentemente analisado, revisado e, principalmente, corrigido para manter a compatibilidade com o mundo real.

Este post não será incluído no livro, porque acreditamos que muitas empresas já trabalham este tipo de análise. Vamos conversar nos comentários sobre quaisquer dúvidas, evoluções e ampliações deste trabalho.