[quote=andre_salvati][quote=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.
[/quote]
Faz de conta que eu não entendi sua viagem, vc escreve demais e ainda chama pessoas de “recursos”
[/quote]
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.
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?[/quote]
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.
[quote=mochuara][quote=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?[/quote]
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.[/quote]
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 ?
[quote=sergiotaborda][quote=mochuara][quote=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?[/quote]
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.[/quote]
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 ?[/quote]
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.
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?
[quote=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.
[/quote]
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.
