Estimativa não é ciência exata

Perguntinha na lista scrum-brasil@yahoogrupos.com.br:

Para se saber quantos pontos cabem na sprint atual, tomamos como base a sprint anterior certo? Dessa forma, vamos que seja colocada na sprint atual a mesma quantidade de pontos que foi atingida na sprint anterior.

Porém pelo que entendi, não temos a velocidade individual de cada um na sprint, não sabemos quantos pontos CADA DESENVOLVEDOR cumpre, pois cada um tem uma velocidade (baseada na capacidade, experiência, enfim, uma pessoa nunca é igual a outra). Só que como vamos saber qual será a velocidade da equipe na próxima sprint, ou seja, como vamos saber quantos pontos caberão na sprint, se a cada sprint eu tiver uma quantidade de pessoas diferentes trabalhando na sprint?

Porque eu pergunto isso? Imaginem que na sprint anterior tivemos 4 desenvolvedores trabalhando full time. Na próxima, um deles não poderá trabalhar 1 dia (irá fazer uma viagem a trabalho, por algum motivo) e outro faltou por uma questão de saúde, por exemplo. Dessa forma, minha velocidade já não é a mesma, pois não tive 4 pessoas full time.

Como tratar essas situações? Inclusive isso é muito comum na minha opinião.

Bem, estimativa não é uma ciência exata…

Uma das coisas que mais gosto nas práticas ágeis de planejamento e estimativa é exatamente o fato de não existir métricas individuais. Sim, nas equipes existem pessoas mais produtivas do que outras, porém, a variabilidade é tão grande entre pessoas e entre iterações que isso não vale a pena ser controlado, pois não somos robôs. Fred Brooks diz que há variação de até 80% na produtividade entre programadores. Algo que não ocorre com pedreiros como exemplo.

As práticas do Scrum e das estimativas ágeis (Planning Poker, literatura do Mike Cohn) são muito humanistas. Não são fatores deterministas que darão a produtividade da equipe. Se alguém na equipe teve que se ausentar, está com problemas na família, está doente ou está grávida, tudo isso é levado em conta na sua velocidade e ninguém é melhor que a própria equipe para fornecer parâmetros sob essa ótica tão empírica. Não é um gerente ditador que faz a equipe engolir a métrica. A EQUIPE É RESPONSÁVEL PELA ESTIMATIVA, sob todos os aspectos. É isso que faz a métrica funcionar.

No treinamento Scrum da Aspercom nós temos atividades práticas com estimativas ágeis, e é muito interessante como a aceitação de tal métrica é geral. Vejo o mercado cansado de métricas pesadas e pouco assertivas.

Respondendo a pergunta do nosso amigo do fórum, nas minhas equipes, no “planning” rolaria uma conversa mais ou menos assim:

“Se na Sprint 3 fizemos 39 pontos com todo mundo e nessa Sprint 4 o Claudervanderson vai viajar 1 dia, vamos estimar nossa velocidade em 37 pontos, fazendo as stories X, Y, Z, W, H, U, V, O…. concordam?”

A resposta para a velocidade sempre é dada pela Equipe… pense na velocidade como uma tendência e não como uma certeza. Pense na velocidade como uma aplicação financeira com riscos: “rentabilidade passada não garante rentabilidade futura”.

[photopress:BusinessPeoplePlanning.jpg,full,pp_image]

No cenário acima, se na Sprint 4 o Valdercleudiney ficar doente uns dois dias e vocês matarem 32 pontos ao invés de 37, não precisamos cortar os pulsos. Isso era esperado, certo? Então, no Planning da Sprint 5 pode rolar uma conversa assim:

“Bem, nessa Sprint 5 ninguém estará ausente e o Valdercleudiney melhorou. Vamos estimar nossa velocidade em 39 novamente? Concordam em planejar as Stories U, V, O, M, N, L, Q?”

A decisão é em grupo. Repetindo: É empírico.

Ou então você pode usar a tabela de fatores de correção da AMM:

Dor de Dente -4%
Enxaqueca -22%
Diarréia -46%
TPM -84%
Corinthians perdeu no Sprint anterior -26%
Gravidez -36%
Briga na família -26%
Problemas com alcolismo -21%
Diretor está de férias -49%
O cara que cuida dos processos está de férias +75%

Francamente!!!!!

About The Author

rodrigoy

Instrutor e Consultor Sênior - ASPERCOM

Deixe sua opinião!

10 Comments

  • Muito bom esse post, Rodrigo! Me poupou de ter que escrever essas mesmas coisas pra responder a essa thread lá na scrum-brasil 🙂

  • Hehehe, muito legal cara. Morri de rir 🙂

    []s

  • No caso de alguns diretores que conheço acredito que ficaria assim:

    Diretor está de férias +49%

  • Marcelo Bruckner

    Reply Reply 03/04/2009

    “Corinthians perdeu no Sprint anterior”…
    No ano passado… o sprints devem ter sido trágicos!!!!
    heheheheh

    Ótimo post!!!
    Parabéns!

  • Rodrigo Yoshima

    Reply Reply 03/04/2009

    @Tiago

    Pois é! Porém, o -49% é que a equipe relaxa!! he he he

    @Marcelo

    Cara, pensei umas 20 vezes antes de aprovar esse teu comentário. Curintianos, retaliações aqui no blog não serão toleradas.

  • Rafael Ponte

    Reply Reply 08/04/2009

    Excelente post Rodrigo.

    Estimativa de software é uma das coisas mais incertas que existem, é muito dificil estimar alguma funcionalidade, correção etc, e isso varia muito de desenvolvedor para desenvolvedor, no final das contas a experiência de cada um conta muito.

    Sem falar que já é muito dificil medir a produtividade de um time inteiro de desenvolvedores, imagine medir a produtividade de um membro da equipe.

    Como você disse, é algo realmente empirico.

    Enfim, excelente post, parabéns.

  • Almiro Alves

    Reply Reply 04/12/2009

    Olá Rodrigo,

    Primeiramente parabéns pelo problema levantado, acredito que a estimativa é a maior culpada de todos os sucessos e insucessos de qualquer produto, sem dúvida.
    Mas tem um ponto que ainda fico em dúvida, e isso eu não sei se não entendi direito ou se minha dúvida faz sentido.
    Mas quando você fala que baseado em pontos de um Sprint Backlog anterior, nós podemos estimar o atual, e descontar pontos para os possíveis problemas, estamos falando de algo previsível no momento da estimativa do Sprint Backlog, como por exemplo, viagens, treinamentos e etc. E para os casos imprevisíveis? Como por exemplo caso de saúde e etc? Vc concorda que não tem como saber isso no momento do Sprint Backlog?

    Abraços.

  • @Almiro

    Exatamente, não temos bolinha de cristal, certo? Então, nesse caso a velocidade será menor ao terminar o Sprint, e não há nada, absolutamente que possamos fazer neste caso.

    “A velocidade que estimamos era 38, mas por conta do atropelamento do gato da Marecilda, e sua ausência nos 3 últimos dias prejudicou e fizemos só 32 pontos… Agora que o Fulcherbison (o nome do gato) se recuperou e a Mare está de volta podemos estimar novamente em 38?”

  • Wylker

    Reply Reply 25/02/2011

    Olá Rodrigo, boa noite.

    venho tentando dar precisão não nas estimativas, mas na capacidade de produção realista suportada em uma sprint. Explicando melhor, utilizo variaveis que me darão a dimensão de horas/pontos possiveis dentro do sprint. Dentre as variaveis, são abordados: HH semanal; Time Box; Tamanho da sprint (2,3 ou 4 semanas); numero de desenvolvedores; porcentagem de reprovação no teste(estimada); tempo de correção das tarefas que retornaram do teste(estimada); e tempo de teste sobre tarefa(estimada). Abaixo um exemplo:

    – Horas /Homem Semanal (HS)
    – Número de Desenvolvedores (ND)
    – Número de Testadores (NT)
    – Time Box (TB) – 2,3 ou 4 (Semanas)
    – Porcentagem de Retorno do Teste (PRT) = % de tarefas que não passam no teste durante um Sprint
    – Tempo Estimado do Teste/ Tarefa (TET) = %ET: Tempo em relação a tarefa destinado ao teste (exemplo: se uma tarefa possui um tempo estimado em 10 horas, e o TET é 150% logo o TET em relação a tarefa é 15 horas)
    – Tempo de Correção das Tarefas (TCT) = %ET: Tempo em relação a tarefa destinado ao correção (exemplo: se uma tarefa possui um tempo estimado em 10 horas, e o TCT é 40% logo o TCT em relação a tarefa é 4 horas)
    – Impacto dos Riscos (RI) = Porcentagem do impacto dos impedimentos sobre a produção.

    Para se saber a capacidade realista de produção utilizo a seguinte formula:

    Capacidade Realista de Produção do Desenvolvimento (RPD) = (MPD*(1-RI)) / (1+PRT*TCT)

    Com isso, eu posso mensurar o tamanho real da sprint (a capacidade de produção). Daí cabe a equipe estimar o quanto de estória vai caber nesse espaço (RPD). Adianto que estamos tendo resultados muito próximo do previsto.

    Sei que ficou um pouco complicado de entender, nao eh uma fórmula convencional e talvez precisasse de uma maior explanação. Mas funciona! rsrs!

Leave A Response

* Denotes Required Field