Estimar prazo com Planning Poker em Scrum

É 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

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??

mateushim:

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! :lol:

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!

Abraço,

Claudio

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:

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??

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

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?

Bruno Laturner:

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.

mateushim:

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.

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.

É 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.

sergiotaborda:

Bruno Laturner:

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.

andre_salvati:

sergiotaborda:

Bruno Laturner:

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.

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 :shock: ), continue assim…

Abraço.

O cliente pode mudar o scopo de uma story, desde que ela ainda esteja no backlog. mas essa mudança faz com que a story precise ser reestimada. e recobrada, e reorganizada, e o cliente precisa saber disso.

Supondo que a story ficou mais complexa, isso vai demandar mais tempo (não necessariamente, mas implicitamente). e o cliente TEM que ser cobrado disso. não da pra enfiar 44 sp num splint de 40. Ai, a questão contratual é que tem que ser verificada. pq vc tem um escopo/valor definido. se o cliente quer mudar, blz, desde que ele perceba os impactos dessa mudança e decida o que fazer.

andre_salvati:

sergiotaborda:

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?

Não torne as coisas pessoais. E digo mais, não as tente tornar pessoais antes de ter entendido o que estou dizendo.
Porque vc não entendeu nada do que eu disse.

Onde eu disse que não aceitava isso ?
Essa é a primeira coisa que eu aceito : software evolui.
Escopos de projeto evoluiem por causa disso. É natural.

Nem tudo muda. O dia continua tendo 24h e as semanas 7 dias. A segunda-feira vem depois do domingo e a sexta antes do sabado.
Entenda o problema dos gerentes de meia tigela de hoje em dia : eles acham que projeto de desenvolvimento de software e o software são a mesma coisa. Não são.

O escopo do projeto muda, o esforço não muda. O cliente pagou um preço pelo seu esforço. O seu esforço permite fazer um numero limitado de coisas O objetivo desta associação comercial é vc cumprir , com o esforço contratado, o máximo de desejos do cliente.

Isto é simples, óbvio e cistalinamente nitido para quem entende o que é scrum e agilidade me geral.

Veja bem. O cliente contratou 120 dias de desenvolviemento porque a equipa estará 120 dias disponivel para ele. A equipa estará 120 dias disponivel porque ela tem a certeza que esse é o tempo necessário para aplicar o esforço necessário para alcançar o objetivo que o cliente pediu quando assinou o contrato. O projeto está fechado. Ninguem paga mais um centavo, ninguem trabalha extra. Capice?

O fato de gerentes imcomptentes fazerem as suas equipas trabalharem mais porque “abriram as pernas para o cliente” ( é uma expressão chula e que eu não gosto de usar, mas é a expressão comum usada pelos desenvolveodres) atesta apenas que eles não tem coragem de dizer que não.

Para fazer scrum é preciso coragem para dizer que não. É por isso que é tão dificil implantar scrum.

O projeto , não o software, tem esforço fixo. É como um jarro de água. O cliente encheu no principio e agora vai ser usado. Ninguem vai encher esse jarro de novo. O cliente aloca a água como quiser enquanto ela existir no jarro, mas depois de consumida, já era. Não ha volta atrás. Qualquer alteração consome mais água. A água não é mágica.

O cliente pode escolher gastar toda a água numa funcionalidade imbecil. Ou gastá-la num sistema simples,mas util. Ele pode mudar de opinião. Ele irá mudar de opinião, mas o recurso é finito. Quando se acabar, ele tem que comprar mais. Tão simples assim.

A prioritazção do baclog é onde acontece esta escolha. O cliente é livre de aumentar o backlog o quanto quiser. Não ha limite para o numero ou tamanho das estorias. É isso que significa “escopo aberto”: requisitos novos são aceites a qualquer momento.
Mas o esforço é fixo. Dai a importância e necessidade de priorização.

Simples demais. Tão simples que não funciona. Ninguem é omniciente para poder prever e planejar tudo com antecedência. Isso é uma falácia. Mesmo em engenharia e ciencia isso não é real. Muito menos em desenvolvimento de software.

Boa tentativa. Mas eu estou dizendo o mesmo que vc. A unica diferença é que eu disse que o esforço do projeto é fixo, que é uma caracteristica do scrum. Como vc faz, ou vê fazer, não é scrum. Portanto, não ha nenhuma contradição.

É uma pena que as pessoas duvidem que scrum ( não se escreve SCRUM, não é uma sigla) as pode ajudar a ter projeto de escopo aberto e custo fixo. Afinal esse é o objetivo do mundo de desenvolvimento ha anos… e agora que está ai, ninguem quer aceitar que é possivel… que ironia.

Não é pessoal. É técnico e empírico. Vc precisa experimentar para perceber…

Os dias da semana são uma convenção, por isso não mudam (poderiam ser 8 ou 10). Por outro lado, alguns são de sol, outros de chuva, outros nublados: portanto, mudam. Isso é baboseira filosófica e não importa.

O que importa eu vou repetir: se vc trabalha com escopo fechado, vc não é ágil.

Errado. Se o escopo muda, o esforço muda. É aí que vc peca.

Vc é português?

Ou vc não entendeu porque eu não expliquei direito , u vc não entendeu porque é limitado, ou vc entendeu e quer ficar enchendo o saco.

Vou dizer só mais uma vez:

O esforço alocado ao projeto não muda.
O escopo do projeto muda.
O escopo do projeto mudar, não mudar o esforço alocado ao projeto. Apenas muda o esforço necessário para completar todos os requisitos que o cliente inventou. Mas o projeto não serve para completar todos os requisitos que o cliente inventar. O projeto serve para completar aqueles que cabem no esforço contratado.

O escopo é sempre alterável, o backlog é alterável, mas isso não significa que a equipa vai fazer tudo o que está lá. É por isso que é preciso priorização do backlog. Se fossemos fazer tudo, não importava a ordem.

O erro das metodologia tradicionais é exatamente esse : não priorizar as coisas com o cliente e fazê-lo ver que se gastar recursos enfeitando a tela com cores não vai haver recursos para implementar a lógica importante para o negocio (controle de estoque, por exemplo). Scrum impõe limites. É preciso fazer trade-offs constantes entre as features que faltam implementar. è por isso que se fazer reuniões de fim de sprint e de inicio de sprint. Exatamente para que o cliente saiba das coisas, tenha toda a informação e com isso possa decidir a prioridade. Um dos valores do scrum é Foco. E isso é conseguido através de ir fazendo pacotes de features durante os sprints. A cada pacote o cliente experimenta o que já foi feito e isso lhe mostra mais claramente o fim da linha. Nesse ponto ele pode mudar de opinião e alterar alguma coisa, mas tudo isso sairá do orçamento que ele contratou.

Se no fim do projeto , no fim dos recursos alocados, o backlog ainda contém muitas features interessantes, outro pacote de recursos pode ser contratado e continua. A melhor forma de contratar agil é primeiro assinar um contrato guarda-chuva de compromisso ou seja, o cliente se compromete a contratar a empresa X para desenvolver o software Y. Depois sub-contratos são assinados conforme necessário. Estes sub-contratos são tratados como lançamentos e projetos para um deles são feitos. Cada projeto destes partilha o mesmo backlog que está protegido pelo contrato guarda-chuva. É muito simples.

Bom, se entendeu ótimo. Se não entendeu outro alguém que explique.
(alguma das outras pessoas pode explicar o que não é claro ? )

Faz de conta que eu não entendi sua viagem, vc escreve demais e ainda chama pessoas de “recursos”

Vamos ouvir o que os outros têm a dizer…

andre_salvati:

sergiotaborda:

Ou vc não entendeu porque eu não expliquei direito , u vc não entendeu porque é limitado, ou vc entendeu e quer ficar enchendo o saco.

…

Bom, se entendeu ótimo. Se não entendeu outro alguém que explique.

Faz de conta que eu não entendi sua viagem, vc escreve demais e ainda chama pessoas de “recursos”

Isso foi vc que , descaradamente , inventou. Vc deveria ter vergonha de dizer essas coisas.
Olhe só o que eu disse:

Até onde eu sei, pessoas não se consomem ou gastam. A não ser que vc seja canibal…
A sua argumentação é pifia. Se foi realmente isso que entendeu, sugiro que faça um curso de português urgentemente.

Bruno Laturner:

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?

Se software evolui toda estimativa vai ocasionalmente estar errada portanto o melhor é não se basear nessa informação. Se precisa fechar contrato deve ter uma boa equipe de marketing/vendas.

Falando sério, não deve ser diferente da técnica usada pelo cliente e outras tantas empresas pra saber quanto custa entregar um valor num determinado prazo. O propósito de técnicas como planning poker é amelhoria do proprio processo não atender expectativas externas a ele.

Ora pois,

mudaste de opinião de novo?

Acabou Sérgio. Continue com seus projetos de escopo fechado que eu continuo com os meus de escopo aberto.

Mais uma vez, um abraço.

mochuara:

Bruno Laturner:

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?

Se software evolui toda estimativa vai ocasionalmente estar errada portanto o melhor é não se basear nessa informação. Se precisa fechar contrato deve ter uma boa equipe de marketing/vendas.

Falando sério, não deve ser diferente da técnica usada pelo cliente e outras tantas empresas pra saber quanto custa entregar um valor num determinado prazo. O propósito de técnicas como planning poker é amelhoria do proprio processo não atender expectativas externas a ele.

Se o contrato depende do custo e o custo depende do tamanho do projeto, e o tamanho do projeto é a soma do tamanho das estorias e este é estimado usando planning poker, como é que possivel vc entender que o contrato não depende do planning poker ?

O planning poker tem como objetivo estimar o tamanho das estorias, mas para fazer isto é preciso muito dialogo. Nestas reuniões é comum destrinchar as coisas em mais detalhes com o PO. Portanto é vantagem para todos. Além disso coloca toda a equipe na mesma página para que não haja segredos nenhuns… Abertura e Foco, são os principais valores nestes momento do projeto

Como vc estima/estimaria o valor do contrato de um projeto scrum ?

Para quem se interessa um artigo pequeno, mas elucidativo sobre o assunto
http://www.opensourceconnections.com/2007/05/03/turning-waterfall-contracts-into-scrum-contracts/

sergiotaborda:

mochuara:

Bruno Laturner:

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?

Se software evolui toda estimativa vai ocasionalmente estar errada portanto o melhor é não se basear nessa informação. Se precisa fechar contrato deve ter uma boa equipe de marketing/vendas.

Falando sério, não deve ser diferente da técnica usada pelo cliente e outras tantas empresas pra saber quanto custa entregar um valor num determinado prazo. O propósito de técnicas como planning poker é amelhoria do proprio processo não atender expectativas externas a ele.

Se o contrato depende do custo e o custo depende do tamanho do projeto, e o tamanho do projeto é a soma do tamanho das estorias e este é estimado usando planning poker, como é que possivel vc entender que o contrato não depende do planning poker ?

O planning poker tem como objetivo estimar o tamanho das estorias, mas para fazer isto é preciso muito dialogo. Nestas reuniões é comum destrinchar as coisas em mais detalhes com o PO. Portanto é vantagem para todos. Além disso coloca toda a equipe na mesma página para que não haja segredos nenhuns… Abertura e Foco, são os principais valores nestes momento do projeto

Como vc estima/estimaria o valor do contrato de um projeto scrum ?

Concordo que comunicação com cliente é importante mas vc pode estar confundindo os clientes neste caso, quem participa do processo de desenvolvimento como PO não é o mesmo cliente que fecha o contrato, ou pelo menos existe uma diferenca de tempo entre a negociacao inicial e o momento e contexto onde planning poker podem ser uteis para estimar alguma coisa. Se o objetivo é conquistar o cliente minha sugestão sobre arrumar uma boa equipe de vendas pra reforçar um contrato de escopo variavel continua valendo. Nesse momento o foco passa a ser estimar o valor de uma entrega, que é mais facil.

Me desculpe amigo, o escopo pode até mudar, mas o esforço ou horas contratadas não devem ser alteradas, a não que se aumente o custo e preço do produto.

pra mim isto é a maior furada… onde trampava tentaram colocar algo do tipo só que não adiantou pra nada a não ser consumir tempo da equipe…

Se o escopo é variável, tempo e custo podem ser fixos, o próprio cliente vai saber oq é mais importante ele ter pronto ao final do tempo contratado e cada vez que ele quiser mudar algo ele pode, mas sabe que cada mudança terá seus implicações.

Entao, se la onde voce “trampava” nao funcionou significa que é uma furada? Todos os casos de sucesso, bem como a literatura toda podem ser jogados fora por isso?

Pessoal, desculpem ressucitar o tópico. Tem ALGO que NÃO intendi!!!

Eu intendi que a Estimativa do Scrum serve para MEDIR Esforço Relacional entre as Prints. Ou seja uma sprint que tem 20 pontos deverá demorar o dobro da que possue 10 pontos.

Porém, possuo duas dúvidas.
1- As cartas do Planning Poker não deveriam seguir a sequência de Fibonacci? (1, 1, 2, 3, 5, 8, 13, 21, 34, 55 )
Pelo que ví, as cartas do Planning Poker NÃO seguem a sequência…(0, 1, 2, 3, 5, 8, 13, 21, 40)

2- Já que apenas conseguimos medir o tamanho de esforço de uma tarefa…O que cada número na primeira Sprint representa?
Ex: A sprint possue 10 pontos. Como sei que dez pontos é um Sistema completo ou um select na base?
Qual o valor de cada Ponto? 1 dia, uma hora, dez linhas de código?

InsaneChess:

Pessoal, desculpem ressucitar o tópico. Tem ALGO que NÃO intendi!!!

Eu intendi que a Estimativa do Scrum serve para MEDIR Esforço Relacional entre as Prints. Ou seja uma sprint que tem 20 pontos deverá demorar o dobro da que possue 10 pontos.

Não. Vc não entendeu. Um sprint sempre demora o mesmo tempo. É essa a definição de sprint. Em scrum o sprint é um timebox, uma caixa de tempo. Ou seja, vc tem um tempo T pré-determinado para completar as historias.
Os pontos que estão contidos no sprint podem ser quaisquer. Se a equipe fez 20 pontos em um sprint e 40 no outro, ótimo. Isso significa que ela está evoluindo. Esse numero de pontos por sprint chama-se Velocidade.

A sequencia de Fibonacci não é a única opção (potencias de 2 é outra), mas é a mais usada por várias razões. Mas ela é usada apenas entre 1 e 10. Isto tem uma relação com a capacidade do ser humano raciocinar com numeros. Numeros até dez vc entene bem, mas numeros maiores é meio que a mesma coisa. Além disso quanto maior o numero, maior o erro, e portanto usar 34 em vez de 40 seria uma falácia. Vc estaria tentando colocar precisão onde ela não existe. A escala do planning poker é inspirada na sequencia de fibonacci porque a sequencia de fibonacci otimiza o processo.
A escala do planning poker é 0 , 0.5 , 1, 2, 3, 5, 8 , 13, 20 , 40, 60, 80, 100 e infinito

Vc escolha o valor de um ponto antes de começar a usar o Scrum. O que importa é que signifique sempre o mesmo. Se 1SP = 1dia ideal, que seja sempre assim até o final. Mas tecnicamente o correto é usar uma escala relativa. Para isso vc pode escolher uma feature do sistema de médio porte e escolher ela como sendo 5 SP. O resto das historias será menor ou maior que 5 conforme o tamanho é maior ou menor que o dessa feature que vc escolheu.

Não ha necessidade de trabalhar com tarefas em agil. Apenas historias. historias são conjuntos de várias tarefas. É possivel , e existem tecnicas, para usar também a quebra em tarefas, e pode ser util quando a equipe está migrando do tradicional para o ágil, mas o tempo que as tarefas demoram apenas ajuda a refinar a estimativas das historias seguintes , em nada afeta a estimativa e o planejamento que já foi feito. Ou seja, não ha necessidade de quebrar em tarefas para estimar o tamanho do backlog.

Não funciona porque as responsabilidades não são entendidas, não funciona porque o programador entende um mundo e o analista de processo entende outro mundo, quando um projeto é financiado espera-se afirmação do contrato e o resto o marketing toma conta, ai vem fabrica de software , fabrica de garagem e por ai , scrum e bla, bla , bla … O que pode se fazer é colaboração e ai tratar tudo como um modelo de negocio, transferindo a responsabilidades para as especificação e a execução de tarefas, entendendo como um XP, programação pareada iniciantes e experientes, a transferência de resultados para o cliente.
Desenvolvimento de software nunca vai ser um pensamento científico, mesmo porque a tecnologia é um consorcio de muitos fornecedores de solução, na verdade é uma negociação sempre pra colocar em plano uma tecnologia que vai ser adquirida ou comprada pela empresa.