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 ter previsibilidade no método Kanban

12 de março de 2019

Ricardo Augusto Shikota

Agilista: você já pensou em adaptar seus comportamentos para extrair o melhor do seu time?

29 de novembro de 2018

Fernanda Rogge Barbosa

Tudo o que rolou no Agile Brazil 2018!

30 de outubro de 2018

Karina Costa Mineiro

Do Scrum para o Kanban: quais são os desafios dessa transição?

02 de julho de 2018

Reinaldo Simizu

Deixe seu comentário