Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Marcelo Nunes
Existem distintas formas de se acompanhar o andamento de um projeto. Praticamente cada modelo de gerenciamento sugere sua própria forma de seguir de perto como anda o desenvolvimento das tarefas. Gráfico de Gantt, gráfico focado em produtividade do Kanban e etc… são apenas algunas exemplos do que é utilizado hoje no acompanhamento de projetos em TI. Acredito que a maioria dos leitores esteja acostumada e familiarizada com os gráficos de Gantt. Apesar de serem bastante difundidos e utilizados mundo afora, pessoalmente julgo que esse método de acompanhamento funciona muito bem quando o foco são datas de entrega ou planejamentos de longo prazo. Quando focamos no acompanhamento da produtividade de uma equipe no dia-a-dia, o gráfico burndown do SCRUM e o baseado na produtividade do Kanban se mostram muito mais robustos e evidentes.

A principio se vê o rosto de uma mulher, porém ao observar mais atentamente, também se vê um saxofonista.

Para este post, vou focar no gráfico de burndown. Neste gráfico, o eixo horizontal representa os dias de duração de uma sprint e o eixo vertical a quantidade de tarefas que ainda não foram cumpridas dentro do espaço de tempo determinado. Dessa forma, todos os dias a gerência da equipe pode verificar a produtividade do dia anterior e qual a meta que precisa ser alcançada para que todas as tarefas que ainda restam consigam ser finalizadas no prazo.
Acredito que a maior dificuldade para a equipe de gestão de um projeto SCRUM é saber interpretar os dados que lhe são mostrados no gráfico e como repassar essas informações preciosas para o product owner do projeto ou o cliente em questão. Sprint passada enfrentei um problema similar. Algumas alterações no burndown não foram bem interpretadas pelo product owner do projeto. Percebi que, apesar de atingir muito bem seu objetivo, algum tipo de informação relevante estava faltando ali. É como se a informação estivesse na frente dos nossos olhos, mas a nossa forma de pensar estivesse bloqueando o real entendimento.
Decidi então adicionar uma nova curva ao burndown. Ao invés de mostrar somente a curva da quantidade de tarefas “queimadas” durante os dias da sprint, coloquei também uma nova curva onde apresentávamos a evolução do número total de tarefas. Pode parecer estranho para alguns, mas no SCRUM as tarefas que devem ser executadas em cada iteração podem variar de acordo com a demanda. Durante uma sprint, podemos tanto remover como adicionar novas tarefas e justamente essa visibilidade foi a que senti que estava faltando no burndown do meu projeto. Uma descida mais suave no gráfico de produtividade não significa que a equipe teve uma baixa produtividade, mas sim a influência do incremento do número de tarefas a serem executadas naquele período.

Gráfico de Burndown exibindo a curva com a evolução do número total de Tarefas

Arquivado em:Agilidade, Tudo

Source: http://bytesdontbite.com/2011/04/17/acompanhando-projetos-atraves-do-grafico-de-burndown/

Category: Agilidade, Tudo

Você também pode querer ler

Comments are off for this post.