Ger proj 4_sofismappd_v1.0_semnsi

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

description

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

Transcript of Ger proj 4_sofismappd_v1.0_semnsi

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