Nelson Correia

.NET Thinking Machine

My Links

News

Search



Blog Stats

Archives

Post Categories

.NET

Links

Login
    u:
    p:
    Remember Me:
     

Tuesday, December 18, 2007 #

Scrum - Sprint Burndown

Um dos artefactos resultantes da aplicação de Scrum a um projecto é um gráfico com o Sprint Burndown. Este gráfico mostra o trabalho por fazer versus trabalho já feito. Assim, o espectável é acabar o sprint com um gráfico cuja linha do trabalho por fazer comece no máximo e acabe em zero e o inverso para o trabalho completo. Algo deste género:

burndown2[1]

Começamos o sprint com tudo por fazer e nada feito e a uma velocidade mais ou menos constante, caminhamos para o final do sprint, onde temos o trabalho todo feito e nada por fazer.

Então e o que acontece quando no início do sprint não sabemos bem o que fazer (ou não o planeamos bem) e à medida que este decorre, vamos adicionando itens ao sprint backlog? Imaginemos que no início do dia adicionamos ao backlog aquilo que nos propomos a fazer durante esse dia e no final marcamos esse trabalho como completo. O que obtemos com esta abordagem é um gráfico deste género:

burndown[2]

Um pouco estranho... Parece que o tempo foi passando e nada de trabalho feito. O terror de qualquer gestor de projecto! Isto acontece, porque como á granularidade temporal deste gráfico é o dia, se fizermos como disse acima (adicionar itens de manhã e marcá-los como completos ao final do dia), obtemos um gráfico deste género, onde se vê o número de horas de trabalho a aumentar e o número de horas de trabalho por fazer sempre constante (devido a itens adicionados no início do sprint e que ainda não foram concluídos).

Conclusão: sempre que possível façam um planeamento do sprint por inteiro. A adição de itens ao sprint backlog no decorrer do sprint, apesar de possível, deve ser evitado e encarado como uma excepção.

posted @ 6:23 AM | Feedback (0)