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.