Calibrando nossa “Bola de Cristal” – Scrum, Estimativas e Datas de Entrega

Qual a estimativa? Eu tenho certeza que você já gastou muito tempo de suas “Sprint Plannings” estimando tarefas… e no final das contas errou feio!

Desenvolver software é uma atividade extremamente criativa, com centenas de formas de se chegar ao mesmo resultado “funcional” e com muitos e muitos desafios que só serão descobertos em tempo de desenvolvimento.
Além da tradicional estimativa em “horas de desenvolvimento“, temos outras abordagens como Análise de Pontos de Função, Planning-Poker, T-shirt Size ou ainda #noEstimates [1] (que defende ser um desperdício estimar o esforço do trabalho).
Estimativas são importantes para definirmos uma meta da Sprint “atingível” e nos comprometermos com datas de entrega.
Mas afinal, por que precisamos saber quanto tempo leva para fazer?
Uma Sprint não acaba “após X horas consumidas pelo time”, não paramos o desenvolvimento “após X pontos produzidos”. A Sprint acaba em uma data! Um determinado “dia do calendário” define o final da Sprint! Pensando nisso, me parece mais importante “estar pronto no dia X” do que “consumir X unidades de estimativa”.
Uma abordagem bastante utilizada na MATERA é estimar as tarefas em “data do fim de desenvolvimento“. Nossos times Scrum são encorajados a responder “que dia fica pronto?” para cada tarefa, o que tem simplificado bastante o trabalho de estimar e melhorado o gerenciamento do tempo (se uma tarefa não está pronta na “data do fim”, está atrasada).
O acompanhamento da Sprint não utiliza “gráfico de burndown”[2], mas uma planilha que batizamos de “Matriz de Tarefas” (figura 1).

matriz_tarefas

Figura 1 – Matriz de Tarefas.

Em cada linha temos as tarefas prevista para cada desenvolvedor e nas colunas os dias do calendário da Sprint. Este cenário inicial se altera bastante no decorrer da Sprint, pois as tarefas podem não ser realizadas pelo desenvolvedor previsto inicialmente (o desenvolvimento segue a ordem de prioridade dos incrementos). Esta abordagem faz com que o time se auto-gerencie (trabalhamos com Scrum, certo? [3]) e se comprometa com tarefas que devem estar prontas ao final do dia, de modo a manter o cronograma previsto.

Em sua próxima Sprint, experimente não utilizar “unidades de estimativa” e pergunte ao seu time: “Que dia fica pronto?” para cada tarefa ou estória. Volte aqui e me conte como foi!

Links Externos

[1] http://blog.kudoos.com.br/gestao/gestao-de-riscos-e-no-estimate-dois-temas-comentados-por-grandes-agilistas-brasileiros/

[2] http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisellePlugin/guidances/concepts/graficoBurndown_B9AC47B7.html

[3] http://blogdocaze.com.br/2015/09/18/palestra-desenvolvimento-agil-com-scrum/

Por ANDRÉ SUMAN

Computeiro, mágico, sanfoneiro, motorista pós-balada, cantador de bingo... entre outras atribuições.

Postado em: 09 de outubro de 2015

Confira outros artigos do nosso blog

Como a comunicação influencia em times ágeis?

15 de junho de 2018

Ariane Ferreira Izac

Vamos falar sobre métricas Kanban?

21 de maio de 2018

Ricardo Augusto Shikota

Método Kanban: primeiros passos

10 de maio de 2018

João Paulo Grabosque

Afinal, o que é Scrum Master?

20 de abril de 2018

Fernanda Rogge Barbosa

Deixe seu comentário