O documento discute as estimativas de projetos e argumenta que aproximações são melhores do que precisões. Estimativas não devem ser vistas como certezas, mas sim como palpites úteis. É melhor estar aproximadamente certo do que precisamente errado. Estimativas devem ser usadas para gerir expectativas, não para definir sucesso ou falha de projetos.

1. Estimativas:
Aproximação ou Precisão?
Julho 2016

2. Pedro Gustavo Torres
Ágil desde 2010
Agile Coach & Delivery Area
Manager
@_pedro_torres

3. Comunidades
20142014
2012 2013 2014 2015 2016

4. Definição de Estimativa (com AO)
Fonte: http://www.infopedia.pt/

5. Definição de Estimativa (sem AO)
Fonte: http://www.infopedia.pt/

6. Estimar não é
Uma certeza
Um contrato
Uma data
Um compromisso
Uma data da data

7. Estimar é
Um palpite
Um bitaite
Uma opinião
Um feeling
Uma ideia

8. Estimativas != Certezas

9. Estimativas são úteis?
Os gestores adoram-nas… os developers odeiam-nas!

10. Estamos formados para estimar? (ex: FEUP)

11. Como se pode estimar?
• Horas
• Dias
• Pontos
• T-shirt size
• Throughput
• …

12. Para que servem as estimativas?
• Criar roadmaps?
• Adjudicar projectos?
• Para ter deadlines?
• Para definir o sucesso de um projecto?

13. Exemplo: Casa da Música, Porto, Portugal

14. Exemplo: Casa da Ópera, Sydney, Austrália

15. Exemplo: Casa da Ópera, Sydney, Austrália

16. Sucesso de um projecto?
“Caros são aqueles jogadores que se compram e não jogam”
Terminar dentro do prazo previsto? (mesmo que não seja usado)
Ou…
Que apesar de atrasado é usado? (e que se paga por si só)

17. Estamos focados na coisa errada!
• Estimativas não tem grande significado
• Estimativas não trazem valor para o nosso cliente
• Porquê tomar decisões baseadas em palpites?
• E se tentássemos decidir com base no ROI ou no Lucro?
• Quando foi a última vez que um projecto foi abortado porque pela
estimativa ia demorar muito tempo?
• Tipicamente os projectos são para ontem
• Ainda não começamos e já estamos atrasados!

18. Porque é que estimamos?
A) Estamos aborrecidos
B) É divertido
C) Somos muitos bons a estimar
D) Queremos prever o futuro

19. Porque é que estimamos?
D) Queremos prever o futuro

20. Prever o futuro: Gantt Chart

21. Prever o futuro: Gantt Chart

22. Prever o futuro: Mais técnicas
• Monte Carlo
• Três pontos
• COCOMO
• KLOC
• Wideband Delphi
• …

23. Prever o futuro: Buffers

24. Prever o futuro: Student Syndrome

25. Prever o futuro: Student Syndrome

26. Prever o futuro: Parkinson’s law

27. Prever o futuro: Parkinson’s law

28. Prever o futuro: Informação irrelevante

29. Prever o futuro: Tamanho da especificação

30. Prever o futuro: Requisitos extra

31. Prever o futuro: Ancoragem

32. Prever o futuro: Ancoragem (Dilbert)

33. Porque é que estimamos?
D) Queremos prever o futuro

34. Porque é que estimamos?
E) Queremos prever o futuro… de forma útil!

35. Qual é o problema que procuramos resolver?
Queremos prever o futuro… de forma útil!

36. Qual é o problema que procuramos resolver?
Queremos prever o futuro… de forma útil!

37. Qual é o problema que procuramos resolver?
Queremos prever o futuro… de forma útil!

38. Qual é o problema que procuramos resolver?
Queremos prever o futuro… de forma útil!
“The future cannot be predicted, but futures can be invented.
We cannot predict the future, but we can invent it.
The way to cope with the future is to create it.
The best way to predict the future is to invent it.
The best way to predict the future is to create it.
You cannot predict the future, but you can create it.”
Peter Drucker; Abraham Lincoln; Dennis Gabor

39. Prever o futuro de forma útil: Aproximação vs Precisão
• Estimar é caro.... se estamos a estimar não estamos a desenvolver!
• Quanto custa a precisão?
• E a aproximação? É melhor estar
aproximadamente
certo do que
precisamente
errado!

40. Prever o futuro de forma útil: Aproximação vs Precisão
Mike Cohn

41. Ex: Duração de uma viagem Porto -> Lisboa
• Qual é a duração de uma viagem de carro Porto -> Lisboa?
• E se receber o ordenado dependesse de acertarem?
(Estimativa por alto? Ficavam na última estação de serviço a fazer
tempo?)
• Um intervalo de tempo? Ajudava?
• E se só tivessem de responder à pergunta (o tempo que demorariam)
a 10 kms de chegar? Ajudava?

42. Cone da incerteza

43. Gerir expectativas
• Estimativas deverão ser sempre duração e não calendário (exemplo: 3
semanas e não "23 de julho") e em intervalo de tempo para
demonstrar a incerteza que temos (exemplo: 2 a 3 semanas)
• Para promover: Transparência e honestidade

44. Pontos
• Estimativa por comparação (melhor que estimativas absolutas)
• Tipicamente usa-se a escala de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21, …)
• Quando é que está pronto? No final da sprint…

45. Como estimar um Backlog do zero
Duas escolas de pensamento
(Pontuamos o resto através de comparação de esforço e risco)
Escolhemos um requisito que
toda a equipa considera
básico…
e atribuímos-lhe 1 ponto
Escolhemos um requisito
ligeiramente complicado…
e atribuímos-lhe 3 pontos

46. Pontos “traduzidos” em tempo

47. Planning Poker

48. Velocidade
• Fórmulas de cálculo:
• Média de pontos entregues desde sempre
• Média de pontos entregues das últimas 6 sprints
• Média de pontos entregues das últimas 6 sprints descartando a melhor e a pior
sprint
• …
Ou…
• Yesterday’s weather... (Jeff Sutherland’s A Pattern Language For
Hyperproductivity)
• Baseada nos pontos entregues na última sprint

49. Re-estimar: Sim ou Não?

50. Re-estimar: Sim ou Não?
• Antes de começar o trabalho: Sim
• Durante o trabalho: Não
• Depois do trabalho estar concluído: Não (mas há quem goste)

51. Estimar bugs?
• Tipicamente: Não
• Excepção (discutível): Se a equipa apenas / maioritariamente resolver
bugs

52. T-shirt size
• Em vez de usarmos pontos usamos o tamanho da roupa
• Comparamos uns tamanhos com os outros
• É mais difícil de apurar a velocidade
• Mas é mais fácil / simples de estimar

53. Throughput
• Em vez de tentarmos estimar cada item de trabalho / requisito…
• “Fatiamos” / Reduzimos os requisitos (sensivelmente) ao mesmo
tamanho… e contamos o número de requisitos implementados por
intervalo de tempo

54. Estimar: sim ou não?

55. Então o que resulta?
• Herbalife… Não
• Tempo… Meh
• Pontos… Sim

56. Então o que resulta?
• O truque é ter sempre tudo shippable (semana a semana,
mensalmente, de forma contínua, etc) e receber funding enquanto
justificar
• Usem o fenómeno móveis IKEA (envolver o cliente construindo o
produto com ele e com entregas regulares) para relativizar o tempo
de Projecto. Com confiança tudo é mais fácil!

57. Então o que resulta?
• Se precisam de saber a estimativa com rigor ao dia … para saber se
um projecto deve (ou não) avançar.... então provavelmente não devia
avançar.
• Escolham projectos que sejam óbvios e não duvidosos!

58. Obrigado! 
Estimativas:
Aproximação ou Precisão?