Gráfico de burndown

Um gráfico de burndown é uma representação gráfica do trabalho a ser feito versus tempo. O trabalho restante (ou backlog) é geralmente no eixo vertical, com o tempo no eixo horizontal. É útil para prever quando todo o trabalho será concluído, frequentemente usado em metodologias ágeis de desenvolvimento de software, como o Scrum. No entanto, os gráficos burn down podem ser aplicados a qualquer projeto que contenha progresso mensurável ao longo do tempo.

O trabalho restante pode ser representado como tempo ou pontos de histórias.[1]

Interpretando o burndown editar

 
A project burn down chart

Um gráfico de burndown para uma iteração concluída, conforme mostrado acima, pode ser lido da seguinte forma:[2]

Eixo X editar

Cronograma do projeto/iteração. A unidade do eixo x

Eixo Y editar

O trabalho que precisa ser concluído para o projeto. As estimativas de ponto de tempo ou história para o trabalho restante serão representadas por este eixo. A unidade do eixo y pode ser em dias, horas ou pontos de estórias.

Ponto de partida do projeto (Start) editar

É o ponto mais à esquerda do gráfico, ocorre no dia 0 do projeto / iteração.

Ponto final do projeto (End) editar

É o ponto que está mais à direita do gráfico, ocorre no último dia do projeto / iteração

Linha de trabalho restante ideal (Ideal Work Remaining Line) editar

Esta é uma linha reta que conecta o ponto inicial ao ponto final. No ponto inicial, a linha ideal mostra a soma das estimativas para todas as tarefas que precisam ser concluídas. No ponto final, a linha intercepta o eixo x, mostrando que não há trabalho a ser concluído. Essa linha é um cálculo matemático baseado em estimativas, e as estimativas têm mais probabilidade de estar erradas do que o real.

Linha de trabalho restante real (Actual Work Remaining Line) editar

Esta linha mostra o trabalho restante real. No ponto inicial, o trabalho restante real é o mesmo que o trabalho restante ideal, mas à medida que o tempo avança, a linha de trabalho real flutua acima e abaixo da linha ideal, dependendo da diferença entre as estimativas e a eficiência da equipe. Em geral, um novo ponto é adicionado a essa linha a cada dia do projeto. A cada dia, a soma das estimativas de ponto de tempo ou história para o trabalho que foi concluído recentemente é subtraída do último ponto na linha para determinar o próximo ponto.

Removendo a variabilidade nas estimativas de tempo editar

Uma questão que pode ser notada nos gráficos é se a linha de trabalho real está ou não acima ou abaixo da linha de trabalho ideal depende de quão precisas são as estimativas de tempo originais. Isso significa que, se uma equipe constantemente superestimar os requisitos de tempo, o progresso sempre aparecerá antes do previsto. Se eles subestimam constantemente os requisitos de tempo, eles sempre aparecerão atrasados. Esse problema é corrigido pela incorporação de um fator de eficiência no gráfico de burndown. Após a primeira iteração de um projeto, o fator de eficiência pode ser recalculado para permitir estimativas mais precisas durante a próxima iteração. Alguns modelos calculam automaticamente a eficiência à medida que um projeto avança. Isso pode ser usado para identificar áreas / fases em que estimativas imprecisas ocorrem consistentemente.[2]

Assinaturas sprint (Sprint signatures) editar

Como uma equipe trabalha em conjunto, ela desenvolve seu próprio estilo de criação e manutenção do Backlog da sprint. Também demonstra padrões de trabalho exclusivos, alguns trabalhando consistentemente, outros no final de uma sprint. Ao longo do tempo, os gráficos de backlog de cada equipe desenvolvem padrões previsíveis, elas se estabilizam à medida que a equipe aprende a tecnologia, o negócio ou o domínio do produto e entre si. Esses padrões gráficos são chamados de assinaturas Sprint:[3][4]

  • Fakey- Fakey: O Fakey-Fakey é caracterizado por uma forte e regular descida até a conclusão. A maioria dos softwares é suficientemente complexa e precisa ser descoberta ao longo do caminho. Apresentar um progresso regular e previsível em um campo complexo e em constante mudança é, na melhor das hipóteses, pouco sincero e, na pior das hipóteses, falso, apresentando uma falsa impressão sobre o estado do projeto. É frequentemente apresentado por equipes que estão operando em um ambiente de “comando e controle”, onde ficam desconfortáveis ​​em serem abertas e honestas.
     
  • Late-Learner: Tem uma corcunda de aprendizado (indicada pelo sombreado azul) no final de uma iteração. É comum para novas equipes que ainda estão tentando se comunicar de forma eficaz e criar um software que é "Feito" no final da Iteração. Em equipes recém-formadas, o atraso é geralmente devido a uma percepção tardia de que o teste é uma parte importante do fornecimento de software demonstrável ao final de uma Iteração.
 
  • Middle-Learner: À medida que a equipe começa a amadurecer, a ênfase é colocada na descoberta anterior, especialmente na definição inicial do que precisa ser testado. Isso ajuda a mover a maior parte do trabalho para o meio do Sprint, conforme mostrado abaixo.
 
  • Early-Learner: As equipes que estão apresentando um bom desempenho geralmente terão um gráfico da Sprint com uma corcunda inicial e, em seguida, uma queda gradual. Neste caso, a equipe aprendeu a importância da descoberta precoce geralmente pela definição inicial do que precisa ser testado. Uma vez que eles tenham uma definição mais substancial do que precisa ser realizado no Sprint, eles trabalham constantemente para alcançá-lo.
 
  • Plateau: Embora as equipes estejam tentando encontrar um equilíbrio entre o aprendizado antecipado e o aprendizado tardio, elas geralmente passam por uma fase em que inicialmente progridem bem, mas esse progresso não é levado até o final do Sprint.
 
  • Never-Never: Times que trabalham bem até um evento inesperado ocorrer no final do sprint, apresentam uma linha decrescente estável e no final do sprint uma curva crescente. A curva pode ocorrer porque o time esclareceu algo muito tarde ou o Product Onwer mudou o escopo, dificultando ou impossibilitando atingir as metas. Essas mudanças tardias devem ser levantadas e resolvidas na retrospectiva.
 
  • Scope-increase: Esse gráfico possui um pico repentino na linha de trabalho restante, sendo comum em times que não analisam o escopo do trabalho
 

Gráfico burnUp editar

Um gráfico de burnup fornece informações sobre o status do projeto como um todo e não apenas do sprint, como é o caso do gráfico de burndown. O gráfico burnup consiste em faixas que representam o progresso em direção à finalização do projeto. Simplificando, existem duas linhas no gráfico:

  • Uma linha de trabalho total (a linha do escopo do projeto);
  • Uma linha de trabalho concluído.

Desta forma, o gráfico mostra tanto o escopo do trabalho como também o projeto concluído, com a iniciativa sendo finalizada na medida em que as linhas se aproximam.[5]

 

Ver também editar

Referências

  1. George Dinwiddie. «Feel the burn – Getting the most out of burndowns charts» (PDF) 
  2. a b Wenzel, Joel (2012). Burn Down Chart Tutorial: Simple Agile Project Tracking. [S.l.: s.n.] 
  3. Vikas Hazrati. «Analisando gráficos de Burndown» 
  4. Scrumology. «Sprint Burn Down Graph Signatures» 
  5. [https:/www.projectbuilder.com.br/blog/agile-entenda-o-que-e-o-burnup-chart/ «Agile: entenda o que é o burnup chart»] Verifique valor |url= (ajuda)