Estimar prazo com Planning Poker em Scrum

Entusiasta Java Membro desde: 28/10/2008 15:08:02 Mensagens: 24 Offline

Olá galera

eu mais uma vez aqui no forum fazendo perguntas sobre métricas

Estou pesquisando muito sobre Planning poker, em sites ingles tambem

Mas o que não conseguir entender as seguintes coisas:

Planning poker é para estimar prazo ou valor do negocio?

Se Planning Poker é para estimar prazo, como eu extraio o prazo atravez das cartas de fibonacci?

Eu encontrei a métrica ideal day que utiliza as cartas, ai de vez ser fibonacci é utilizado por dia, ai é para isso que ela é utilizada

Grato pessoal

É um processo empírico. Geralmente a dinâmica é a seguinte: o time pega uma estória que considera a menor e atribui o valor 2 a ela. A partir daí as demais são estimadas por relatividade. Ex: O quão maior/mais difícil é fazer X do que Y? Daí se calcula o valor.

Depois de tudo estimado, vocês vão chegar a algum total. Ex: 50 pontos. Uma abordagem é usar o feeling e separar as estórias que vocês "acreditam" conseguir entregar dentro do tempo do período de iteração/sprint (e.g 5, 15, 30 dias). Da próxima vez, dá pra ser usado como base o resultado obtido.

O mais importante é perceber que o processo é empírico. Não é possivel prever muita coisa, mas dá pra ir ajustando com o tempo pra ter uma noção da velocidade do time.

[]s

Entusiasta Java Membro desde: 28/10/2008 15:08:02 Mensagens: 24 Offline

Então, eu que tenho que definir +/- o tempo de cada carta?
Ex.: Carta número 8 é o que vale 5 horas

+/- mesma coisa que Ideal Day entao??

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

mateushim wrote:Olá galera

eu mais uma vez aqui no forum fazendo perguntas sobre métricas

Estou pesquisando muito sobre Planning poker, em sites ingles tambem

Mas o que não conseguir entender as seguintes coisas:

Planning poker é para estimar prazo ou valor do negocio?

Se Planning Poker é para estimar prazo, como eu extraio o prazo atravez das cartas de fibonacci?

Eu encontrei a métrica ideal day que utiliza as cartas, ai de vez ser fibonacci é utilizado por dia, ai é para isso que ela é utilizada

O que é dificil de entender no scrum - no agil em geral - sobretudo para quem é educado ou pensa da forma tradicional de custo/hora é que existem fatores independentes.

Planning poker não serve nem para estimar o prazo nem para estimar o valor de neogico. Estranho ? Não. Estranho é desenvolvedores cobrarem por hora.

PlanningPoker (PP) serve para estimar esforço relativo.

Esforço - trabalho necessário para fazer algo.
Relativo - comparado com outros do mesmo tipo.

O PP serve para fomentar o dialogo (um dos principios ageis :comunicação) entre a equipa scrum (PO + SM + desenvolvedores)
Para que todos entendam as dificuldades e tenham a mesma noção de tamanho do software.

bom, esforço é como um tamanho. Ele é discreto ( ou seja, existem tamanhos pre definidos onde tem que encaixar, como as camisas. as pessoas tem que se encaixar nos tamnhos que existem. E em caso de duvida escolhem um tamanho maior )

Com o tamanho cotado em SP o prazo advém da velocidade da equipa e da distribuição das historias em releases. O custo advém de manter a equipe trabalhando em condições durante esse tempo. Para detalhes leia isto. Dê uma lida no resto do material de scrum nesse site.

Agora, o que os dias ideias têm a haver com a historia ?

Quanto vale 1 SP ?

A resposta é : não vale nada porque a escala é relativa. Su so sei que se A tem 2SP e B tem 8 , então B demanda 4 vezes mais esforço que A. Mas quanto tempo mais ? Depende da velocidade da equipa. Se a velocidade da equipa é 9, os dois demoram o mesmo tempo, porque os dois serão feitos em 1 sprint.
O tempo, em scrum, é medido em sprints e não em dias ou horas. E os sprints tem tamanho fixo.

A matemática do scrum é bem simples, mas bem diferente do que estamos habituados. Ela usa matemática de inteiros em vez de decimais e isso causa muito espanto. Mas é essa matemática diferente que faz com que o processo seja mais...digamos..."exato".

Mas quando a equipa tem pouca experiencia com scrum e não conhece muito a sua velocidade existe uma forma alternativa de estimar. Nesta forma existe um vinculo semi-relativo entre os SP e o que se chama de dias ideais. eu acho esta forma mais facil de entender e ela promove mecanismos mais intuitivos e mais justos.

O que é um dia ideal ? É o esforço que um programador de um certo grau pode executar em 1 dia de trabalho se ele fosse fechado numa sala com comida e bebida para sem que ninguem o incomodasse e ele não se disperssase em tarefas outras que não a de desenvolver (nada de ver email e consulta o ranking com campeonato)

Um dia de trabalho tem 8h, sem contar extras porque em scrum ninguém trabalha extra.
Veja que um dia ideal é uma medida de esforço, de trabalho, não de tempo ( o nome pode enganar)

normalmente escolhe-se um grau que seja compativel com a equipa dedesenvolvedores. Se todos são juniors, escolhe-se junior.
Se existe a maioria é pleno, usa-se pleno, e se existe algum sênior, usa-se o sênior. Repare que 2 SP de Sênior demoram diferente que 2 SP de junior porque as velocidades são diferentes. Mas o esforço em si mesmo é igual.

Agora a escala relativa é mais facil de usar. Antes vc teria ter quer uma estória que vc considera 1 e depois as outras são relativas a ela. Mas isso é muito dificil de acertar sem uma escala absoluta por baixo. Se 1 SP for mudar a cor de label, estamos inchando a escala porque criar uma tela inteira seriam 200 SP (sei lá) , mas de 1SP = 1Dia ideal é obvio que mudar a cor tem que ser menos que 1 ( 0.5 ou 0 mesmo :lembre-se que 0 tem um significado especial no Planing Poker).

Mesmo que vc não use scrum, vc pode usar esta forma de estimar esforço.

Um projeto de software é baseado em 4 "coisas" : Prazo (tempo) , Custo (dinheiro/valor) , Esforço (trabalho) e Qualidade.

Num projeto tradicional faz-se : qualidade = não me importa , Prazo = fator_k * Esforço , Custo = Fator_q * Prazo , Esforço = horas estimadas para o desenvolvimento (só para o desenvolvimento, não para teste, design , refactoring, etc... )

em que fator_k =1 e Fator_q = custo por hora.

formulinha básica. Básica demais e por isso que não funciona!

Cara,

só vou postar aqui pq estava escrevendo enquanto o sergio respondia! E deu mo trampo! kkkk

Eai Mateus,

falar de métricas num post rápido assim é meio complicado mas vamos lá.

Primeiro, existe uma razão onde a precisão da métrica esta ligada ao tempo que vc tem para medir, assim, se vc me der 1 ano para fazer uma analise de um use case / story com certeza vou conseguir te dar um estimativa muito boa e assertiva (não levando em consideração o livro The Mythical Man Month).

Sem duvidas essa situação não existe.

Uma outra coisa que precisa ser levado em consideração é que estimativas "estão sempre erradas", o que quero dizer com isso é que impossível dizer se a data bate, não da para prever o caos, isso é coisa de esoterismo, um exemplo tosco é imagina uma epidemia H1N1, que não só tira gente da equipe como tira a paz das pessoas doentes e baixa a produtividade (ohhh minha irmã esta doente, meu deu estou preocupado!!)

O ponto é que precisamos estimar para ter uma idéia de recursos, como tempo e grana etc.

Mas a estimativa esta diretamente ligada a VELOCIDADE do SEU TIME, toda métrica só fica madura dentro depois de um tempo que essa equipe esta trabalhando junta, 6 meses mínimo, ai podemos entender sua velocidade e isso é o decisivo para uma boa estimativa.

Ao invés de "quanto tempo leva para fazer isso" o correto é "quanto tempo, esse time, leva pra fazer isso".

Assim, o mais importante de tudo, não é estimar, e sim MEDIR!

Medir o tempo que sua equipe leva para fazer alguma coisa será a melhor maneira de conseguir estimar algo corretamente.

Agora, o que é esse alguma coisa? Um story? um epic? um use case?

Todos estão certos, o que vale é o que é melhor para vc e sua equipe!

Ai entra o Poker ... Quando vc começa com o poker, vc pega a story, que todo mundo em consenso, acha que é a menor e pega a que todo mundo acha que é maior (lembre-se, não precisa ser necessariamente a maior ou a menor, o importante é existir algo para ser usado como referencia/comparação).

Ai vc DEFINE essa menor, digamos, representa o numero 2, quanto representa a maior? Ai todos juntos chegam a um
Consenso, digamos 13.

Ai vc começa a estimar as stories usando essas comparações como referencia.

No final, o que vc tem?

NADA?

Vc tem um monte de stories com uns números que não querem dizer nada! Mas o que você tem na mão é a proporção entre elas!!!!

Ai vc pega algumas dessas stories (priorização do back log) e começa a quebrar em tarefas menores, até que vc encha sua sprint. Nas tarefas menores, vc pode estimar um numero especifico de horas, já que vc ta no nível: "criar tabela X", fazer DAO Y, etc ...

Ai vc começa a sprint, e vê realmente, quanto tempo uma story que era 1 levou, quanto uma que era 5 levou, etc etc.

De posse desses números, vc pode rever, na próxima reunião de planejamento, os valores da sua métrica, fazendo acertos aos tamanhos das stories etc.

Em algumas iterações vc vai chegar a um numero médio de horas por story DA SUA EQUIPE! Você pode usar esse numero médio (tendo em mente o desvio padrão, etc) para estimar novos projetos que serão executados POR ESSA MESMA EQUIPE!

Essa é maneira que encontrei de chegar mais perto de estimar algo mais perto do real, mas sempre lembrando que NADA, NADA, NADA, mas NADA mesmo garante que vai estar certo!

Vc percebeu que o numero da carta do poker não esta tão diretamente ligada a um numero de horas, o segredo é começar com uma referencia para comparação, vc poderia usar raças de cachorros por exemplo:

"essa story é um chiuaua, essa aqui é um são bernardo"

Depois de umas sprints vc sabe quanto tempo leva um são bernardo!

O fibonatti é usado, por que a diferença entre os números cresce, representando a incerteza, que aumenta nas stories maiores, por exemplo, eu sei que fazer um insert no db é bico, leva exatamente 10 minutos, agora, fazer integração com um web service de um cliente X, é mais difícil:

Isso leva uma hora! (Fácil de estimar)
vs
Isso leva 234,5 horas! (Como chegou a precisão desses números quebrados? O correto seria umas 230 horas)

Te recomendo um livro chamado Agile Estimation and Planning, é muito phoda!

http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

Abraço,

Claudio

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Só uma pergunta,

os clientes sempre querem saber o quanto vão desembolsar num projeto antes dele ter começado. O que vocês respondem? Como calculam um valor de entrada/custos iniciais?

mateushim wrote:Então, eu que tenho que definir +/- o tempo de cada carta?
Ex.: Carta número 8 é o que vale 5 horas

+/- mesma coisa que Ideal Day entao??

Como eu disse no post anterior, em Scrum é por relatividade. Pega-se o que considera o mais fácil e atribui-se o valor 2. A partir daí faz por relatividade. O tempo é o tempo do Sprint (e.g. 10 dias). O que couber nesse tempo é o que "provavelmente" será entregue.

Para complementar, seguem dois posts que mudam um pouco essa ideia de prazo, contrato de escopo, desenvolvimento iterativo, releases curtas, etc.

http://www.acarlos.com.br/blog/2008/02/cone-da-incerteza-e-scrum/

http://www.acarlos.com.br/blog/2009/09/desenvolvimento-de-produtos-de-forma-incremental/

Na nossa equipe, por enquanto, temos chegado à conclusão de que o maior valor do planning poker está na discussão das estórias. Após algumas rodadas jogando as cartas para uma determinada estória, muitas vezes encontramos problemas e soluções que não havíamos considerado e consequentemente o planejamento como um todo se torna mais preciso. Se depois de três ou quatro rodadas ainda não chegamos a um consenso total, mas percebemos que a discussão não está mais agregando nada (i.e., estamos apenas discutindo o número), então arredondamos para cima (desde que todos concordem).

Nossa escolha do que vai compor o Sprint Backlog é feita com base em planejamento por compromisso (o que a equipe acha que consegue entregar), em vez de por velocidade (usando os pontos).

Abraços

Entusiasta Java Membro desde: 28/10/2008 15:08:02 Mensagens: 24 Offline

Deixa eu ver se entendi

Então utilizo o planning poker para encontrar as storys points do product backlog
Apos isso tenho que saber quantos pontos minha equipe faz por sprint
ai eu divido o product backlog em sprints apartir da quantidade de pontos que minha equipe consegue fazer por sprints

ai digamos que meu sprint é de 10 dias, e pelas tarefas minha equipe imagina conseguir 40 pontos por sprint
então a media da minha equipe é de 4 pontos/dia ou 0.5 ponto/hora

ai coloco isso no grafico burndown para acompanhar para ver o andamento do projeto dia-a-dia

Nas primeiras vezes poderia utilizar ideal day para ter uma base para story points?
Tipo:
O sprint tem 10 dias com 8 horas de trabalho (considerando que trabalha 100% do dia sem paradas), assim tendo um total de 80 horas por sprint. Minha equipe pelo planning poker estimou 90 pontos para esse primeiro sprint
então os proximos sprints poderia usar como base os 90 pontos desse primeiro sprint
ai caso o prazo excedesse nos proximos sprints, reavaliaria e por ter mais experiencia poderia estimar um novo valor por pontos

e +/- isso pessoal?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Bruno Laturner wrote:Só uma pergunta,

os clientes sempre querem saber o quanto vão desembolsar num projeto antes dele ter começado. O que vocês respondem? Como calculam um valor de entrada/custos iniciais?

Vc pega todas as user stories ( o backlog), vc estima ( com planning poker ou outro método) , ai vc descobre/sabe/estima a velocidade da sua equipa com sprints de tamanho fixo ai vc faz as contas.

backlog = 400 SP
Velocidade = 40 SP
Sprint =10 dias uteis.

Com 400 pontos a 40 SP por sprint vc precisa de 10 sprints. Só para implementar. Coloque mais 2 ou 3 para correções, digamos 12
12 sprints são 120 dias uteis. Coloque isso num calendário real ( não se trabalha sabados, domingos e feriados... considere pontes tb)
isso dá um numero de dias reais. Calcule quanto custa manter a equipa por esse tempo. Isso é o custo.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

mateushim wrote:Deixa eu ver se entendi

Então utilizo o planning poker para encontrar as storys points do product backlog
Apos isso tenho que saber quantos pontos minha equipe faz por sprint
ai eu divido o product backlog em sprints apartir da quantidade de pontos que minha equipe consegue fazer por sprints

ai digamos que meu sprint é de 10 dias, e pelas tarefas minha equipe imagina conseguir 40 pontos por sprint
então a media da minha equipe é de 4 pontos/dia ou 0.5 ponto/hora

Epa , epá, calma, calma... vc até ia bem até misturar tarefas e pontos por hora.

Pontos por hora não existe! Existe pontos por sprint. O que vc sabe é que 40 pontos serão feitos no sprint. Apena isso. Não invente divisões sem significado.

As estorias são cotadas em SP. Elas são divididas em tarefas depois. Tarefas são unidades de implementação. Ou seja, uma tarefa é algo que uma pessoa pode fazer. Uma estoria é um conjunto de tarefas. As tarefas são estimadas em horas ideias como de costume. Isso , dependendo da sua definição de 1 SP pode ser feito durante ou após o planning poker para validar os tamanos relativos, mas NUNCA vc usará essa informação para programar os sprints.

A velocidade não é uma média. Médias não são usadas em scrum.

Nas primeiras vezes poderia utilizar ideal day para ter uma base para story points?

Para cada projeto vc precisa definir o quanto vale 1 SP. Mas essa definição não pode mudar até o fim do projeto.
Sim, para o seu primeiro projeto usar 1SP = 1Dia ideal é mais fácil.

Tipo:
O sprint tem 10 dias com 8 horas de trabalho (considerando que trabalha 100% do dia sem paradas), assim tendo um total de 80 horas por sprint.

É irrelevante o numero de horas. Essa coisa de hora não é necessário. O facto de um dia ideal ter 8 horas ideias apenas serve para estimar se vc errou quando estimou os SP.

10 dias são 10 dias. Não são 80 horas.

Leia Scrumalicous para mais detalhes de como planejar o sprint e os logs.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

sergiotaborda wrote:

Bruno Laturner wrote:Só uma pergunta,

os clientes sempre querem saber o quanto vão desembolsar num projeto antes dele ter começado. O que vocês respondem? Como calculam um valor de entrada/custos iniciais?

Vc pega todas as user stories ( o backlog), vc estima ( com planning poker ou outro método) , ai vc descobre/sabe/estima a velocidade da sua equipa com sprints de tamanho fixo ai vc faz as contas.

backlog = 400 SP
Velocidade = 40 SP
Sprint =10 dias uteis.

Com 400 pontos a 40 SP por sprint vc precisa de 10 sprints. Só para implementar. Coloque mais 2 ou 3 para correções, digamos 12
12 sprints são 120 dias uteis. Coloque isso num calendário real ( não se trabalha sabados, domingos e feriados... considere pontes tb)
isso dá um numero de dias reais. Calcule quanto custa manter a equipa por esse tempo. Isso é o custo.

A quem vcs querem enganar? Ao cliente? Ou a si mesmos?

É óbvio que vc precisa estimar o tempo total de projeto, mas deixe claro para seu cliente que esta estimativa é grosseira.

Faça contrato de escopo de escopo variável. Em um projeto de 1 ano (será que dura 1 ano??), faça entregas parciais e cobre conforme essas entregas.

Mostre software funcionando rápida e ciclicamente e conquiste a confiança do patrocinador.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

andre_salvati wrote:

sergiotaborda wrote:

Bruno Laturner wrote:Só uma pergunta,

os clientes sempre querem saber o quanto vão desembolsar num projeto antes dele ter começado. O que vocês respondem? Como calculam um valor de entrada/custos iniciais?

Vc pega todas as user stories ( o backlog), vc estima ( com planning poker ou outro método) , ai vc descobre/sabe/estima a velocidade da sua equipa com sprints de tamanho fixo ai vc faz as contas.

backlog = 400 SP
Velocidade = 40 SP
Sprint =10 dias uteis.

Com 400 pontos a 40 SP por sprint vc precisa de 10 sprints. Só para implementar. Coloque mais 2 ou 3 para correções, digamos 12
12 sprints são 120 dias uteis. Coloque isso num calendário real ( não se trabalha sabados, domingos e feriados... considere pontes tb)
isso dá um numero de dias reais. Calcule quanto custa manter a equipa por esse tempo. Isso é o custo.

A quem vcs querem enganar? Ao cliente? Ou a si mesmos?

É óbvio que vc precisa estimar o tempo total de projeto, mas deixe claro para seu cliente que esta estimativa é grosseira.

Faça contrato de escopo de escopo variável. Em um projeto de 1 ano (será que dura 1 ano??), faça entregas parciais e cobre conforme essas entregas.

Mostre software funcionando rápida e ciclicamente e conquiste a confiança do patrocinador.

Quem se está enganando ? Que confunde escopo com esforço.

A estimativa se SP é de esforço. Não existem estimativas de escopo. Existe levantamento de escopo ( o backlog).
OS requisistos inicias do projeto não serão os finais, mas o esforço será sempre o mesmo. Básicamente vc acorda com o cliente que esté à disposição para fazer o software de tamanho Z fixo. Quais requisitos quer ver incorporados primeiro ? é a pergunta que vc faz ao cliente. Ele pode mudar de opinião. Ele pode mudar o escopo (requisitos) quando quiser. O que ele não pode mudar é a alocação da equipa, os limites do custo e o trabalho necessário.

Contrato de escopo+tamanho variável é um cancer. É a justificativa de quem não sabe estimar. Nunca funciona. Contratos desses acabam gerando horas extra porque o prazo não muda... o esforço aumenta.

Se quer discutir contratos , isso é outra conversa. O assunto aqui é estimar usando scrum e planning poker. Existem ferramentas no scrum para planejar lançamentos (releases) e controlar projetos usando contratos de esforço fixo e escopo variável.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

sergiotaborda wrote:

Contrato de escopo+tamanho variável é um cancer. É a justificativa de quem não sabe estimar. Nunca funciona. Contratos desses acabam gerando horas extra porque o prazo não muda... o esforço aumenta.

Sérgio,

vc já trabalhou em um projeto de software? DE VERDADE?

Escopos de projeto de software SEMPRE mudam. Aceite isso. Não brigue com seu cliente se ele quiser modificar algum requisito (ou o que vc chama de escopo). Isso é melhor para a sua saúde e para a dele. Se o escopo muda, o esforço muda.

Tudo muda, entende?!?! Se TUDO muda, vc deve estar constantemente replanejando o escopo, o esforço, as batatinhas, as bananas e seja lá mais o que vc acredite que precise para um projeto acontecer.

O raciocínio é MUITO simples.

Agora, se vc prefere continuar pregando seu pseudo-SCRUM (ou Waterfall disfarçado de SCRUM

), continue assim...

Abraço.

Notícias, artigos e o maior fórum brasileiro sobre Java