Transcript
Page 1: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 2: Ger proj 4_sofismappd_v1.0_semnsi

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

Page 3: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 4: Ger proj 4_sofismappd_v1.0_semnsi

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...”

Page 5: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 6: Ger proj 4_sofismappd_v1.0_semnsi

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”.

Page 7: Ger proj 4_sofismappd_v1.0_semnsi

Primeiro Encadeamento LógicoPlanejamento 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ãoPlanejamento detalhado precisa de → projeto do produto

detalhadoTemos queProjeto do produto detalhado no início → ciclo em

cascataEntãoPlanejamento detalhado leva a → ciclo em cascata!

Page 8: Ger proj 4_sofismappd_v1.0_semnsi

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...

Page 9: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 10: Ger proj 4_sofismappd_v1.0_semnsi

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)

Page 11: Ger proj 4_sofismappd_v1.0_semnsi

Segundo Encadeamento LógicoSoftware → bem intangível, produto não físicoSoftware → produção baseada no conhecimento, recurso

não físicoProdução baseada no conhecimento E bem intangível →

não existem medidas físicas (por definição!)Falta de medidas físicas → estimativas imprecisasJuntando com o primeiro encadeamento:Planejamento detalhado precisa de → estimativas

detalhadas Software → estimativas imprecisasEntãoNão é possível fazer estimativas precisas em software,

mesmo pagando o preço do ciclo em cascata!!!!!!!!!

Page 12: Ger proj 4_sofismappd_v1.0_semnsi

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”).

Page 13: Ger proj 4_sofismappd_v1.0_semnsi

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...

Page 14: Ger proj 4_sofismappd_v1.0_semnsi

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...

Page 15: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 16: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 17: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 18: Ger proj 4_sofismappd_v1.0_semnsi

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?”.

Page 19: Ger proj 4_sofismappd_v1.0_semnsi

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).

Page 20: Ger proj 4_sofismappd_v1.0_semnsi

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.

Page 21: Ger proj 4_sofismappd_v1.0_semnsi

Terceiro Encadeamento LógicoDo 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 imprecisasTemos que:Estimativas imprecisas → alta incerteza no processo

produtivo E tambémProdução sob encomenda → baixa incerteza no processo

produtivoEntãoNão é razoável empregar métodos que esperam baixa

incerteza no processo produtivo para construir software!!!!!!!!!

Page 22: Ger proj 4_sofismappd_v1.0_semnsi

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”?