Agile Way

Uma das ferramentas do SCRUM mais legais e mais motivadoras, é o gráfico de Burndown. Neste artigo, eu irei procurar apresentar a forma como eu utilizo o gráfico em meus projetos de SCRUM. É apenas uma sugestão que você pode, ou não, aderir. Fica a seu critério

O gráfico de Burndown é uma forma visual e rápida de enxergar o status atual do projeto. Ele possui uma estrutura simples, onde:

- Eixo X: representa os dias do sprint
- Eixo Y: representa o trabalho restante

O trabalho restante pode ser definido de acordo com a sua necessidade. Algumas pessoas utilizam pontos, algumas pessoas utilizam horas, outros dias e assim por diante. O uso com pontos, geralmente ocorre com a atualização do gráfico apenas quando uma user story é finalizada. Ou seja, teoricamente teremos um gráfico cuja linha será horizontal até a finalização de uma tarefa, algo mais ou menos com está apresentado abaixo:

Notem que dessa forma o gráfico é facilmente atualizado, mas não representa uma visão de curto prazo. Já com a utilização de métricas baseadas nas tarefas, conseguimos um resultado mais real do atual status do projeto. O gráfico irá representar, diariamente, se as horas/dias/task stories foram vencidas ou não. E ainda poderá apresentar um acréscimo de horas, quando surgirem tarefas não-planejadas. O gráfico ficaria mais ou menos assim:

Notem que temos uma visão mais de curto prazo, o que torna o gráfico mais interessante para visualização. A dificuldade, neste caso, é mantê-lo atualizado sempre, pois basta um dia perdido, e você se perderá na hora de atualizá-lo novamente.

Como eu disse, existem várias formas de medir o trabalho restante: horas, dias, user stories e até mesmo task points. Isso vai muito da vontade de cada um de estimar as tarefas de cada user story. Só não recomendo o uso de “task points” pois é realmente uma perda absurda de tempo para isso!

Eu tentei estimar as tarefas. Porém comecei a ver que estávamos já andando para o “micromanagement”, ou seja, estávamos perdendo tempo estimando um esforço que não seria necessário. Por quê? Pois utilizamos o conceito de ONE-DAY TASK, ou seja, as tarefas devem ter no máximo 1 dia de duração. Para facilitar, pensamos em tarefas que durem MEIO-DIA ou UM DIA.

Pensando dessa forma, qual seria a necessidade de perder tempo setando que a tarefa A tem 4 horas (meio-dia) e a tarefa B tem 8 horas (um dia, não considerando “horas trabalhadas”)? Vocês concordam que seria bastante complicado ficar atualizando o gráfico assim?

- “Pessoal, vamos atualizar nosso Burndown. Faltavam 84 horas ontem. Hoje matamos as tarefas A, B e C. A tarefa A tinha 4 horas, a B e a C 8 horas. Portanto temos que descontar 12 horas”.

Parece mais uma daquelas “historinhas matemáticas” que tínhamos que resolver no colégio.

Ao invés disso, resolvemos simplificar lá no trabalho. Agora nós apenas CONTAMOS as tarefas. Se temos 20 tarefas, então temos 20 “pontos” para vencer. Se uma tarefa não-planejada surgir, então acrescentamos 1 “ponto” ao gráfico.

Muitos afirmam que isso é inútil. Afinal, se for para contar apenas as tarefas, basta olhar para a taskboard e ter essa visão. Pode ser. Mas sinceramente, eu já percebi que o Burndown tem uma característica única: ele é um agente motivador!

TODOS os meus subordinados, quando falei que voltaríamos a usar o SCRUM, pediram para voltarmos a usar o burndown. Durante a palestra que eu dei para aquela turma de GP, a grande maioria concordou que olhariam primeiro para o burndown para depois olharem as tarefas.

Esta é, portanto, a minha maneira de utilizar o burndown. Ele não representa pontos nem horas, pois não perdemos muito tempo estimando as tarefas. O burndown, para nós, é apenas um agente motivador. Uma ferramenta visual para agilizar e motivar o grupo a cumprir as tarefas.

Eu sinceramente não acredito em certo e errado em qualquer metodologia. Eu acredito em aplicar as ferramentas de acordo com a sua realidade e necessidade. E por isso, posso afirmar que o burndown dessa forma não só resolve nosso problema, como também é um agente motivador.