por que não estimar por pontos

Advertência: prefiro trabalhar com horas, turnos ou dias ideais (daqui pra frente, só chamarei de “dias-ideais”). Muitas pessoas se referem a dias-ideais como pontos. De fato, até aqui na Fortes chamamos os dias-ideais de pontos. Mas os pontos a que me refiro no título do post se referem àqueles em que as equipes atribuem um ponto para a história mais simples e estimam as demais histórias em relação a essa mais simples. É dessa abordagem que não gosto. Daqui pra frente neste post, quando falar em pontos, é dessa abordagem que estou falando, e não da de dias-ideais.

Não acho nada natural estimar uma história em relação a outra. Imaginemos que num sistema de controle de issues a história mais simples seja “registrar issue”. Imaginemos ainda que haja a história “tela de acompanhamento de issues”. Simplesmente não consigo – pode ser uma limitação minha – fazer qualquer relação direta de tamanho entre essas duas histórias. A única forma que conseguiria de fazer essa relação seria estimar ambas em dias-ideais e ver quantas vezes uma é maior que a outra.

Quando o Alexandre Magno esteve aqui na Fortes ministrando um treinamento, ele fez uma dinâmica para tentar explicar por que seria interessante trabalhar com pontos. Ele nos trouxe uma série de “livros”, de bem simples como um de histórias em quadrinhos, a bem complexos como um do Dostoiévski. Pediu para escolhermos o mais simples e para estimarmos a complexidade dos demais em relação a ele. Adivinha o que aconteceu na minha cabecinha? Para cada livro estimei quanto tempo levaria para lê-lo e fiz a relação entre eles a partir dessa estimativa. Foi a forma mais simples e natural que achei de fazer o que havia sido pedido.

Desde que o mundo é mundo, estimar atividades em tempo é a regra, é a forma mais natural.

Uma crítica comum que se faz ao modelo de dias-ideais é a seguinte: “Esforço não é mesma coisa que tamanho. Dias-ideais se referem a esforço, mas o que queremos saber é qual o tamanho das histórias.” Concordo que esforço não é igual a tamanho. Mas discordo quando dizem que dias-ideais se referem diretamente a esforço. Se eu estimar uma história em cinco dias-ideais, pode ser que a faça em dez. Quede a relação entre dias-ideais e esforço? Perguntariam: como faço então para resolver esse problema de erro de estimativa? Resposta: além do próprio aprendizado empírico, aplicando o conceito de “velocidade”.

Dias-ideais também não se referem diretamente a tamanho, pelo menos não em seu conceito canônico. Em tese, o tamanho deve ser o mesmo para o mesmo projeto independente da equipe que o meça. E isso realmente não dá para conseguir com dias-ideais. Duas equipes podem chegar – e normalmente chegam – a tamanhos diferentes quando medem um mesmo projeto em dias-ideais. Esse problema é em tese resolvido com o modelo de pontos. Mas ainda assim esse modelo não consegue resolver outro conceito – o mais importante – por trás do tamanho: a existência de uma unidade de medida universal para tamanho de projetos.

Iniciando um aparte.

Atualmente considero a técnica de Pontos-de-Função (PFs) o melhor – de fato, menos pior – modelo de tamanho, a melhor unidade de medida universal. Como disse, é o menos pior. A técnica de PFs apresenta ainda uma série de problemas: há alguma subjetividade, a faixa de tamanhos das funções em P, M e G é muito simplista, não pode ser aplicado a todo tipo de projeto de software e alguns dos fatores de ajuste deveriam ser aplicados por função. Ou seja, ainda estamos longe de conseguir uma boa unidade de medida universal para projetos de software (de fato, acho que nunca vamos conseguir; se até hoje nenhuma das chamadas indústrias criativas conseguiu isso, não vai ser a de software que vai conseguir). A questão é: que vantagem teríamos se houvesse essa unidade de medida universal? Várias: poderíamos por exemplo saber se uma equipe está ficando mais produtiva ao longo do tempo; poderíamos também saber se uma equipe é mais produtiva que outra. Essa última vantagem seria especialmente interessante para a contratação de projetos de software por órgão públicos, mas isso é assunto para outro post.

Voltando do aparte.

Um outro problema do modelo de pontos que vejo é o seguinte: não dá para aproveitar a velocidade obtida num projeto para estimar o tempo de desenvolvimento de outro projeto. A história mais simples de um projeto pode não ser do mesmo tamanho que a história mais simples de outro projeto. Responderiam: é só fazer a relação entre as histórias mais simples dos dois projetos, quantas vezes uma é maior que a outra. Tostines: se já acho difícil fazer a relação entre histórias do mesmo projeto, avalie entre histórias de projetos diferentes. Voltamos ao ponto inicial.

 

Atualização
O tema foi bastante aprofundado e estendido nos comentários.

About these ads

21 Comentários on “por que não estimar por pontos”

  1. Tino Gomes diz:

    Olá Tales,
    Compartilho do mesmo sentimento que você. Hoje vivo no mundo SCRUM e passei um bom tempo com este mesmo problema. Apesar de várias literaturas confirmarem que a estimativa por comparação é válida, nunca consegui ver isso funcionando, justamente por esse ponto ser “complexidade”.

  2. Clavius Tales diz:

    Oi, Tino.
    Excelente lembrança essa da complexidade. Nesse modelo de pontos, muita gente fala que a relação entre cada história e a história mais simple deve ser feita em relação à complexidade. Isso é um erro. Imaginemos uma história de baixíssima complexidade mas que é muito trabalhosa e vai levar por exemplo duas semanas para ser desenvolvida. Imaginemos agora uma história de algoritmo supercomplexo mais que vai levar apenas uma semana para ser desenvolvida. Nesse cenário, a história mais complexa teria o dobro do tamanho da história mais trabalhosa. Qual seria a utilidade disso?

  3. Interessante o relato. Eu não acho que nenhum dos dois modelos seja certo ou errado, varia com o time, nível de maturidade, tempo de projeto, etc.

    Mas uma coisa que acho interessante no seu relato é que, pelo que entendi dele, você usa sim pontos. A diferença é que a dimensão que você mede ao aferir o tamanho de uma história é o coneito tangível de dias e não um conceito abstrato de tamanho.

    Se eu estimar uma história em cinco dias-ideais, pode ser que a faça em dez. Quede a relação entre dias-ideais e esforço?

    Este trecho que me fez pensar desta forma. Se você realmente utilizasse tempo isso seria um fator preocupante -bem como é preocupante quando as estimatias utilizando story points erram por uma margem muito grande.

    Num time recente nós chamávamos pontos de ‘donuts’, será que se você trocar ‘dia’ por ‘donut’ no seu dia a dia seria tão diferente deste time? Creio que não. No fundo é a mesma coisa utilizando escalas diferentes.

    Quanto a pontos de função… discordo totalmente :) Não só ela se baseia em aferições de coisas compeltamente irrelevantes (número de arquivos? wtf?) bem como seu objetivo é comparar dois sistemas, o que é sempre danoso quando mal feito.

    No mais parabén pelo blog, já era hora ;)

  4. Fico feliz por vê você usando palavras em inglês nos seus textos :D Ao invés de “pôste” escreveu “post”. Ao invés de “ichu” escreveu “issue”. Fantástico. Espero que tenha abolido aquele negócio de “saite”. hehehehe

  5. Clavius Tales diz:

    Oi, Calçado.

    Eu não acho que nenhum dos dois modelos seja certo ou errado, varia com o time, nível de maturidade, tempo de projeto, etc.

    A enorme quantidade de relatos de uso, de literatura e de discussões a respeito de pontos indica que é um modelo que deve funcionar. Só que minha experiência com minhas equipes me provou que o conceito de dias-ideais se mostrou muito mais fácil de aplicar que o de pontos. Mas facilidade de uso não deve ser o único critério para a escolha de uma técnica. É preciso avaliar o conjunto de vantagens de cada técnica. A questão é: qual vantagem o conceito de pontos tem sobre o de dias-ideais? Nenhuma. Então, por que aplicar a mais complexa?

    Como disse, nas primeiras vezes que tentei aplicar o conceito de pontos, fazia a conversão para dias-ideais para achar a relação entre as histórias. Se eu tivesse exercitado isso continuamente, talvez algum dia introjetasse essa conversão e passaria a ser natural, inconsciente. Talvez seja isso que você queira dizer por “nível de maturidade”. Mais uma questão: para que ter esse trabalho todo de introjeção se no fim das contas não vou obter vantagem nenhuma?

    Mas uma coisa que acho interessante no seu relato é que, pelo que entendi dele, você usa sim pontos. A diferença é que a dimensão que você mede ao aferir o tamanho de uma história é o coneito tangível de dias e não um conceito abstrato de tamanho.

    Exato: tangibilidade. Pra que usar um conceito abstrato – que exige mais esforço, mais preparo – se tenho um tangível que resolve o problema da mesma forma?

    Este trecho que me fez pensar desta forma. Se você realmente utilizasse tempo isso seria um fator preocupante -bem como é preocupante quando as estimatias utilizando story points erram por uma margem muito grande.

    Não sei se entendi o que você quis dizer. Mas vou explorar um pouco mais o que eu disse.

    Para facilitar a explicação, imaginemos um cenário bem simples: a “equipe” sou eu apenas, um único desenvolvedor, e sei que não serei interrompido durante o desenvolvimento. Estou na primeira iteração (de uma semana). Planejo fazer na primeira iteração as histórias A e B. Estimei cada uma em 2,5 dias-ideais. No fim da iteração, vi que só consegui fazer a história A. O que isso quer dizer? Que erro minhas estimativas em 100%, já que a semana tem 5 dias. Planejo então para a próxima iteração as histórias B (que deixei de fazer na iteração anterior) e C. Estimei cada uma em 2,5 dias-ideais (a B já estava estimada). O que devo esperar? Que vou entregar somente a história B, já que costumo errar em 100%, já que costumo entregar numa semana apenas 2,5 dias-ideais (velocidade). De fato, observando o que aconteceu na primeira iteração, nem teria planejado para a segunda as histórias B e C, mas somente a B.

    Obviamente esse cenário que apresentei é simplista e cartesiano. É só mesmo para facilitar a explicação.

    Num time recente nós chamávamos pontos de ‘donuts’, será que se você trocar ‘dia’ por ‘donut’ no seu dia a dia seria tão diferente deste time?

    Falando por mim, seria, pois faria a mesma conversão que se usasse pontos. Quantos donuts tem a história X? O que eu faria: sei que a história mais simples tem 1 donut; sei que a estimaria fazer em dois dias-ideias; sei que a história X estimaria fazer em seis-dias ideais; calculo (regra-de-três) então e vejo que a história X tem 3 donuts. Pergunto novamente: pra que ficar fazendo essa conversão se posso trabalhar diretamente com dias-ideias?

    Quanto a pontos de função… discordo totalmente Não só ela se baseia em aferições de coisas compeltamente irrelevantes (número de arquivos? wtf?) bem como seu objetivo é comparar dois sistemas, o que é sempre danoso quando mal feito.

    Discorda de quê? De que o técnica de PFs é a menos ruim para medir tamanho? Me aponte uma melhor. Que o modelo é ruim, é fato, disse isso no próprio post. Só que não existe outro melhor – ou menos ruim. Só uma coisinha: número de arquivos não é irrelevante, não. Quanto mais arquivos uma história está associada, maior ela é. Obs.: o número de arquivos da técnica de PFs é lógico, não físico.

    No mais parabén pelo blog, já era hora

    Valeu.

  6. Clavius Tales diz:

    Oi, Hilda.
    Você é um pândego. E eu não aguento e vou me dar o trabalho de responder. Regra: aportugueso as palavras de uso corriqueiro. Ex.: “saite” – que você citou -, “emeio” e “blogue”. Exceção: há palavras que não me sinto (ainda?) confortável em aportuguesar. Ex.: “software” e “post“. “Software” pela complexidade fonética e “post” por não saber como aportuguesar. Não poderia ser “pôste”, como você disse, pois o acento diferencial em casos desse tipo caiu com último acordo ortográfico. De fato, nem caiu totalmente. Há ainda alguns casos. Como o tema é controverso, prefiro não arriscar. Poderia ainda ser “pouste” ou “pôsti”. No caso de “pouste”, careço de pesquisa para saber se é um processo adequado de aportuguesamento. No caso de “pôsti”, deve ser errado, pois não lembro de ter visto o i sendo utilizado como vogal epentética para as chamadas consoantes mudas. E quanto a “issue“? Não a utilizo corriqueiramente, logo não a aportugueso. Na verdade, uso “pendência”. Só resolvi utilizar “issue” mesmo no post para que os leitores soubessem exatamente do que estava falando.

  7. Se medidas mais tangíveis funcionam melhor no seu caso então não há porque não usá-las mas o ponto principal em usar medidas abstratas é que quando você usa uma medida ‘prática’ você está se iludindo.

    Como Fred Brooks já disse e tantos e tantos estudos confirmaram nas últimas décadas não existe meio prático de medir esforço de desenvolvimento em tempo.

    O ponto de usar uma medida é se ela facilita para o time estimar. Seu time pode preferir trabalhar com tempo, eu já vi casos de que preferem trabalhar com número de testes ou com linhas de código. E não é porque seu time prefere trabalhar com tempo -e por isso tem que converter- que todos são assim, eu por exemplo prefiro estimar complexidade e para mim tempo é apenas uma derivação desta.

    Todas estas medidas são completamente não científicas, valhe o que a equipe se sente mais confortável em usar.

    Se a coisa for bem feita eu tenho certeza que como você mesmo falou um time que estima tarefa (a) como 2 dias e tarefa (b) como dez dias vai acabar usando a mesma proporção com outra medida, talvez estimando a primeira como 5 pontos e a segunda como 25. No final não importa a medida, por isso que achamos melhor no projeto que estava falando anteriormente utilizarmos um nome engraçadinho que deixasse claro que não existe medida física adequada.

    Sobre pontos de função eu discordo do uso de PF para qualquer coisa. Ela não é “menos pior”, simplesmente é inadequada e tem um efeito nocivo de fazer com que as pessoas pensem que se baseia em alguma espécie de ciência.

    Fazendo uma analogia: Não é porque não temos uma cura para o câncer que beber ácido passa a ser um bom tratamento. Não só ele não melhora seu problema bem como cria muitos outros.


    Sobre o número de arquivos em específico eu também discordo. Se em 2009 você ainda usa uma plataforma onde lidar com arquivos é algo relevante a ponto de aumentar a complexidade do seu sistema isso me é muito estranho.

  8. Clavius,

    Parabéns pelo blog!
    Sobre o post, vou deixar minha opinião.

    Qualquer modelo de estimativa será subjetivo, intuitivo, ineficaz e irrelevante. Se funcionar provavelmente será mais uma coincidência, ou um exercício tendencioso, do que uma evidência de efetividade de determinada técnica. Não considero P, M e G um modelo de estimativa, apenas uma forma de classificação de demandas. Se for utilizado como modelo de estimativa, não será só simplista, será inútil.

    Na minha opinião, a melhor forma de resolver o problema das estimativas é criar as condições para que você não precise estimar. Estimar é exercitar “futurologia”! É a cobra que come o próprio rabo. Ela só se sustenta pela pré-concepção íntriseca das relações comerciais de desconfiança mútua que aprendemos a estabelecer invariavelmente com nossos clientes.

    Aí você me dirá: – Impossível! Eu preciso dar um previsão para os meus clientes!

    Pois é… O conhecimento da humanidade não evolui por meio da melhoria contínua em cima de conceitos enraizados, mas por meio da completa substituição de idéias que até certo momento eram consideradas irrefutáveis. É o que já dizia Thomas Kuhn em sua teoria dos paradigmas.

    Pense nisso…
    Abraços!
    Alisson Vale

  9. Marcio Tierno (MT) diz:

    Parabéns pelo blog e pelo post inicial.

    Após tanto tempo, a conclusão é que ainda não conseguimos um modelo de estimativa confiável quando a granularidade é pequena. É o tal cone de incerteza, que diz que a incerteza em relação ao esforço total é muito grande no início do projeto (necessariamente) e vai diminuindo ao longo do tempo, até atingir a precisão de 100%, o que só ocorre no dia na entrega efetiva do projeto.

    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.

    Quanto os PFs, o Phillipe já falou tudo. A piece of crap!

    Grande abraço e parabéns!!

  10. Clavius Tales diz:

    Oi, Calçado.

    Como Fred Brooks já disse e tantos e tantos estudos confirmaram nas últimas décadas não existe meio prático de medir esforço de desenvolvimento em tempo.

    É no The Mythical Man-Month? Vou ver se dou uma olhadinha. Mas só para ficar claro: não defendo – e condeno – o uso de dias-ideais para fazer a conversão direta para tempo. Vou dar um exemplo: uma de nossas equipes aqui tem seis desenvolvedores. Sua velocidade atual gira em torno de 110 horas-ideais por semana. Achamos isso natural. Se fizéssemos a relação direta com o tempo, esperaríamos uma velocidade de 240 horas-ideais (40 HorasPorSemanaPorDesenvolvedor x 6 Desenvolvedores).

    O ponto de usar uma medida é se ela facilita para o time estimar. Seu time pode preferir trabalhar com tempo, eu já vi casos de que preferem trabalhar com número de testes ou com linhas de código. E não é porque seu time prefere trabalhar com tempo -e por isso tem que converter- que todos são assim

    Concordo plenamente. Só não consigo é imaginar como alguém consegue estimar quantos testes ou quantas linhas de código uma história vai ter. Até mesmo porque uma história pode envolver mais refatoração que criação de algo novo efetivamente. Mas, como você disse, se funciona e se eles se sentem confortáveis, bola pra frente.

    Porém, estamos discutindo generalidades. Se uma equipe-projeto funciona melhor com PFs que com dias-ideais, use PFs. Se uma equipe-projeto funciona melhor com Cascata que com Iterativo, use Cascata. Isso não quer dizer que PFs e Cascata não possam ser criticados. Quando dizemos que PFs e Cascata são ruins, estamos dizendo que 80 (desconsiderar a precisão deste número; é apenas ilustrativo) a 99,99% das equipes-projetos funcionariam melhor de outra forma.

    eu por exemplo prefiro estimar complexidade e para mim tempo é apenas uma derivação desta.

    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?

    Todas estas medidas são completamente não científicas

    Você está incluindo 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.

    Se a coisa for bem feita eu tenho certeza que como você mesmo falou um time que estima tarefa (a) como 2 dias e tarefa (b) como dez dias vai acabar usando a mesma proporção com outra medida, talvez estimando a primeira como 5 pontos e a segunda como 25.

    Concordo. A afirmação é: em geral, seria mais fácil utilizar dias-ideais que pontos. Se o resultado é o mesmo, utilizemos o mais fácil.

    No final não importa a medida, por isso que achamos melhor no projeto que estava falando anteriormente utilizarmos um nome engraçadinho que deixasse claro que não existe medida física adequada.

    Interessante essa afirmação. Não havia me tocado sobre isso. É uma vantagem do modelo de pontos. Não havia visto umazinha sequer. O modelo de dias-ideais, pelo fato de se tratar de uma medida física, mais concreta, pode induzir a equipe a tratar a estimativa como a expressão da realidade. Nisso o modelo de pontos leva vantagem. Ainda assim, colocando na balança, prefiro o modelo de dias-ideais.

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

    Sobre pontos de função eu discordo do uso de PF para qualquer coisa. Ela não é “menos pior”, simplesmente é inadequada e tem um efeito nocivo de fazer com que as pessoas pensem que se baseia em alguma espécie de ciência.

    Fazendo uma analogia: Não é porque não temos uma cura para o câncer que beber ácido passa a ser um bom tratamento. Não só ele não melhora seu problema bem como cria muitos outros.

    Entendi e concordo. Quero deixar claro que sou absolutamente contra o uso de PFs. A única situação que vejo que a técnica seria aplicável, potencialmente interessante, seria em contratações públicas de certos tipos de sistemas.

    Minha afirmação é a seguinte: o modelo menos ruim de unidade de medida universal é PFs. Mas isso não quer dizer que defendo sua aplicação. Toquei no assunto simplesmente como forma de incrementar meu raciocínio e minha argumentação.

    Sobre o número de arquivos em específico eu também discordo. Se em 2009 você ainda usa uma plataforma onde lidar com arquivos é algo relevante a ponto de aumentar a complexidade do seu sistema isso me é muito estranho.

    Talvez nem valha a pena continuar a discussão desse ponto específico, já que concordamos que PFs é uma porcaria. Mas só para ficar claro: o conceito de arquivos de PFs é diferente do conceito convencional de arquivos. Não tem qualquer relação com a plataforma.

    http://apf.locaweb.com.br/mod/glossary/showentry.php?courseid=1&concept=Arquivo+Lógico+Interno

    http://apf.locaweb.com.br/mod/glossary/showentry.php?courseid=1&concept=Arquivo+de+Interface+Externa

  11. Clavius Tales diz:

    Oi, Alisson.

    Parabéns pelo blog!

    Valeu.

    Não considero P, M e G um modelo de estimativa, apenas uma forma de classificação de demandas.

    No caso de PFs, é.

    Conheço bem o seu caso (inclusive o estamos utilizando como inspiração para melhorar nosso processo; e você será o primeiro a quem quero apresentar quando estiver pronto) e seus PMGs não têm nada a ver com os PMGs dos PFs.

    Na minha opinião, a melhor forma de resolver o problema das estimativas é criar as condições para que você não precise estimar. Estimar é exercitar “futurologia”! É a cobra que come o próprio rabo. Ela só se sustenta pela pré-concepção íntriseca das relações comerciais de desconfiança mútua que aprendemos a estabelecer invariavelmente com nossos clientes.

    Aí você me dirá: – Impossível! Eu preciso dar um previsão para os meus clientes!

    Pois é… O conhecimento da humanidade não evolui por meio da melhoria contínua em cima de conceitos enraizados, mas por meio da completa substituição de idéias que até certo momento eram consideradas irrefutáveis. É o que já dizia Thomas Kuhn em sua teoria dos paradigmas.

    Entendo, mas acho difícil. Não me recordo agora de nenhuma atividade humana que conseguiu esse feito, até mesmo aquelas que dependem exclusivamente do talento dos envolvidos. Quando uma gravadora contrata uma banda, ela estabelece prazos para a conclusão dos projetos (ex.: um disco a cada dois anos). Quando uma editora contrata um escritor, também (ex.: um livro a cada três anos).

  12. Clavius Tales diz:

    Oi, MT.

    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.

  13. 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 ;)

  14. Clavius Tales diz:

    Oi, Calçado.

    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. ;-)

  15. > Entendo, mas acho difícil. Não me recordo agora de nenhuma atividade humana que conseguiu esse feito, até mesmo aquelas que dependem exclusivamente do talento dos envolvidos. Quando uma gravadora contrata uma banda, ela estabelece prazos para a conclusão dos projetos (ex.: um disco a cada dois anos). Quando uma editora contrata um escritor, também (ex.: um livro a cada três anos).

    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

  16. Clavius Tales diz:

    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.

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

    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.

  18. Aristofânio diz:

    “Clavius Tales Diz:

    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!

  19. Rodrigo de Toledo diz:

    Ola Clavius,

    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…

  20. Clavius Tales diz:

    Oi, Rodrigo.

    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.

  21. [...] (em geral, histórias) esperadas. Depois, a equipe estima cada funcionalidade em pontos (aqui na Fortes utilizamos horas-ideais). Somam-se então os pontos das funcionalidades achando o total de pontos do projeto. O resto é [...]


Deixar uma resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

WordPress.com Logo

Está a comentar usando a sua conta WordPress.com Log Out / Modificar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Log Out / Modificar )

Facebook photo

Está a comentar usando a sua conta Facebook Log Out / Modificar )

Google+ photo

Está a comentar usando a sua conta Google+ Log Out / Modificar )

Connecting to %s

Seguir

Get every new post delivered to your Inbox.