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!!!!!
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%
“Corinthians perdeu no Sprint anterior”…
No ano passado… o sprints devem ter sido trágicos!!!!
heheheheh
Ótimo post!!!
Parabéns!
@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.
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.
Pingback:Quantos pontos devemos fazer em um sprint? « Nelson Hochman
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?”
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!