Ger proj 4_sofismappd_v1.0_semnsi
-
Upload
ratem -
Category
Technology
-
view
462 -
download
1
description
Transcript of 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.
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
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.
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...”
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.
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”.
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!
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...
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.
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)
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!!!!!!!!!
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”).
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...
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...
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.
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.
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.
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?”.
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).
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.
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!!!!!!!!!
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”?