Estimar é Desperdício!

Para começar minha participação nesse blog, resolvi escrever sobre algumas ideias que venho tendo a algum tempo, e que recentemente vieram à tona por causa de uma discussão na lista Scrum Brasil.

Contextualizando, a discussão começou com uma duvida sobre como estimar projetos de escopo fechado com Scrum, e passou por técnicas como Pontos por Caso de Uso (UCP), Pontos de Função (PF), Story Points, entre outras.

A idéia desse post não é discutir técnicas de estimativas (o que fica para outra hora, se alguem estiver interessado), mas sim apontar para um fato que nem todo mundo se lembra na hora de estimar:

Estimativa é Desperdício!

Quando digo isso não quero dizer que não se deve estimar, ou que estimativas não servem para nada. O que quero deixar claro é que quando estamos usando (perdendo) tempo para estimar, não estamos adicionando nenhum valor para o produto que está sendo entregue (o software), mas sim realizando um processo de apoio, que deve ser considerado desperdício.

É claro que na maioria dos casos, estimar é um desperdício necessário, mas devemos ter em mente para que estamos criando estimativas, de forma a otimizar ao máximo o processo.

O Chris Leishman escreveu um post interessante sobre isso, onde ele especifica as três razões (3 Ps) para estimar. Resumidamente:

  • Prediction: para estabelecer o escopo e tamanho do projeto
  • Prioritisation: para que o cliente possa priorizar as estorias que devem ser executadas
  • Performance: para medir o desempenho da equipe

Entao, quando penso sobre estimativas, gosto de pensar para que essas estimativas vão servir, e tentar descobrir como atingir esse objetivo com o menor esforço possível, para poder dedicar mais tempo ao que realmente importa, que é desenvolver software.

Ps: Vale a pena comentar que não vejo nenhum caso onde o tempo gasto com análises como UCP ou PF é justificável🙂

Sobre o autor:

Frank Trindade

Francisco Trindade

Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.

14 thoughts on “Estimar é Desperdício!

  1. Olá Francisco. Não concordo com a idéia de que estimar é desperdício. Como você mesmo citou, “permitir que o cliente priorize as histórias” ou “medir o desempenho da equipe” não tem valor? Acredito sinceramente que desenvolver software não é somente escrever código, como sugerido no seu texto. Pelo pensamento defendido por você, escrever testes também é desperdiçar tempo.
    Mas tudo bem, ainda tentando entender, como trabalhar sem estimar, então? Acho que ficou faltando esta “resposta” no seu post.

  2. Olá!
    Interessante, e concordo, ma a partir do seu texto surgem algumas dúvidas:
    1) Entao: como convencer o usuário sobre isso?
    2) Como dizer isso ao seu chefe?
    3) Estou participando do projeto de desenvolvimento da metologia que será usada na empresa, e queremos adotar uma metodologia ágil baseada em OpenUP, surgir essa dúvida sobre como estimar. A empresa q trabalho está inserindo PF para as estimativas, vou falar pro meu chefe que nao é a forma mais adequada? Ou vamos trabalhar com RUP?

    []s,

  3. @Adolfo,

    concordo com vc, e escolhi esse titulo justamente para levantar a polemica e causar essa discussão🙂.

    Quando falo que estimar é desperdício, não quero dizer que não tem valor nenhum ou que não devemos faze-lo, mas sim que temos que nos dar conta que estimar não entrega nenhum valor para o cliente. Ou seja, no produto final que o cliente leva (o software), a estimativa não acrescenta nada, e devemos ter consciência disso na hora que decidimos como fazer nossa estimativa.

    Mas em nenhum momento falei que não devemos estimar (o que já é defendido por algumas pessoas, mas ainda não concordo com isso). Conforme falei, estimar é um desperdício necessário na minha opinião. Só devemos ter clareza em qual o motivo das nossas estimativas, para sabermos a melhor maneira de cria-las.

    Um abraco,
    Francisco

  4. @Wagner,

    bom, várias perguntas….

    Em relação ao usuário e o cliente, acho q a resposta é sempre a mesma. Tu deve pensar no que achas q é melhor para a equipe (o modo de estimar, nesse caso), e apresentar isso para o cliente ou chefe. A melhor maneira, na minha opinão, é tentar esclarecer para que vcs estão tentando estimar, e mostrar que as vezes detalhes demais não vão fazer muita diferença.

    Concordo que não é uma tarefa fácil, escrevi mais ou menos sobre esse assunto em um post no meu blog (http://franktrindade.wordpress.com/2008/05/20/uncertainty/), discutindo como é dificil para a maioria das pessoas aceitar as incertezas que existem no desenvolvimento de software.

    Em relação à análise por PF, eu acho que a complexidade da análise não é justificada em nenhum momento pela precisão do resultado gerado. Estimar sempre eh um chute (chute científico, alguns diriam), então não vejo porque tentar gastar mais tempo fazendo isso através de PF, se o resultado que se vai obter não tem mais precisãpo do que métodos mais empíricos, como story points, por exemplo.

    Espero ter ajudado.

    Um abraço,
    Francisco

  5. A proposta é interessante até mesmo porque, quando começamos um projeto de software, a quantidade não chega a ser suficiente para ter uma idéia da real proporção do trabalho.
    O que acontece é que o cliente não assina contrato com custo em aberto. Como tratar isso?? Um contrato de Fábrica de Software lida com isso fácil já que trata de vários projetos que podem consumir a métrica que você achar melhor. Mas e um projeto isolado?

  6. Estimar tem valor para o cliente. Através de estimativas o cliente consegue gerenciar expectativas, montar planos de marketing, prever seu orçamento para o ano, prever demanda e utilização, comprar recursos just-in-time, etc.

    Se houvesse um meio mágico de estimar software com precisão aceitável ele seria ótimo, o grande problema é que este método mágico não existe, então estimar é uma atividade que produz resultados não tão valiosos quanto poderia.

    Desta forma, estimar é caro e não produz resultados tão confiáveis, mas ainda assim entrega valor.

    []s

  7. Philip,

    tbm concordo com vc, e se esse for o caso (o cliente vai utilizar essas estimativas para fazer alguma coisa), entao se sabe para que queremos estimar, e devemos mais uma vez pensar na melhor forma de fazer isso.

    Eh mais ou menos como com documentacao (embora eu concorde que estimativas sao mais frequentemente necessarias do que documentacao : ). Se o cliente precisa da documentacao por algum motivo, entao ela passa a ter valor, senao nao.

    Abraco,
    Francisco

  8. Francisco, se você concorda que as estimativas têm algum valor, então porque colocou o título de “Estimar é Desperdício!” no seu post? Pelo que entendi, você gostaria de dizer algo do tipo “estimar gera mais esforço que valor”, não? Bom, de qualquer forma, isso é muito difícil de medir. Não é fácil determinar o valor de estimativas, testes, reuniões diárias, pareamento e todas as outras práticas que estão fora “do que realmente importa, que é desenvolver software”.
    De qualquer forma, parabéns pelo artigo. Acho que está gerando uma discussão importante😉

  9. Adolfo,

    antes de mais nada, obrigado : )

    Quanto ao termo, ele pode ser considerado a maior contribuicao que eu queria passar com o post.

    Justamente pq para melhorarmos o processo de desenvolvimento de software, temos que separar o que agrega valor para o cliente e o que sao praticas inseridas no sistema que em si nao agregam valor (a nao ser em casos, como o Philip citou, em que o cliente realmente necessita da estimativa), mas sao realizados pq de alguma forma sao considerados necessarios.

    E tu realmente entendeu o ponto. Estimativas, testes, reuniões diárias, etc.. sao tambem desperdicios, mas isso nao quer dizer que nao sejam necessarios.

    E eu acho importante considerar tudo isso desperdicio, pq so assim eu posso tentar otimizar o processo, me questionando se esses desperdicios ainda sao necessarios ou nao. Caso contrario, se acaba seguindo um processo so pq o processo foi definido daquela maneira. Se estima, mas nao se sabe exatamente por que.

    Espero ter esclarecido (ou confundido) um pouco mais : )

    Abraco,
    Francisco

  10. Claro q quando digo q o termo eh a maior contribuicao, nao quer dizer q eu inventei ele….: )

    Desperdicio (waste, ou muda) eh um conceito de Lean, e serve para identificar partes do sistema que nao agregam valor ao produto final.

    []’s

  11. Opa Francisco,
    “E tu realmente entendeu o ponto. Estimativas, testes, reuniões diárias, etc.. sao tambem desperdicios, mas isso nao quer dizer que nao sejam necessarios”

    Legal!! Também acho que são necessários (e quase sempre).

    “E eu acho importante considerar tudo isso desperdicio, pq so assim eu posso tentar otimizar o processo, me questionando se esses desperdicios ainda sao necessarios ou nao. Caso contrario, se acaba seguindo um processo so pq o processo foi definido daquela maneira. Se estima, mas nao se sabe exatamente por que.”

    Agora o seu ponto ficou bem mais claro pra mim. Nunca tinha pensado assim e é realmente muito muito interessante a idéia que você passou. Serviu pra me lembrar de que preciso urgentemente ler um bom livro de Lean🙂

    Obrigado pelos esclarecimentos e pelo diálogo, Francisco!!!

  12. Pingback: Desconforto « Blog Visão Ágil

  13. Pingback: Por que usar “story points”? « Blog Visão Ágil

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s