Demorei a saber deste post… Mas eu sou bem favorável ao uso de story points, apesar de achar que é possível sim funcinoar bem com “dias-ideais”. Segue um texto que escrevi sobre o assunto:
http://visaoagil.wordpress.com/2008/12/08/por-que-usar-story-points/

Li o post – vou fazer uns comentários lá. Bem interessante, mas não guarda relação direta com o meu. Você faz um comparativo entre estimar em pontos e estimar em prazo – e não em dias-ideais. Meu comparativo não é esse. Num dos comentários, o Calçado é sagaz ao perceber que de fato a gente aqui trabalha com pontos. E eu mesmo confirmei – inclusive chamamos de ponto. A confusão que o mercado normalmente faz é essa mesmo que você cita no seu post, entre pontos e prazo. Mas no mundo ágil esse assunto é superado, a meu ver. A discussão é entre “pontos de comparação-de-histórias” e “pontos de dias-ideais”.

Quanto a PF, acho que ficou confuso misturar com o outro assunto. Eu acho que PF é um exercício de fé, e nesse caso sou bem cético. Bom, vale lembrar que PF é uma medida tipicamente brasileira (pouco usado lá fora de maneira tão generalizada como aqui, exceto em alguns poucos países como a Coréia).

Me arrependo de ter citados PFs no texto. Quis enriquecer minha argumentação, mas mais confundiu que ajudou.

amos conversar no Scrum Gathering…

Ainda não sei se vou. Mas se for, certamente conversamos.

Demorei a saber deste post… Mas eu sou bem favorável ao uso de story points, apesar de achar que é possível sim funcinoar bem com “dias-ideais”. Segue um texto que escrevi sobre o assunto:
http://visaoagil.wordpress.com/2008/12/08/por-que-usar-story-points/

Quanto a PF, acho que ficou confuso misturar com o outro assunto. Eu acho que PF é um exercício de fé, e nesse caso sou bem cético. Bom, vale lembrar que PF é uma medida tipicamente brasileira (pouco usado lá fora de maneira tão generalizada como aqui, exceto em alguns poucos países como a Coréia).

Vamos conversar no Scrum Gathering…

06/04/2009 às 8:21 PM
Oi, Alisson.
Você está dizendo que acha desnecessário discutir qual o melhor modelo, de dias-ideais ou de pontos, já que a maior relevância está nas técnicas estatísticas, é isso? Sei não. Eu me interesso até pela discussão se post-its são melhores que cartões com tachinhas.”

Clavius peço-lhe licença para adicionar a seu comentário.

Idéias, conversas, fatos e até mesmo simples ‘post-its’ podem gerar novas e grandes idéias, podem trazer novos entendimentos, abrir novas linhas de pensamentos, confirmar entendimentos ou desentedimentos, etc.

Legal sua idéia! Muito bom!!

Só não concordo com: “…de fato, acho que nunca vamos conseguir…”. Mas como você deixou o “ACHO” ficou blz!!

Vou ler depois o restantes dos posts!

Com certeza, não. Estou apenas dando ao seu leitor a oportunidade de pensar sobre a questão em um outro ângulo, totalmente ortogonal à linha de discussão, mas ainda assim muito relevante para quem gostaria de extrapolar o problema no sentido de encontrar sua causa-raiz. Se você se questiona sobre o “Porquê” estimar software, talvez o “como” seja totalmente transformado.

Clavius,

Sim, este é o ponto. Você sempre terá um prazo, isso é fato, mas não pode estimar com precisão quanto tempo vai levar para se executar um trabalho criativo (software, livro, música ou outra coisa parecida). O que você faz é ir trabalhando com tempo e escopo para chegar a um resultado aceitável em uma determinada data. O caso do livro é interessante… Você é capaz de estimar quanto tempo vai gastar para escrever um capítulo? Acredito que não… mesmo fazendo iterações e medindo quanto tempo levou cada um dos capítulos anteriores, você nunca poderá prever o tempo necessário para escrever um novo. A melhor conclusão que você pode chegar é que este será mais rápido do que aquele. E isso não é suficiente para se obter uma resposta razoável.

O máximo que você pode conseguir é estabelecer tendências baseado no “Yesterday Weather”. Mas isso é uma questão de estatística, não de qual a melhor técnica para “estimar” ou “advinhar” a duração de um trabalho.

O que aumenta a previsibilidade dos projetos são as técnicas que ajudam a encontrar tendências (estatística), não as técnicas que supostamente melhorariam nossa capacidade de descobrir quanto tempo vai levar para se construir uma determinada feature. É a capacidade de estabelecer tendências que faz projetos ágeis serem “Previsíveis”, não as técnicas de estimativa em si.

Foi isso que eu quis dizer no meu comentário original.

Abraços,
Alisson Vale

Eu pediria para ver um estudo destes.

Pois, é. Também gostaria. Infelizmente me baseio mesmo só no relato verbal de algumas empresas e consultores.

Já tive algo mito parecido. Em um determinado time nós adotamos um nome ridículo, como ‘Turings per second’ e quando o cliente perguntou o que aquilo significava nós dissemos que era uma uniade de engenharia de software e demos uma definição criada no erador de lero lero. Resultado? O cliente não entendia o que era um ‘TpS’ mas em algum tempo esta ‘medida’ passou a fazer parte do vocabulário dele.

Hehehe. Fui justamente por isso que decidimos começar a chamar horas-ideais de pontos.

Já concordamos que se funciona e se a equipe se sente confortável, beleza. Mas só uma curiosidade: o que você chama de complexidade? Complexidade algorítmica e tecnológica? Você chegou a ver meu comentário-resposta ao Tino?

Eu vi sua resposta sim e entendo seu onto sobr trabalhoso x complexo, mas na minha experiência algo trabalhoso e simples (e.g. substituir todas as tags por em uma aplicação muito grande) geralmente pode ser automatizada.

Talvez ‘complexidade’ não seja o termo certo, talvez ‘dificuldade’ seja o melhor porque na vedade é assim que penso: émais fácil ou mais difícil fazer X que Y?

indo nessa sua afirmação coisas como PFs e Pontos-de-Casos-de-Uso (PCUs)?

Sei não. Já ouvi diversos relatos (algumas empresas e vários consultores CMMI-MPS.BR-etc.) de sucesso no uso dessas técnicas. Sucesso no sentido de calcular tamanho para derivar esforço e tempo de desenvolvimento. Obs.: conheço um caso sintomático, homérico, ridículo de falha usando PCUs. Mas esse (pseudo?) sucesso não quer dizer que não exista algo melhor. Tenho certeza de que se a taxa de sucesso de coisas como PFs e PCUs é de 70%, a de coisas como dias-ideias e pontos seria de 90%, por exemplo. É preciso ficar claro que meu post se refere à comparação entre dias-ideais e pontos. Se for para comparar pontos com PFs ou PCUs, esses, PFs e PCUs, não dão nem pra começar.

Eu pediria para ver um estudo destes. Também já vi diversos ‘casos de sucesso’, inclusive já trabalhei para empresas onde APF era a lei e UCP estavam sendo introduzidos. Exatamente por ter trabalhado em uma delas que tudo que já vi, na minha empresa ou em concorrentes, era apenas brincadeira com números para chegar a um objetivo pré-determinado. Lies, damn lies and…

Numa de nossas equipes, justamente a da velocidade de 110 que citei acima, tivemos um problema com esse negócio de horas-ideais. Por uma questão de economia, nos nossos diálogos falávamos apenas “horas”, apesar de pensarmos em horas-ideais. Resultado: o cliente passou a questionar por que não entregávamos as tais 240 horas por iteração. Foram necessárias várias semanas, repetindo a explicação, para que o cliente entendesse que horas-ideais não são a mesma coisa que horas “reais”.

Já tive algo mito parecido. Em um determinado time nós adotamos um nome ridículo, como ‘Turings per second’ e quando o cliente perguntou o que aquilo significava nós dissemos que era uma uniade de engenharia de software e demos uma definição criada no erador de lero lero. Resultado? O cliente não entendia o que era um ‘TpS’ mas em algum tempo esta ‘medida’ passou a fazer parte do vocabulário dele.

Talvez nem valha a pena continuar a discussão desse ponto específico, já que concordamos que PFs é uma porcaria.

Concordo que não valha a pena mas seu link onfirma o que eu disse

Parabéns pelo blog e pelo post inicial.

Valeu.

Outro ponto é que ninguém quer saber o tamanho do sistema. Nós queremos saber é quanto tempo (esforço) leva, pois isso tem uma correlação linear e direta com outra coisa, essa a que realmente importa: Quanto $$$ vai custar esse projeto.

Costumo dizer que o importante é conseguir estimar um timeframe e um orçamento que sejam aceitáveis tanto para o cliente quanto para o time de desenvolvimento num primeiro momento. E, depois, usar as iterações time-boxed, as mudanças nas histórias e a estatística para conseguir fazer convergir o cone com a estimativa. E a melhor estimativa, creio, ainda é o bom e velho chute científico, “calibrado” pelos pitacos dos pares de quem está estimando.

Perfeito. É exatamente o que fazemos aqui. Quando começamos um projeto, realizamos o que chamamos de workshop de planejamento do projeto. A primeira atividade é levantar todas as histórias do projeto. Depois a equipe estima cada história em dias-ideais. Somamos todas as histórias e temos o tamanho total do projeto em dias-ideais. De posse da velocidade histórica calculamos o tempo total do projeto, a partir do qual, como você mesmo disse, achamos o custo total.

Números de nossos últimos três projetos:

1) Estimado em quatro meses e meio; entregue com três semanas de antecedência;
2) Estimado em três meses; entregue com duas semanas de antecedência;
3) Estimado em três meses; entregue com uma semana de antecedência.

O tamanho das equipes de cada projeto era de 10 a 15 pessoas. E esses workshops levavam de um a três dias.