O documento discute a importância de estimativas em desenvolvimento de software, abordando métodos históricos e modernos, como análise de pontos de função e estimativas ágeis. Destaca a necessidade de avaliar custo e prazo de projetos de forma contextualizada e sugere que não há uma abordagem única para realização de estimativas. Além disso, menciona a visão do conceito #noestimates e suas limitações na prática.

2. ESTIMAR
lat. aestĭmo ou aestŭmāre
1. Fazer estimativa de; avaliar; calcular
2. Fazer avaliação aproximada de
3. Fazer julgamento a respeito de
(algo) com base nas evidências
existentes; achar, conjecturar

3. OBJETIVO
Definir o CUSTO do Produto,
através de uma previsão de:
● Tamanho (escopo)
● Esforço (pessoas/hora)
● Prazo

4. Mas, porém, todavia...

5. Anos 70
LOC – Lines of
Code e suas
variações: SLOC,
KLOC, AMLOC
Métodos
voltados ao
tamanho do
código fonte
00
80
70
90
Anos 90
UCP – Pontos
por Caso de Uso
Muitos fatores de
ajustes e muita
subjetividade
Anos 80
APF – Análise de
Ponto de Função
Mede tamanho e
não complexidade
2
Anos 2000
Metodologias
Ágeis
Planning Poker
T-Shirt Sizes
…
HISTÓRIA

6. 1 3 3
2 1
5 8 8
5 5
13 13
21
40 100
40 100
T-SHIRTS SIZES
AFFINITY ESTIMATION
A estimativa de afinidade é particularmente eficaz quando há um
número significativo de histórias para estimar. Aqui, a equipe
agrupará muitas histórias em baldes de uma só vez, em vez de
se concentrar em uma história de cada vez. Isso é ideal para
projetos de grande escala.

7. PLANNING POKER
Cada membro da equipe declarará sua
estimativa para uma história.
Se todos estimarem o mesmo número ou
um número semelhante, passe para a
próxima história.
Mas se cada membro da equipe tiver
estimativas diferentes, uma discussão é
feita para esclarecer o escopo, antes que
ocorra uma estimativa mais silenciosa.

8. Tem como fundamento básico a
afirmação que “estimativas não geram
valor”.
Prega que devemos evitar a todo modo
estimar, reduzindo tal atividade ou
mesmo a extinguindo.
Advoga que devemos bolar métodos
alternativos à estimativa. Será? Esse
caminho serve para a gente?
A ação seria desenvolver software sem
fornecer uma estimativa final de entrega
ao cliente e apresentar regularmente o
progresso do projeto.
#NoEstimates
Minha visão é que as ideias e
princípios do #NoEstimates são
muito válidos, mas não significa que
devam ou possam ser aplicados
indiscriminadamente.

9. O cliente te procura e faz a seguinte
solicitação:
“Quero adicionar ao meu produto
(site/app/…) um Bolão da Copa do
Mundo. Por favor me traga
AMANHÃ uma estimativa de PRAZO
e CUSTO, porém preciso que esteja
pronto em no máximo 45 dias para
ter tempo de fazer as ações de
marketing.”
Prazo
● Urgente!
● Produto deve ser entregue no máximo
em 45 dias!!
● ± 6 semanas → 3 Sprints de 2 semanas
Custo
● Preciso contratar mais profissionais?
● Quantos? Qual o prazo para efetivar as
contratações? Temporários?
● Ou realocar de outras Squads?
PROBLEMA PROPOSTO

10. Como fazer
essa
estimativa
para o meu
cliente?
PRAZO x CUSTO

11. Proposta:
Escala de 5 Pontos
David J. Anderson

12. Construir um Modelo
de Classes Abrangente
ou Similar
1
2
Construir uma
Lista de
Funcionalidades
ou de Histórias 3
Relacionar Classes
com
Funcionalidades
PASSOS

13. FDD - Feature-Driven Development

14. Modelo

15. Front End Back End
Tela de Boas Vindas API de Autenticação
Tela de Login API para Apostas
Tela de Regulamento API para Listar Pontuação Geral
Tela de Apostas
API para Listar Pontuação
Individual
Tela de Acompanhamento de
Pontuação
API para Calcular Pontuação
Lista de Features

16. Modelo x Features
Feature Classes
Tela de Boas Vindas
Tela de Login
Tela de Regulamento
Tela de Apostas
Tela de Acompanhamento de Pontuação
API de Autenticação
API para Apostas
API para Listar Pontuação Geral
API para Listar Pontuação Individual
API para Calcular Pontuação
0
1
0
3
2
1
3
2
2
3

17. Escala de 5 Pontos
Nº de Classes Complexidade
Esforço
(Pessoa-Dia)
1 1 0,5
2 2 1
3 3 2
4 4 4
5 5 8+
David Anderson, Agile Management for Software Engineering, 2003

18. Escala de 5 Pontos
Ajustada
Esforço adaptado utilizando Fibonacci
Nº de Classes Complexidade
Esforço
(Pessoa-Dia)
1 1 1
2 2 2
3 3 3
4 4 5
5 5 8+

19. Nossa Lista com Estimativas
Feature Classes Esforço
Tela de Boas Vindas 0 1
Tela de Login 1 1
Tela de Regulamento 0 1
Tela de Apostas 3 3
Tela de Acompanhamento de Pontuação 2 2
API de Autenticação 1 1
API para Apostas 2 3
API para Listar Pontuação Geral 2 2
API para Listar Pontuação Individual 2 2
API para Calcular Pontuação 3 3
5
10 dias
13 dias
Front
Back
5

20. Segundo a Estimativa de 5 Pontos
23 dias úteis
Considerando apenas
1 Dev Full Stack
Com 2 Devs
(1 Front e 1 Back)
o prazo passa a ser de
13 dias úteis
Prazo
2 a 3 Sprints
de 2 semanas para o
desenvolvimento.
Há uma margem
(pequena) para testes e
avaliações
Sprints
Com essas informações
você pode decidir
junto a direção se é
viável ou não assumir
esse projeto
Decisão

21. Estimar ou Não Estimar? Eis a questão!
E se estimar, qual método utilizar?
Não há uma resposta única e simples. Depende de vários fatores:
Cliente, Projeto, Equipe, Cultura, Maturidade, Prazo e outros.
Estimativas não devem ser classificadas nem como benéficas nem
como nocivas ao software, pois são fortemente dependentes do
contexto aplicado.
“Quanto menor o escopo estimado e maior a experiência dos
profissionais, maiores são as chances da estimativa se
transformar em realidade.” - Martin Fowler
Escolha a melhor opção para o seu negócio, sua equipe e seu
cliente!
O mais importante é não criar um ambiente de
Rally de Regularidade!
Conclusões

22. Jorge Bublitz
Engenheiro de Software
● Especialista em FDD – Feature-Driven
Development e Scrum Master (PSM I)
● Pós-graduado em Engenharia de Software
● Cursa Mestrado em Engenharia de Software
(Universidad Europea del Atlántico)
● Artigos publicados nas revistas Micro Sistemas,
Clube Delphi, MundoPM e Engenharia de
Software Magazine
● Palestrante na BorCon Revolutions 2007,
CodeRage III 2008, Ágiles 2012, Agile Brazil 2013
e CONIP 2016
bublitz@hotmail.com
linkedin.com/in/jorge-bublitz