Argumentação contrária às técnicas tradicionais de estimativa de esforço de software.

1. O Sofisma do Plano do Projeto
Detalhado em Desenvolvimento de
Software – Visões da Prática
Prof. Rogério Atem de Carvalho, D. Sc.
Prof. Rodrigo Soares Manhães, M. Sc.

2. Objetivo deste Documento
● Mostrar, por argumentação lógica que a
construção de planos de projeto detalhados no
âmbito de desenvolvimento de software na prática:
– Forçam o seguimento de um ciclo em cascata e/ou
– São muito imprecisos, levando a altos custos da função
controle e de constantes mudanças no processo e no
próprio planejamento.
– V 0.9: 21/10/2008
– V 1.0: 02/03/2009

3. O Plano do Projeto na Indústria
● Trataremos inicialmente da indústria que trabalha
por encomenda e não a que produz por previsão de
demanda, já que desenvolvimento de software é
também produção por encomenda.
● A indústria, no geral, segue um processo de
projeto em cascata:
– Elicitar os requisitos do produto junto ao cliente.
– Projetar o projeto por completo (Engenharia do
Produto).
– Apresentar o projeto ao cliente.
– Sendo aceito, partir para o planejamento e posterior
execução e controle do projeto.

4. O Plano do Projeto na Indústria
● O planejamento se baseia em técnicas de
estimativa de alocação de recursos bem
dominadas.
● Assim, as estimativas funcionam a contento,
devendo apenas eventos aleatórios (como quebra
de máquina) causar desvios do curso planejado.
● O uso dos recursos é bastante padronizado. Por
exemplo: “para colocar 50 metros de dutos
térmicos na plataforma P-XYZ precisaremos de
um técnico em dutos, trabalhando durante 3
dias...”

5. O Plano do Projeto na Indústria
● Com estimativas precisas e um produto totalmente
projetado, faz sentido programar detalhadamente as
atividades futuras.
● Diga-se de passagem, quando regulação e/ou
recursos escassos se fazem presentes, o projeto
completo do produto deve ser feito a priori.
● Exemplo clássico e vivenciado na prática são obras
offshore: são reguladas por normas ambientais e de
Engenharia e a necessidade de planejar a alocação
de recursos é central ao problema, como por
exemplo, vaga em helicóptero e na plataforma.

6. O Plano do Projeto na Indústria
● Resumindo: por que o ciclo em cascata é aceito e
muito usado nas Engenharias?
– Porque as técnicas de projeto do produto são
estabelecidas há décadas (as vezes séculos) e são
padronizadas, o que facilita enormemente as
estimativas. Assim, a demanda por HH é conhecida a
priori.
– Porque a regulação exige que o projeto do produto
esteja completo antes de iniciar sua execução.
– Porque os produtos são tangíveis e as atividades
envolvem relativamente pouco de criatividade e muito
de “seguir o manual”.

7. Primeiro Encadeamento Lógico
Planejamento detalhado precisa de → estimativas
detalhadas (para definição do prazo = recurso tempo)
Estimativas detalhadas precisam de → projeto do
produto detalhado (para definição das atividades)
Então
Planejamento detalhado precisa de → projeto do produto
detalhado
Temos que
Projeto do produto detalhado no início → ciclo em
cascata
Então
Planejamento detalhado leva a → ciclo em cascata!

8. Primeiras conclusões
● A argumentação poderia parar aqui já que cairia
numa discussão de uso ou não do Ciclo em
Cascata, que já é sabidamente ineficiente em
desenvolvimento de software.
● Ainda assim, poderia ser sugerido que em alguns
casos é necessário fazer o projeto do produto a
priori, como por exemplo, em licitações do
Governo.
● Assim, agradavelmente forçados pela Lei, os
“detalhistas” partiriam para o projeto (integral) do
produto e tudo estaria bem...

9. A Dura Realidade do Software
● Infelizmente, o software é um produto intangível,
produzido por trabalhadores do conhecimento.
● Intangível: não é possível mensurar suas
características físicas (como material necessário),
simplesmente porque ele não é físico!
● Trabalho baseado no conhecimento: difícil de
mensurar também (como o tempo das operações),
pois além de não físico, é artesanal e dependente
da criatividade.
● Adicionalmente, é quase totalmente dependente
das pessoas e consequentemente de todas suas
especificidades.

10. A Dura Realidade do Software
● Em termos práticos, de onde vem a incerteza no
software?
– Rápidas mudanças tecnológicas
– Algumas tarefas consideradas simples se mostram
complexas
– Trabalho não repetitivo e baseado em criatividade
– Mudanças nos requisitos
– Necessidade de aprender sobre o problema ao qual o
sistema está relacionado
– Etc
(os argumentos acima são empregados justamente em
favor de ciclos iterativos-incrementais e contra cascata)

11. Segundo Encadeamento Lógico
Software → bem intangível, produto não físico
Software → produção baseada no conhecimento, recurso
não físico
Produção baseada no conhecimento E bem intangível →
não existem medidas físicas (por definição!)
Falta de medidas físicas → estimativas imprecisas
Juntando com o primeiro encadeamento:
Planejamento detalhado precisa de → estimativas
detalhadas
Software → estimativas imprecisas
Então
Não é possível fazer estimativas precisas em software,
mesmo pagando o preço do ciclo em cascata!!!!!!!!!

12. Primeiras conclusões
● Os planejamento do projeto detalhado funciona na
indústria de bens materiais, porém foi transplantado para a
Engenharia de Software sem os devidos cuidados...
● Algumas organizações insistem nesse modelo falho,
trazendo altos custos de controle e de replanejamento.
● Surgem absurdos como por exemplo, forçar o cronograma
a se encaixar na estimativa de esforço (aumentando as
horas extras = aumentando custos) ou forçar estimativas
para cima, de maneira a deixar folgas.
● Ao fim, o objetivo se torna não um melhor processo
produtivo, mas criar uma ilusão de controle (“o rabo
abana o cachorro”).

13. Primeiras conclusões
● Um diálogo possível (digamos em dezembro de 2009):
– Preciso do planejamento detalhado para 2010...
– Como vou saber o que estaremos fazendo na semana 3 de
outubro de 2010, por exemplo?
– Faça uma estimativa!
– Mas as estimativas são grosseiras!
– Apresente o planejamento detalhado em função das
estimativas e então quando estiver mais próximo, replaneje
e atualize toda a documentação do cronograma...
– Se eu com certeza vou ter que replanejar, por que fazer o
planejamento detalhado?
– Para mostrar que você sabe planejar...

14. Primeiras conclusões
● Então, quem poderá intervir?
Spectroman?
Super Mouse?
Chapolin Colorado?
Mais controle gerencial?
Mais burocracia?
Constante replanejamento detalhado?
Proibir mudanças nos requisitos?
● Talvez a solução seja olhar para as experiências da
indústria que trabalha sob demanda e não sob
encomenda...

15. Produzindo com Incerteza na
Demanda
● A indústria de bens de consumo produz bens
tangíveis, com tempos de produção razoavelmente
determinísticos.
● O maior fator de incerteza se encontra na
demanda.
● Maior demanda pode gerar perdas de vendas.
● Menor demanda pode gerar estoque.
● Como se adaptar às flutuações de demanda?
– Durante décadas usou-se o planejamento detalhado,
que na realidade virava um loop de replanejamento
constante e controle da produção caro e complexo. E
ainda assim, FALHO.

16. Produzindo com Incerteza na
Demanda
● Na contramão do Ocidente, os japoneses criaram
um sistema simples, de controle manual mas ...
essencialmente dinâmico!
● Esse sistema é conhecido por vários nomes, como
Just In Time, Kanban, Toyota...
● Toyota foi onde surgiu, JIT é a filosofia como um
todo e Kanban o sistema de programação e
controle da produção.
● Atualmente, junto com outras práticas, usa-se o
termo genérico Lean Manufacturing.

17. Produzindo com Incerteza na
Demanda
● Esse sistema se baseia em:
– Valorização do trabalhador
– Qualidade durante todo o processo (e não após!) e
como responsabilidade de cada um.
– Programação simples.
– Controle simples.
– Decisão descentralizada.
● Como resultado esse sistema trouxe um
dinamismo maior aos sistemas produtivos, fazendo
com que os níveis de produção acompanhassem a
demanda, ao invés de tentar (em vão) se antecipar
a ela.

18. Produzindo com Incerteza na
Demanda
● Para quem duvida como métodos simples podem
ser a solução para problemas complexos:
– Os japoneses dominam a venda de automóveis nos
EUA desde os anos 70.
– “Como eles fazem carros melhores, mais baratos, em
menos tempo, se não usam nossos detalhadíssimos
mecanismos gerenciais que vêm evoluindo há
décadas?”.

19. Produzindo com Incerteza na
Demanda
● Resposta:
– Subordinando o processo ao produto e não o contrário!
– Subordinando as atividades de gestão às de chão de
fábrica e não o contrário!
– Trazendo quem faz para o centro da discussão de como
e quando se faz.
– Em suma, chega do rabo abanar o cachorro!!!!!!
● A indústria ocidental, após se recuperar do
choque, passou a adotar as mesmas técnicas, bem
como mesclar com outras, levando ao surgimento
do Lean Manufacturing (Produção Enxuta).

20. Produzindo com Incerteza na
Demanda
● Por que então utilizar métodos de produção sob
demanda e não de produção sob encomenda se o
software é encomendado?
● Porque a questão não está no modo de colocação
do pedido de produção, mas nas incertezas no
processo produtivo.
● Assim, embora o software seja encomendado, por
ser um bem intangível não é possível determinar
com precisão as quantidades de recursos a serem
alocados à sua produção, levando a incertezas no
processo produtivo.

21. Terceiro Encadeamento Lógico
Do segundo encadeamento:
Produção baseada no conhecimento E bem intangível →
não existem medidas físicas (por definição!)
Falta de medidas físicas → estimativas imprecisas
Temos que:
Estimativas imprecisas → alta incerteza no processo
produtivo
E também
Produção sob encomenda → baixa incerteza no processo
produtivo
Então
Não é razoável empregar métodos que esperam baixa
incerteza no processo produtivo para construir
software!!!!!!!!!

22. Conclusões
 A estimativa de esforço é necessária, porém só terá
uma precisão razoável se feita em janelas de tempo
pequenas.
 A velocidade de produção muda com o tempo, a
produtividade não é linear.
 Você ainda acredita em técnicas de estimativa de
esforço “tradicionais”???
 Você ainda acha que desenvolvedores são como
trabalhadores “apertadores de botão”?
22