BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Estimativas e cronogramas: úteis, prejudiciais ou os dois?

Estimativas e cronogramas: úteis, prejudiciais ou os dois?

Favoritos

Esther Derby, consultora de liderança e práticas ágeis e co-autora de dois livros, publicou em seu blog um post intitulado "Estimar costuma ser útil; mas estimativas costumam ser prejudiciais", onde defende a ideia de que o processo de gerar estimativas normalmente traz vários benefícios a um projeto; enquanto que a prática comum de se transformar as estimativas produzidas por este processo em um cronograma acaba prejudicando a equipe e o projeto.

Reforçando a recomendação contra o uso de estimativas para gerar cronogramas, Allan Kelly, consultor de práticas ágeis e de Lean, e autor de vários livros sobre desenvolvimento de software, cita pesquisas que concluem não ser possível usar estimativas de tempo de modo confiável como base para estabelecer um cronograma. Allan Kelly comenta o próprio post de Esther Derby, além de também documentar detalhadamente em seu blog as referências consultadas para se chegar a esta conclusão.

Aqui analisamos os dois pontos de vistas e adicionamos referências e novas perspectivas.

Estimativas versus cronogramas

Esther Derby começa comentando sobre o valor de se gerar estimativas:

Estimar ajuda quando o processo de estimação constrói um entendimento compartilhado, entre as pessoas que necessitam do trabalho realizado e as pessoas responsáveis por realizar este trabalho.

Estimar ajuda a descobrir e a validar premissas ocultas em um projeto, aumentando as suas chances de sucesso. Também ajuda a identificar riscos e permite que estes sejam amenizados ou removidos.

Por outro lado, estimativas feitas sem embasamento podem acabar sendo danosas. Por isso o processo de estimar deve ser baseado em entrevistas, modelos e experimentos (ex.: testes de hipóteses), clarificando os fatos e explicitando as premissas:

Às vezes, os estimadores descobrem que não sabem o suficiente para pensar sobre o tamanho ou esforço de nenhuma maneira significativa. Esta situação exige disciplina para resistir à especulação. Estimativas nascidas de advinhações são piores do que inúteis.

Problemas surgem quando as estimativas geradas pela equipe são transformadas em metas dentro de um cronograma. A este respeito, Esther Derby alerta:

Atingir o alvo se forma o verdadeiro objetivo e o método usado na prática passa a ser cumprir o cronograma. Satisfazer necessidades deixa de ser prioridade.

As estimativas são transformadas em promessas que, quando não são cumpridas, levam à busca por culpados, comprometendo a dinâmica e a produtividade da equipe.

O fato é que estimativas são apostas, com uma margem de erro implícita. Mas os gerentes normalmente não querem trabalhar com estas margens, o que gera desconfiança dos gerentes em relação à equipe e vice-versa.

Outro problema é a prática comum de se negociar estimativas: em vez de aceitar a estimativa gerada pela equipe, o gerente busca reduzí-la para atingir uma expectativa de prazo ou custo, o que compromete ainda mais a confiança entre o gerente e a equipe.

Estimativas versus previsibilidade

O post de Esther Derby gerou um fluxo intenso de comentários. Muitos profissionais de TI já passaram pelas situações descritas pela autora. Ao mesmo tempo, é uma necessidade real das equipes comunicar prazos e definir metas com a gerência e os patrocinadores do projeto. A empresa espera um comprometimento da equipe com metas, e a gerência necessita de certo grau de previsibilidade.

Uma questão levantada nos comentários foi: Se as estimativas não devem ser usadas, por serem prejudiciais, gerar estimativas não seria meramente um desperdício? Seria possível substituir as estimativas por outro mecanismo, que ajudasse a trazer previsibilidade, mas sem os riscos de se gerar metas irreais?

Em vários comentários foram sugeridas práticas ágeis, como a medição de velocidade do Scrum ou o poker de planejamento do XP. Estas práticas têm em comum o uso de estimativas de complexidade, em vez de estimativas de tempo; ajudam a manter o foco gerencial na entrega de funcionalidade, em vez de no controle do tempo.

Outra sugestão, apresentada nos comentários ao post de Allan Kelly (mais sobre ele adiante), é o uso da Estimativa Baseada em Evidências (EBS), de Joel Spolsky, autor do popular blog Joel on Software e um dos fundadores do site de perguntas e respostas Stack Overflow. A ideia é dar um tratamento estatístico, tanto ao registro de horas passadas quanto à estimativa de horas futuras, e realimentar este tratamento a cada iteração.

Embora a EBS seja focada no tempo gasto por atividade realizada pelo desenvolvedor (em vez de focar em funcionalidade entregue ao usuário, como nas metodologias ágeis) ela não gera datas precisas para a conclusão de cada tarefa, e sim uma distribuição de probabilidades para a data de conclusão de um conjunto de tarefas. Então a EBS suporta a ideia de Esther Derby de que não se deve usar estimativas de tempo como alvos ou milestones em um cronograma.

Talvez, grande parte do problema seja o fato de que os gerentes não sabem realmente o que está envolvido ao estimar o esforço no desenvolvimento de software. E seria uma função da equipe comunicar melhor esse fato, para reduzir a desconfiança dos gerentes. A equipe deve envolver os gerentes no processo de estimativas, e não se limitar a apresentar os resultados finais.

Por outro lado, os gerentes precisam ser honestos com a equipe. Esther menciona uma situação em que o objetivo era obter aprovação política do projeto, e não se estava realmente esperando uma definição precisa de custos e prazos. Infelizmente, este tipo de "jogo duplo" ocorre com bem mais frequência do que deveria nas empresas.

Não adianta querer controlar o tempo

Allan Kelly destaca em seus comentários ao post de Esther Derby a chamada falácia do planejamento, pela qual pessoas e empresas subestimam constantemente o tempo necessário para se concluir uma tarefa. A pesquisa na área, originada por Daniel Kahneman, psicólogo ganhador do prêmio Nobel de Economia, sugere que este "otimismo" não é ocasional; trata-se de algo sistemático, e que não é restrito à área de TI.

As pesquisas mostram que, mesmo quando confrontadas com seu próprio histórico de estimativas falhas, as pessoas continuam sendo otimistas e estimando tempos inferiores aos que serão necessários para realizar tarefas semelhantes. Então, o fato de conhecer o passado não ajudaria a prever o futuro, ao contrário da crença geral.

Ainda segundo as pesquisas, as pessoas só são otimistas quando estimam o tempo ou custo de tarefas nas quais elas próprias estão envolvidas. Se forem chamadas a estimar o tempo para a realização de uma tarefa por outras pessoas, serão pessimistas e sempre irão gerar uma estimativa maior que o necessário.

Nas palavras de Allan Kelly:

Quebrar a falácia do planejamento é difícil. Não funciona simplesmente "estimar melhor" nem "lembrar o tempo gasto com as tarefas anteriores". Pode-se ter sucesso em aumentar as estimativas para que fiquem mais longas do que o tempo real, mas você não conseguirá ser mais preciso.

Assim, qualquer metodologia para derivar cronogramas baseada em estimativas de tempo para realização de tarefas estaria fadada ao fracasso, pois sempre partiria de estimativas muito baixas - ou muito altas. Reconhecer este problema pode ajudar a diminuir a desconfiança entre gerentes e equipes de projetos.

Um ponto positivo é que, embora as estimativas de tempo sejam consistentemente abaixo (ou acima) do necessário, as pesquisas mostram que são fortemente correlacionadas com o tempo efetivamente gasto na realização de cada tarefa. Ou seja, tarefas que demandam menos tempo recebem estimativas proporcionalmente menores; e tarefas que demandam mais tempo recebem estimativas proporcionalmente maiores.

Conclui-se que as pesquisas suportam as práticas ágeis baseadas em métricas relativas e qualitativas para o dimensionamento de sprints. Estas métricas medem os resultados entregues nas iterações anteriores - e não o tempo gasto - como base para se prever a quantidade de trabalho (histórias, funcionalidades) que poderão ser realisticamente entregues nas próximas iterações.

Ter um registro do tempo gasto também não ajuda

Mas Allan Kelly se aprofunda na pesquisa relacionada com a questão de "estimativas retrospectivas", que são nada mais que a recordação do tempo gasto em uma tarefa, conforme a memória de quem executou a própria tarefa. Se as estimativas restrospectivas fossem confiáveis, seria possível usar usar o tempo gasto em tarefas no passado para se prever o tempo que será despendido em tarefas semelhantes no futuro.

Infelizmente a pesquisa indica que as pessoas não conseguem relembrar corretamente o tempo gasto em tarefas já realizadas, mesmo quando solicitadas a fazer isso juntamente com a execução da tarefa, ou logo após a sua conclusão. Ainda mais, as pessoas acreditam sistematicamente ter gasto bem menos tempo do que o real; isso sugere que os mecanismos psicológicos são semelhantes para se prever o futuro (estimativa) e para se registrar o passado (estimativa retrospectiva).

Em outras palavras, um timesheet estaria registrando um tempo menor do que o realmente gasto na execução das tarefas, comprometendo a utilidade deste registro histórico para se prever o tempo necessário para realizar tarefas semelhantes no futuro.

A já citada Estimativa Baseada em Evidências (EBS) de Joel Spolsky tenta fugir destas complicações, limitando o tratamento estatístico ao histórico e previsões de um desenvolvedor individual. Spolsky pressupõe, empiricamente, que uma pessoa irá estimar para cima ou para baixo em uma proporção mais ou menos constante, no passado recente.

Entretanto a técnica não é diretamente aplicável dentro de um processo ágil, pois não se inicia um sprint fixando qual desenvolvedor irá atuar sobre qual funcionalidade. Qualquer membro da equipe pode assumir qualquer item do backlog do sprint. Parece que o foco de Spolsky é em projetos executados por desenvolvedores individuais, e não por equipes.

Um dado interessante evidenciado pelas pesquisas citadas por Allan Kelly é uma correlação forte entre prazos preestabelecidos e o tempo de entrega real. Então as pesquisas suportam a noção intuitiva de que as pessoas "acabam se virando" para cumprir os prazos, quando estes são curtos, mas relaxam e alongam as tarefas quando os prazos são folgados.

Observe que não se está afirmando que os prazos sejam efetivamente cumpridos, e sim apenas que prazos menores levam a tempos de execução menores. Infelizmente, isto não ajuda muito se não conseguirmos definir quais seriam os prazos realistas e suficientes - porém não mais folgados que o necessário para acomodar os riscos. Em outras palavras, "gerenciamento por pressão" tem sua eficácila limitada pela falácia do planejamento e também pela imprecisão das estimativas retrospectivas.

Para conhecer mais sobre a literatura sobre a falácia do planejamento e as estimativas retrospectivas podem consultar o registro publicado por Allan Kelly complementar aos posts em seu blog.

Conclusões

A experiência dos profissionais de TI e pesquisas acadêmicas e profissionais indicam fortemente que não é possível gerenciar o tempo gasto na execução de tarefas. Desse modo, não adianta buscar melhores mecanismos para se prever o tempo, nem mesmo manter um registro detalhado do passado. Isso porque nossa psicologia irá trabalhar contra qualquer um desses métodos.

A solução, como se prega nas metodologias ágeis, envolve o uso de medidas relativas e qualitativas de produção. Como sabemos, são medidas quantas funcionalidades (não tarefas!) simples, medianas ou complexas foram concluídas nas iterações passadas, e toma-se isto como base para prever quantas novas funcionalidades serão entregues nas iterações futuras.

A equipe estima não as tarefas que serão realizadas para entregar as funcionalidades, mas sim a complexidade das próprias funcionalidades, pois esta é a estimativa que as pessoas acerta, segundo as pesquisas. Então, mesmo não sendo definidos prazos para executar atividades, os gerentes conseguem alguma previsibilidade em relação ao resultados de cada iteração.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

  • Como se comprometer com seu cliente?

    by Alexandre Queiroz,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Até um tempo atrás eu brincava que nosso trabalho era baseado em um planejamento das atividades que era orientado a datas e não em "cronogramas". Quando se diz que não temos um cronograma, fica parecendo várias pessoas trabalhando desordenadamente sem objetivo. A grande questão é saber como fechar um acordo com meu cliente interno sobre uma visão de estimativas reais, com soluções eficazes, sem passar uma posição "step-by-step" das atividades do nosso time na linha do tempo. Será que não estamos voltando para o modelo cascata?

  • Re: Como se comprometer com seu cliente?

    by Fernando Lozano,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Eu vejo que a grande dificuldade é fazer o cliente acreditar que podemos trabalhar sem definir a priori todo o escopo e entregas. Em vez de nos comprometermos a priori, que seria o modelo cascata, vamos assumindo compromissos pouco-a-pouco, a cada iteração, dentro de uma metodologia ágil. Mas quando o cliente vê na prática que, em vez de um cronograma que nunca é obedecido, ele passa a ter, depois de algumas iterações, as principais funcionalidades prometidas no início entregues no final, ele passa a confiar.

  • Lei de Hofstadter

    by Daniel Serodio,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Não se pode esquecer da Lei de Hofstadter:

    Sempre leva mais tempo do que o estimado, mesmo quando se considera a Lei de Hofstadter

  • Re: Como se comprometer com seu cliente?

    by Daniel Serodio,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Alexandre, acho você está confundindo cronograma com planejamento. Quando as pessoas estão trabalhando desordenadamente sem objetivo é por que não há planejamento. E assim como acontece com as estimativas, o importante é o processo, e não o resultado - isso é, o planejamento é mais importante do que o plano.

  • Adaptar sempre é preciso, porém podemos errar.

    by Alex Almeida,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Senhores, pelo jeito não existe a fórmula do sucesso, cada caso deve ser analisado e utilizado o que melhor se adapta a nossa realidade e a do cliente.
    Onde trabalho temos um grande problema com estimativas de complexidade (planning poker) e quanto tempo levaremos para executar as tarefas.
    Nossas tarefas são planejada em horas, isso é somado e entregue um relatório com quantas horas vamos executar no Sprint. Porém ao final do sprint podemos não ter entregue todas as estórias porque uma ou outra estimativa foi subestimada, só que nossos gerentes precisam de números e números, ou seja, estórias que não foram entregues torna o sprint um fracasso.
    O efeito colateral disso é que a equipe começa a estimar com uma gordura cada vez mais grossa, para dar impressão de que estamos entregando tudoe que o sprint foi um sucesso, mas e a produtividade?
    Por isso é muito complicado querer trabalhar com exatidão quando nossas métrica são baseadas em estimativas. Na verdade sinto que estamos perdidos quanto a isso, e que poderia ser melhor, mas ainda não vejo como unir, se possível, os dois mundos

  • Re: Adaptar sempre é preciso, porém podemos errar.

    by Fernando Lozano,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Alex, é uma premissa de todas as metodologias ágeis que nem tudo que foi planejado para o sprint será entregue. Scrum, XP e outras reconhecem a inexatidão das estimativas, mesmo assim trazem alguma previsibilidade ao parar de focar no tempo. É importante que seus gerentes entendam estas premissas e reconheçam a impossibilidade de se trabalhar baseado em planejamento de horas. Acompanhar horas por tarefas sempre vai levar a distorções e gerar stress na equipe, e desconfiança na gerência. Desenvolver software é gerenciar risco, é aceitar a inexatidão inerente ao processo e trabalhar com ela, em vez de buscar uma exatidão artificial e pressionar a equipe para obte-la.

    Vocês estão classificando suas estórias conforme dificuldade (planning poker), mas estão calculando sua velocidade à partir das iterações anteriores, e usando isso para decidir quantas estórias aceitar para a próxima iteração? A experiência geral do mercado mostra que depois de algumas iterações a margem de erro na quantidade de estórias entregues por iteração diminui bastante. Isto está acontecendo com vocês?

  • Re: Como se comprometer com seu cliente?

    by Alexandre Queiroz,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Olá Daniel! Como eu disse, eu "brincava". Esses dois conceitos são bem claros na minha cabeça: Cronograma e Planejamento. Uma estimativa onde apenas se enxerga um número (seja velocidade do time, UCP, horas, etc.) realmente ficam informações descartáveis quando não são aplicadas dentro de um planejamento claro e verdadeiro. Concordo contigo que o planejamento é mais importante que o plano mesmo. Só não fico confortável ainda em não focar em resultados, que é onde o cliente (injustamente ou não) valida seu ROI. Um abraço!

  • Re: Adaptar sempre é preciso, porém podemos errar.

    by Alex Almeida,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Fernando, o restrospecto nos ajuda quando as estórias são baseadas em algo que fizemos, ou continuacao de uma estoória, uma estória completamente nova é dificil de ter uma base. As vezes olhar para trás pode ser prejudicial se vc teve uma experiência negativa, vc acaba levando consigo uma carga maior, quando as vezes nem é tão complexo. Por outro lado vc tb pode levar boas experiências que vão ajudar no entendimento da equipe. Mas a margem de erro diminui mesmo quando vc esta acostumado com o produto, algumas pessoas novas que entram na equipe erram um pouco no começo, mas durante o planning a gente vai explicando, ai elas vão se acostumando e entram no eixo.

  • Re: Como se comprometer com seu cliente?

    by Gustavo Freitas,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Exatamente Fernando! Estou de acordo contigo. A maioria das metodologias ágeis tem como um dos fortes compromissos - estabelecer confiança. A confiança mútua entre fornecedor e cliente só pode ser conquistada depois de algum tempo e bastante exercício, entregando funcionalidades por prioridade. O modelo cascata por si só é incapaz de gerar confiança, dado que o ciclo do projeto não é interrompido, mesmo quando há falhas. No final, o custo e a entrega das funcionalidades, mesmo que o cliente não esteja de acordo já foi estabelecido e desenvolvido.
    É preciso ponderar, como os próprios artigos dizem. É necessário levar em consideração o trabalho em equipes, mas jamais desconsiderar de que estimativas nada mais são do que "achismos".

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT