[quote=marcosalex][quote=pcalcado]
Não! Eu concordei que a fábrica reduz o custo dela própria
[/quote]
Foi isso mesmo que quis dizer. Pra saber se o preço da fábrica compensa ou não, você tem de ter uma visão muito boa do escopo e do custo do trabalho. Se o cara falar que precisa de 8 horas pra fazer uma tela que seu funcionário faz em duas, não compensa. Se o cara não tem essa visão, é melhor ficar com profissional interno. No meu último trabalho uma fábrica nossa cobrou um valor por hora pra resolver um problema em um dos sitemas. Tudo bem que somos de Uberlandia - MG e o profissional viria de São Paulo, mas fomos fazer as contas do quanto ele ganharia por mês e deu 32 mil :shock: !!
[/quote]
Acho que ainda não consegui me fazer entender:
A fábrica gasta $1 ao invés de $10 por usar mão-deobra subqualificada
O cliente continua pagando $1,000.00, independente do corte de custos da fábrica
O que você falou é que estes $1,000.00 podem ser menos do que um cara interno. Sim, claro, podem. Mas a minha experiência -bem como a de outros aqui- é que durante o projeto e após este o cliente vai ter que arcar com tantos gastos extras (projeto estourou prazo e orçamento, software de manutenção difícil -toda mudança é um parto, software não atende ao que o cliente pedia, software não possui performance desejada…) que o projeto sai mais cao terceirizando para uma fábrica do que para uma consultoria que não trabalha com linha de montagem e waterfall. Ou ainda usando contractors (“PJ”) ou ainda em muitos casos fazendo dentro de casa mesmo.
O contrato precisa deixar bem claro exatamente o que você quer em tempo, escopo e qualidade e a fábrica tem de ser responsável pelo desvio. [/quote]
Tah aí um dos maiores mitos em projetos de desenvolvimento: fechar escopo, custo e prazo e buscar culpados por atrasos em projetos. Os clientes são tão culpados quanto os fornecedores pelo fracasso.
[quote=marcosalex]
Isso é complicado. O contrato precisa deixar bem claro exatamente o que você quer em tempo, escopo e qualidade e a fábrica tem de ser responsável pelo desvio. Se tiver uma brecha, certamente vai acontecer o que você falou.[/quote]
Então, Marcos. Considerando que estatísticas mostam que 50% do escopo de um projeto é descoberto durante o projeto e que waterfall é um anti-pattern será que este objetivo não é simplesmente impossível de ser alcançado na grande maioria dos casos? Ser;a que uma abordagem diferente, baseada em iterações e escopo deslizante não é mais indicada nesta maioria?
[quote=marcosalex]
Quanto à sua afirmação, é claro que precisa ter uma pessoa de dentro capacitada pra trabalhar com o terceiro, seja uma fábrica de software ou não, senão as horas vão sair cara e
…[/quote]
Não foque demais no valor-hora, porque não há termos de comparação. Ao contrário de outras áreas,
não temos tabelas que digam quanto custa um certo serviço (ou tarefa, ou artefato, ou produto): nem
em R$, nem em horas, nem em pontos de função, nem em pontos de casos de uso.
O produto não vai ter os requisitos necessários. Ponto. Nenhuma lista de supermercado vai
garantir isso, qualquer que seja o processo que você seguir. Os requisitos são sempre
elaborados em conjunto, durante o desenvolvimento, porque eles são um contraponto
da implementação, não uma condição anterior fixa e imutável.
No início do projeto, o cliente pode achar que sabe o que quer. Ele não sabe. A equipe de
desenvolvimento pode achar que entendeu o que o cliente queria naquele momento. A equipe
não entendeu. O cliente e o terceiro podem achar que sabe o que a tecnologia da informação
pode contribuir para apoiar o negócio. Nenhum dos dois sabe, nem tem como saber.
Esse conhecimento vai sendo construído durante o projeto. Negar isso é cair em armadilhas
como tentar especificar tudo o que vai ser necessário no início do projeto (engessando tudo
antes da hora), criar comitês para desestimular “mudanças” de requisitos (em vez de mudanças,
prefiro falar de ajustes), fazer contratos comerciais onde se especifica um certo número de
pontos cujo cálculo é extremamente subjetivo (certificações aparte) e chegar no atual
estado das coisas no desenvolvimento de sistemas, no qual dois terços das funcionalidades
de um sistema não são usadas em produção, o sistema fica inchado e a manutenção fica
extremamente cara (mais de dois terços do custo total de um sistema).
Minha experiência mostrou que essa máxima foi verdadeira em todos os projetos em que participei.
Paralelismo significa ruído na comunicação: quanto mais ruído, mais riscos, menor produtividade e
pior qualidade. Não há balas de prata, por mais promissoras que possam parecer certas metodologias /arquiteturas / práticas de gestão. Gerenciar bem é lidar bem com riscos, e o risco de adicionar gente
num projeto atrasado, na minha intuição, é escandalosamente alto. A única certeza é que o seu custo vai aumentar.
[quote=Jorge Diz]Gerenciar bem é lidar bem com riscos, e o risco de adicionar gente
num projeto atrasado, na minha intuição, é escandalosamente alto.[/quote]
Por isso qeu mentalidade de quem vive e planeja um projeto em fábrica é preparar o ambiente para quando tudo ir por água abaixo eles poderem entupir de novos recursos.
Essas empresas iniciam projeto HOJE com struts 1 porque vão precisar alocar pessoas novas todo mês, pois ninguém tem comprometimento e nem motivação de trbaalhar nesses lugares, sendo JR então, qualquer 2 reais hora a mais que apareça significa trocar de emprego, então eles querem algo que possa ser masi facilmente absorvido pela dezena de desenvolvedores que vão passar no projeto ao longo do tempo.
Enquanto outras empresas estão preocupadas em formar equipes multidiciplinares que se comprometam com o projeto e possam trabalhar visando entregar algo de qualidade para o cliente, essas empresas buscam vendedores de horas que não estão nem ai pro cliente, pra empresa, pro projeto, pra nada, ai vira a bola de neve que nós já estamos cansados de conhecer.
Qualidade e Fabrica de Software são duas coisas que não vi ainda caminharem juntas, talvez não seja tanto o modelo Fábrica e sim as consultorias que administram as suas fábricas pensando em $$$$$$$$$ aumentar sua margem de lucro sem investir um R$ 0,01. Trabalhei numa fábrica que não tinha nem ar condicionado!
Quando eu estava na fábrica eu estava muito insatisfeito e vi minha produtividade ir diminiuindo a cada dia que passava, prova disso que os primeiros projetos estavam estava muito bons e os meu ultimos estavam muito aquem.
Parece que o ambiente lá te desanima, use cases frustrantes, especificações frustrantes e politicas frustrantes.
Esse modelo é muito engessado te pouca liberdade, além de te forçar a trabalhar com coisas do tempo do êpa.
Que tal desenvolvimento iterativo (e incremental)?
Que tal um Product Backlog que vai tendo seus itens flutuando pra baixo e pra cima conforme a prioridade/necessidade DO CLIENTE?
Ter alguém com conhecimento do negócio do cliente e que seja comprometido com o projeto para fazer isso funcionar corretamente, que diga o que realmente importa para o cliente, já diminui drasticamente o desvio ocorrido nos projetos.
Bom, eu trabalho com metodologias ágeis há alguns anos e não lembro de ter visto em nenhum lugar com cre’dito alguém defendendo este tipo de coisa. Na verdade, dado que em metodologias ágeis se trabalha em times pequenos e multi-funcionais, seria o extremo oposto. Eu não entendo como práticas como propriedade coletiva de código, user stories entregando valor de ponta-a-ponta, integração contínua e outras poderiam funcionar num ambiente onde exista qualquer paralelismo no desenvolvimento de um sistema.
Pode explicar melhor ou dar referências?
Se o desenvolvedor já está no time provavelmente o relatório é uma user story separada e sim, ele pode ser paralelizado dentro do time se fizer sentido. Se o desenvolvedor vem de fora então seu exemplo está explicado no livro do Fred Brooks, já citado:
Recomendo fortemente a leitura deste livro.
Quanto ao MVC, eu ainda não entendi como ele se encaixa nisso tudo. MVC é apenas uma forma de dizer como 3 componentes de uma aplicação se comunicam, não vejo o impacto na metodologia em usar ou não.
As ferramentas (e, principalmente, as metodologias) de gerenciamento de projeto fazem isso há anos e não resolveram os problemas. A questão é simples, creio: não adianta tentar controlar o incrontrolável. Há mais de duas décadas que se tenta isso com falhas miseráveis todos os anos (vide CHAOS reports).
Mas acredito que você está convergindo para o iterativo incremental, talvez eventualmente ágil. O grande problema é que iterativo e incremental não combina com linha de montagem, onde um time alimenta o outro. Neste modelo não há o tempo e a cerimônia do waterfall, os ciclos e iterações devem ser curtos e você não precisa se preocupar em entregar uma especificação 100% ok para o próximo da fila (analista -> proramador -> testes, etc) porque o que você vai desenvolver é só o necessário para aquela iteração.
Mas modelo iterativo e incremental (com todas as suas variações) é para desenvolvimento de software.
O que eu discordo é que (1)numa fábrica isso funciona e que (2)por serem atividades diferentes você pode adicionar pessoas num time para paralelizar tarefas livremente.
Bom, MVC não é sobre Camadas, mas ainda que fosse não é porque você tem Camadas diferentes que elas podem ser desenvolvidas por pessoas diferentes. O nível de acoplamento entre Camadas é grande demais, talvez você esteja se referindo à Componentes, que possuem contratos e interfaces bem-definidas.
Eu entendo seu ponto mas para mim isso é equivalente a dizer que alguém vai do Rio à São Paulo andando, mas vai de Nike. Por que não pegar um avião (cuja passagem custa menos que o tênis) em primeiro lugar?
Nada funciona em tudo mas a coisa não é como você falou. De qualquer forma, metdologias iterativas e incrementais, especialmente metodologias ágeis, possuem “gerenciamento constante” e baselines. Na verdade elas costumam ser bem rígidas com relação à como o processo é gerido.
O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido -ela, na verdade, foi criada para ser ineficiente e barata.
Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações. Existe um impacto muito grande em tirar ou colocar uma pessoa de um projeto, mesmo metodologias ágeis que pregam pair programming como XP tratam isso com extrema cautela e eu nunca vi ninguém recomendando -nem eu recomendo- colocar pessoas em projetos atrasados. Dificilmente o projeto está atrasado por falta de pessoal, geralmente o problema é mais embaixo, e se for por falta de essoal até estes se tornarem produtivos vai demandar muito tempo/custo.
E não confunda com “o mesmo analista do início ao fim”, estamos conversando sobre a sua discórdia com Fred Brooks sobre acrescentar pessoas em projetos atrasados:
[quote=marcosalex]
Depende do projeto e da alocação. Em algumas vezes sim, mas se existe capacidade de paralelismo ela pode ser explorada. Com projetos baseados em MVC e utilizando metodologias ágeis, muitos desses pontos são fáceis de identificar, mas a pessoa tem de saber gerenciar. Mais um motivo pra ter alguém de dentro pra acompanhar os terceiros (fábrica ou não).[/quote]
Novamente eu recomendo a leitura do livro.
Eu não me lembro de ter falado em nenhum lugar ensta thread sobre não haver acompanhamento ou erenciamento. A analogia foi apenas para tentar mostrar que comprar uma ferramenta bonita e cara (o tênis ou uma ferramenta de gestão de projeto) não adianta.
Como eu já repeti aqui nesta thread algumas vezes isso de “avisar a diretoria” nunca acontece.
Primeiro porque o gerente confunde progresso com execução de tarefas e tenta medir o que não é mensurável. Se 90% das tarefas estão 90% concluídas então o projeto está quase que 90% concluído? Não. Gerenciamento de projeto de software não é matemática de primeiro grau, não adianta somar, dividir e multiplicar. Os 10% restantes podem ocupar 99% do tempo total do projeto e ninguém previu isso. No final o projeto chega no deadline em sei-lá-quantos-% pronto. 90% pronto não é pronto.
O outro problema é que ao primeiro sinal -sempre tarde demais- de que o projeto vai atrasar os gerentes de uma fábrica vão apertar seus funcionários para que trabalhem mais. Horas extras, sábados, feriados, baixar a qualidade do software… tudo o que for preciso para entregar. Entregar qualquer coisa, mas entregar algo.
Uma abordagem baseada em iterações possibilita prever o risco e traçar uma estratégia eficiente, porque se baseia em dados reais. Nossa velocidade é 5, temos duas iterações para acabar o projeto e 25 pontos. (1) Marque uma reunião com o cliente para priorizar quais dos 25 pontos restantes devem entrar nas duas últimas iterações (2) procure coisas simples que podem aumentar a velocidade e (3)em vez de um software 90% funcionando você entrega um software 100% funcionado com 90% do escopo implementado. Precisamos terminar? Bom, se a velocidade se mantiver precisamos de mais 3 iterações.
A coisa não é não gerenciar ou não acompanhar mas sim parar de seguir um anti-pattern chamado waterfall. Cronogramas completos, acompanhamento tarefa-a-tarefa… nada disso tem funcionado desde a época de Fred Brooks.
[quote=marcosalex]
[quote=pcalcado]
O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido - ela, na verdade, foi criada para ser ineficiente e barata.[/quote]
Opinião não discuto :lol: [/quote]
Engraçado, eu citei aqui alguns trabalhos -Mythical Man-month, CHAOS Report- estatísticos e acadêmicos. Será que é somente minha opinião?
E como adendo sobre componentes:
Comonentes podem tecnicamente ser implementados por times diferentes. Muitas vezes funciona. o problema é que para Componentes de Negócio isso é um mito. Novamente: é tecnicamente viável (assim como é viável fazer o mesmo sem componentes ou mesmo Camadas) mas qualquer caso de uso vai envolver mais de um componente e separar o mesmo caso de uso por pessoas distintas não é uma boa idéia.
