http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net http://www.guj.com.br/posts/preList/59536/312800.java http://www.guj.com.br/posts/preList/59536/312800.java GMT
Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).

Pelo que entendo é assim que se trabalha hoje.

[]´s]]> http://www.guj.com.br/posts/preList/59536/312805.java http://www.guj.com.br/posts/preList/59536/312805.java GMT http://www.guj.com.br/posts/preList/59536/312812.java http://www.guj.com.br/posts/preList/59536/312812.java GMT
Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).

Pelo que entendo é assim que se trabalha hoje.

[]´s[/quote]

E na sua opinião, isso é bom?
]]> http://www.guj.com.br/posts/preList/59536/312817.java http://www.guj.com.br/posts/preList/59536/312817.java GMT Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?]]> http://www.guj.com.br/posts/preList/59536/312829.java http://www.guj.com.br/posts/preList/59536/312829.java GMT Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?[/quote]
Que tal [url=http://agilemanifesto.org]abordagens ágeis[/url]? (XP, FDD etc)]]> http://www.guj.com.br/posts/preList/59536/312846.java http://www.guj.com.br/posts/preList/59536/312846.java GMT [quote=s4nchez][quote=furutani][quote=s4nchez]...[/quote]
Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?[/quote]
Que tal [url=http://agilemanifesto.org]abordagens ágeis[/url]? (XP, FDD etc)[/quote]
desculpa mas eu não compreendi bem... O fato de usar uma abordagem agil exclui a fabrica de SW?Ou seja é uma coisa ou outra?
Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).]]> http://www.guj.com.br/posts/preList/59536/312859.java http://www.guj.com.br/posts/preList/59536/312859.java GMT
[quote=furutani]Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).[/quote]

Eu também. Deve ter alguma que use mas eu não conheço nenhuma. Pelo contrário, conheço algumas que se esforçam para conseguir CMM e são extremamente burocratizadas.

[]s
Luca]]> http://www.guj.com.br/posts/preList/59536/312866.java http://www.guj.com.br/posts/preList/59536/312866.java GMT por que?
o que é uma fabrica?
se ajusta a fabrica para uma especificação
depois se adiciona materia prima
e do outro lado saem um monte de coisas exatamente iguais

a coisa mais parecida em software com uma fabrica é uma prensa de CDs/DVDs onde se desenvolve o software/especificação
e depois se prensa um monte de CDs iguais

eles querem que em uma fabrica de software fabrique as espeficicações, mas não é isto que uma fabrica faz, isto é o que o setor criativo da empresa faz ...

por tanto, é impossivel existir uma fabrica de software ...

por isto, todos os que ja trabalharam em uma tem pavor do termo fabrica de software, e todos os clientes que ja compraram de uma fabrica de software estão penando e pagando manutenção até hoje para que algum dia o software faça o que eles querem ...

por que existem as tais?
bom, é um ótimo negócio para consultorias que não se importam com o produto final, e se elas seguirem direitinho a definição de o que o cliente foi convencido que queria, então irão conseguir depois convencer o cliente que é culpa dele que o negocio não funciona/não faz o que o cliente precisa ...


mas isto pode também ser só motivado por algumas péssimas experiências, pode ser que alguem tenha feito estes dois conceitos completamente diferentes funcionarem juntos

IMNSHO => In my not so humble opinion]]> http://www.guj.com.br/posts/preList/59536/312869.java http://www.guj.com.br/posts/preList/59536/312869.java GMT
Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.

A metodologia que foi utilizada foi o [url=http://en.wikipedia.org/wiki/Scrum_%28development%29]scrum[/url].

Só que após os sistemas ficarem prontos, foi criada uma fábrica para dar manutenção, etc... aí (creio eu) para manter o querido CMMI 5, foram introduzidos novos processos.

O que posso dizer é que já ví, vivi e ouvi falar de muitas fábricas de software, mas sem nenhuma queixa quanto a qualidade... acho que isso não astá atrelado ao conceito e sim á empresa.

[]´s]]> http://www.guj.com.br/posts/preList/59536/312872.java http://www.guj.com.br/posts/preList/59536/312872.java GMT
Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).

Pelo que entendo é assim que se trabalha hoje.

[]´s[/quote]

E na sua opinião, isso é bom?
[/quote]

E respondendo:

Pelo menos as experiências que tive, no geral foram boas.

[]´s]]> http://www.guj.com.br/posts/preList/59536/312874.java http://www.guj.com.br/posts/preList/59536/312874.java GMT
O pessoal confundia fábrica de software com pastelaria! Uma tristeza...
Achavam que programar era como fritar pastel(sempre o mesmo processo), e que era só pedir e rapidinho estava pronto!

O grande problema das fábricas de software hoje, na minha opinião, é que elas viraram quintal dos "países desenvolvidos". Por a mão de obra aqui(e na India) ser mais barata, eles mandam as especificações pra cá, e exigem de volta um software de qualidade! Ateh ai, poderia funcionar se:

-as especificações enviadas não fossem uma porcaria
-o tempo não fosse pouco pra executar as tarefas
-o salário pago aqui não fosse tão baixo
-a qualificação dos profissionais não fossem uma porcaria(normalmente as equipes tem 3,4 caras bons e 20 caras ruins digitadores)
-o processo não fosse tão burrocratizado]]> http://www.guj.com.br/posts/preList/59536/312881.java http://www.guj.com.br/posts/preList/59536/312881.java GMT
Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.

A metodologia que foi utilizada foi o [url=http://en.wikipedia.org/wiki/Scrum_%28development%29]scrum[/url].

Só que após os sistemas ficarem prontos, foi criada uma fábrica para dar manutenção, etc... aí (creio eu) para manter o querido CMMI 5, foram introduzidos novos processos.

O que posso dizer é que já ví, vivi e ouvi falar de muitas fábricas de software, mas sem nenhuma queixa quanto a qualidade... acho que isso não astá atrelado ao conceito e sim á empresa.

[]´s[/quote]

Conseguiram medir a qualidade? Quão bom foi o projeto? Tem números?

Lembre-se que no nível 5 vc já definiu, implementou e institucionalizou métricas... ]]> http://www.guj.com.br/posts/preList/59536/312883.java http://www.guj.com.br/posts/preList/59536/312883.java GMT [quote=s4nchez]
Que tal [url=http://agilemanifesto.org]abordagens ágeis[/url]? (XP, FDD etc)[/quote]
desculpa mas eu não compreendi bem... O fato de usar uma abordagem agil exclui a fabrica de SW?Ou seja é uma coisa ou outra?
Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).[/quote]

Daí depende do seu conceito de fábrica de software. Se considerarmos apenas o produto final (software), qualquer empresa que desenvolve pode ser chamada de fábrica de software.

Agora, se levarmos em consideração a maneira de se fazer as coisas, o que eu compreendo por fábrica de software é na grande maioria dos casos desenvolvimento em cascata acompanhado de modelos de qualidade. Ambos são necessários para se criar um conceito de "linha de produção" que ao meu ver não tem a ver com software.

Ou seja, ao meu ver fábrica de software e desenvolvimento ágil podem até não serem conceitos mutuamente exclusivos, mas são bastante diferentes.]]> http://www.guj.com.br/posts/preList/59536/312956.java http://www.guj.com.br/posts/preList/59536/312956.java GMT
Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.

A metodologia que foi utilizada foi o [url=http://en.wikipedia.org/wiki/Scrum_%28development%29]scrum[/url].
[/quote]

E como funcionava esta Fábrica de Software Ágil?]]> http://www.guj.com.br/posts/preList/59536/312957.java http://www.guj.com.br/posts/preList/59536/312957.java GMT
A consultoria que eu trabalhava tinha a certificação de qualidade CMMI 5, não especificamente a fábrica que trabalhei.

Quando disse que novos processos foram encorporados à fabrica, não foi porque aquela fábrica em sí estaria se adaptando para aquela certificação, até porque era uma fábrica alocada, mas sim porque existem processos que realmente precisam ser padronizados.

Quanto ao bom funcionamento da fábrica com scrum, creio que o ponto mais marcante eram as reuniões matinais para da um feedback a todos sobre as atividades de cada um no sistema. Existiam os testes unitários, etc..

Note que o scrum foi utilizado no desenvolvimento dos sitemas, após virar um fábrica, perderam-se algumas características, mas muitas permaneceram. Digamos que houve uma adaptação.

Quanto a números fica um pouco complicado de expor, que tipo de informação gostaria de saber ?

[]´s]]> http://www.guj.com.br/posts/preList/59536/312971.java http://www.guj.com.br/posts/preList/59536/312971.java GMT ]]> http://www.guj.com.br/posts/preList/59536/312988.java http://www.guj.com.br/posts/preList/59536/312988.java GMT Antes tinham as chamadas softwarehouse, que desenvolviam projetos sob encomenda dos clientes. e o que temos agora? Depois voltamos para a alocação direto no cliente, o desenvolvimento interno de produtos, onde os profissionais eram alocados para projetos de 6 meses (geralmente era mais, já fiquei 2 anos num cliente). A fábricas de software que fazem softwares ou serviços sobre encomenda. Já viram isso?
A verdade é que o mundo de TI ainda não achou a melhor forma de se desenvolver software. Talvez nem exista, mas a verdade, é que vão tentando. E se as fábricas não morrerem num futuro próximo e a maioria voltar a trabalhar diretamente para o cliente (como empregado mesmo), eu corto minhas partes íntimas fora (para não ser chulo). Offshore está ficando caro, e os diretores das empresas, mais uma vez, vão ganhar fortunas inventando um jeito novo de software. Quem viver, verá.
Mas nada muito novo, porque no mundo tudo se copia.
[]'s ]]> http://www.guj.com.br/posts/preList/59536/312995.java http://www.guj.com.br/posts/preList/59536/312995.java GMT Que de nada adianta saber um pouquinho de tudo, e sim, tudo de um pouquinho... isso se chama foco no negócio!
As fábricas, softhouses e afins como disse o Ludhi, tem tudo para virarem fumaça logo, logo!
Tá na hora dessas empresas focarem mais em um negócio específico e desenvolverem ao máximo!!! Nisso ganharão qualidade.

Então, resumindo é ter FOCO!!!

]]> http://www.guj.com.br/posts/preList/59536/313114.java http://www.guj.com.br/posts/preList/59536/313114.java GMT Que de nada adianta saber um pouquinho de tudo, e sim, tudo de um pouquinho... isso se chama foco no negócio!
As fábricas, softhouses e afins como disse o Ludhi, tem tudo para virarem fumaça logo, logo!
Tá na hora dessas empresas focarem mais em um negócio específico e desenvolverem ao máximo!!! Nisso ganharão qualidade.

Então, resumindo é ter FOCO!!!

[/quote]
Alguém duvida disso?
E digo mais, daqui a pouco aparece uma outra onda, Ruby ou outra... Aí toda a molecada vai programar nisso, e vai faltar gente em java (sempre faltou, aliás). Aí os salários dão um boom. Já tomei a decisão na vida de não largar mais a área técnica. Por ver o que acontece com os cobolzeiros.
[complementando]
Ser especialista dá trabalho, mas essa semana fiquei sabendo de um cara que conhece uma tecnologia especifica de netweaver que está ganhando...
bem... 50k por mês PJ!!!!!!! Assim eu trabalho com PJ!!!!
[/complementando]]]> http://www.guj.com.br/posts/preList/59536/313136.java http://www.guj.com.br/posts/preList/59536/313136.java GMT
Fábrica != Software em caixinha.

Sinceramente não acedito que fabricas vão acabar, pois muitas delas existem especificamente para atender um nicho de clientes, para suprir suas necessidades e oferecer novos protutos interessantes a eles.

Existem sim "fábricas genéricas", mas pelo menos eu, nunca participei de nenhuma.

Ao criar uma fábrica para atender um cliente, a empresa está, justamente, focando.

[]´s]]> http://www.guj.com.br/posts/preList/59536/313161.java http://www.guj.com.br/posts/preList/59536/313161.java GMT
Fábrica != Software em caixinha.

Sinceramente não acedito que fabricas vão acabar, pois muitas delas existem especificamente para atender um nicho de clientes, para suprir suas necessidades e oferecer novos protutos interessantes a eles.

Existem sim "fábricas genéricas", mas pelo menos eu, nunca participei de nenhuma.

Ao criar uma fábrica para atender um cliente, a empresa está, justamente, focando.

[]´s[/quote]

Não vi ninguém dizer que Fábrica de Software == Software de Caixinha (a fábrica é o meio, não o fim).

Gostaria de entender o que significa "criar uma fábrica" pra você.

]]> http://www.guj.com.br/posts/preList/59536/313188.java http://www.guj.com.br/posts/preList/59536/313188.java GMT
Dado o crescente interesse de IBM, MSFT e outras consultorias mainstream (as brasileiras de trs letrinhas só sabem seguir o que as estrangeiras de três letrinhas fazem, e mesmo assim alguns anos depois) pelo modelo ágil acho que a resposta quanto ao futuro é bem clara.]]> http://www.guj.com.br/posts/preList/59536/313518.java http://www.guj.com.br/posts/preList/59536/313518.java GMT ...
Dado o crescente interesse de IBM, MSFT e outras consultorias mainstream (as brasileiras de trs letrinhas só sabem seguir o que as estrangeiras de três letrinhas fazem
...
[/quote]

MSFT tem 4 letrinhas

Interessante a idéia de Fábrica de Software. Mal posso imaginar o pessoal de controle de qualidade olhando para as classes da tua aplicação que rolam por uma esteira e recolhendo as classes defeituosas. Logo a frente uma máquina empacota as classes e carimbam-nas com data de validade.

<desabafo>Por que será que administradores frustrados vêm reinventar justamente em TI práticas fracassadas em outras indústrias?</desabafo>]]> http://www.guj.com.br/posts/preList/59536/314087.java http://www.guj.com.br/posts/preList/59536/314087.java GMT MSFT tem 4 letrinhas
[/quote]

Eu não falei que tinha 3 letras, falei que as empresas seguem gringas de 3 letras


De qualquer form, ter 3 letras é mais filosofia do que sigla mas não, a MSFT não faz parte deste time. Seus problemas são outros.]]> http://www.guj.com.br/posts/preList/59536/314345.java http://www.guj.com.br/posts/preList/59536/314345.java GMT
http://www.guj.com.br/posts/list/11359.java

]]> http://www.guj.com.br/posts/preList/59536/314350.java http://www.guj.com.br/posts/preList/59536/314350.java GMT
Quando fui trabalhar na minha primeira fabrica, eu pensei: "professor fdp, só falava merda e ainda peguei uma DP dele rsrs".



]]> http://www.guj.com.br/posts/preList/59536/314375.java http://www.guj.com.br/posts/preList/59536/314375.java GMT
http://www.guj.com.br/posts/list/11359.java

[/quote]

Eh, em 2004 já falavam nisso...

Errar é humano, persistir no erro é burrice. ]]> http://www.guj.com.br/posts/preList/59536/314648.java http://www.guj.com.br/posts/preList/59536/314648.java GMT
Veja só: um entrevistador - e também sócio - me disse, como resposta ao meu questionamento sobre o motivo de não utilizarem metodologias ágeis na empresa em questão: "é que pra usar metodologias como XP tu precisa de uma equipe [b]boa[/b]".

Tremendo incentivo pra trabalhar lá, né?! ]]> http://www.guj.com.br/posts/preList/59536/314660.java http://www.guj.com.br/posts/preList/59536/314660.java GMT Eu não falei que tinha 3 letras, falei que as empresas seguem gringas de 3 letras


De qualquer form, ter 3 letras é mais filosofia do que sigla mas não, a MSFT não faz parte deste time. Seus problemas são outros.[/quote]

Já havia entendido, estava apenas brincando. ]]> http://www.guj.com.br/posts/preList/59536/315433.java http://www.guj.com.br/posts/preList/59536/315433.java GMT ]]> http://www.guj.com.br/posts/preList/59536/320563.java http://www.guj.com.br/posts/preList/59536/320563.java GMT [/quote]

Cara, desculpa mas sou obrigado a discordar da sua opinião. Mas antes de mais nada, tbm sou contra fábricas de software...

É claro que é possível se obter métricas aproximadas de quanto tempo vai levar o projeto. Senão tbm vira um circo neh, imagina vc chegar pro seu cliente e falar "ó...não sei quando vou terminar, quando acabar eu te entrego o software"...acho q seria inviável isso...

O grande problema das fábricas de software é que elas mesmo ignoram as métricas que elas fazem e falam pro cliente que vão fazer em um tempo muito menor pra conseguir vender o projeto....se eles fazem a métrica e dá que vai levar 1 ano, eles falam pro cliente que leva 6 meses...

Mas uma métrica e um planejamento bem feito e bem seguido é muito eficiente! Mesmo pq leva em conta riscos como funcionário sair, ficar doente, o projeto dar uma travada e etc...

e o CMMi não diz que desenvolver é um processo exato. Ele só intrefere no controle do projeto. Não que eu goste do CMMi, muito pelo contrário. Mas uma coisa é certa, empresa nenhuma usa ele adequadamente, a que eu trabalhava pagou pra tirar...

]]> http://www.guj.com.br/posts/preList/59536/320608.java http://www.guj.com.br/posts/preList/59536/320608.java GMT
Também tive uma experiência positiva com o Scrum, projeto que eu participei fora conduzido sob tal regime e acho realmente que tem muito mais haver com nossas necessidades, cultura e ter previsibilidade sob o Caos , como o Scrum prega , é praticamente impossível.

Agora, pior que o termo Fábrica de Software, somente BODYSHOP ... affff açougue puro .. ]]> http://www.guj.com.br/posts/preList/59536/320866.java http://www.guj.com.br/posts/preList/59536/320866.java GMT
Sim, existem metricas, mas esse "nao sei quando vou terminar, quando acabar te entrego o software" nao eh exatamente o que as metodologias ageis promovem, com o porem muito importante que as "entregas" sao semanais ou quinzenais?]]> http://www.guj.com.br/posts/preList/59536/320900.java http://www.guj.com.br/posts/preList/59536/320900.java GMT
Sim, existem metricas, mas esse "nao sei quando vou terminar, quando acabar te entrego o software" nao eh exatamente o que as metodologias ageis promovem, com o porem muito importante que as "entregas" sao semanais ou quinzenais?[/quote]

ah sim, mas esse porem é muito importante mesmo! As entregas são feitas semanalmente ou quinzenalmente...ai é ótimo!!!

Quando expressei minha opinião, estava me referindo ao modelo tradicional de desenvolvimento de software, onde se entrega tudo de uma vez só para o cliente no final. Daí eu acho inviável vc não dar um prazo pro cliente...

com metodologias ageis, o cliente acompanha o andamento do desenvolvimento, ai não vejo muito problema!]]> http://www.guj.com.br/posts/preList/59536/320957.java http://www.guj.com.br/posts/preList/59536/320957.java GMT
1 ano depois do falecimento dos posts nesse tópico, queria saber a opinião hoje de vcs sobre como anda o mercado de desenvolvimento?

Estou meio assutado ainda vendo empresas que estão se moldando agora, novas, procurando uma maneira de trabalho de "Fabrica de Software", vejo amigos comentando que suas empresas querer ter 90% do corpo de JR e estagiários, que iniciam projetos HOJE com Struts 1, porque o mercado conhece e como a rotatividade é alta qualquer um pode chegar e mandar bala.
Isso tem fundo de verdade? tem, mas essas empresas não querem pessoas, querem números, afinal onde se é um pessoa que faz parte de um time, eu acredito que a rotatividade não seja grande, onde se é apenas mais um "recurso", tanto faz quem é vc e se vc quer ficar ou não.

Eu estou meio por fora de como as coisas estão rumando no mercado e o modelo de fábrica (consultorias de 3 letrinhas by Shoes) realmente esta forte e crescendo ou realmente tem algo errado com essas empresas?

[]'s


]]> http://www.guj.com.br/posts/preList/59536/514160.java http://www.guj.com.br/posts/preList/59536/514160.java GMT
Eu estou meio por fora de como as coisas estão rumando no mercado e o modelo de fábrica (consultorias de 3 letrinhas by Shoes) realmente esta forte e crescendo ou realmente tem algo errado com essas empresas?

[]'s


[/quote]

Eu vejo que a tendência é só aumentar a adoção desse tipo de modelo. E digo mais, como a mão de obra é beeeeeem mais barata em outros estados, todo trabalho de "desenvolvimento" sairá dos grandes centros. Falo isso porque isso é que acontece na atual empresa que trabalho. Grande parte dos projetos que começaram a ser desenvolvidos aqui em São Paulo, foram todos pra Bahia, e qual a justificativa? Custo com a mão de obra. Enquanto um sênior aqui em São Paulo rala pra ganhar seus R$6.000,00, R$7.000,00, lá na Bahia eles encontrar gente que se sujeita a ganhar de 1/3 e metade do que se ganha aqui em São Paulo.]]> http://www.guj.com.br/posts/preList/59536/514252.java http://www.guj.com.br/posts/preList/59536/514252.java GMT
]]> http://www.guj.com.br/posts/preList/59536/514291.java http://www.guj.com.br/posts/preList/59536/514291.java GMT
HSBC como cliente da fábrica:

Trabalhei alguns anos com sistemas de RH do HSBC, depois de uns 2 anos que eu estava na empresa, recebemos a triste noticia que o banco tinha tomado a decisão de impedir que todo o analista de sistemas do banco desenvolve-se ou desse manutenção em sistemas, teriamos o perfil de gerentes de projeto. Foi implantada uma metodologia monstruosa para construir foguetes e tivemos que engolir toda aquela baboseira. Todos os nossos sistemas seriam desenvolvidos nas fabricas de software das consultorias 3 letrinhas.

Foi o primeiro ano a metodologia não era nada agradavel, nada aplicavel a projetos médios e pequenos por causa das fases dessa metodologia nós trabalhamos com sobreposição de fases, nosso clientes as areas business ficavam responsaveis por solicitar em Use Case depois suplementado pela consultoria e aprovado por nós do TI eram de péssima qualidade pra não dizer terrivelmente ruim!, pequenas alterações que faziamos em uma semana isso com uma boa documentação e teste passaram a ter quase dois meses, pois o tempo de build da fábrica e absurdamente ridiculo!

Eu lembro muito bem dos valores um sistema de interface entre aplicativo estava orçado em 85 mil reais, sem brincadeira aquela interface entre eu montaria em um mês tranquilamente(Lá eu montei duzias), manutenções e módulos que para nossa equipe eram faceis custavam bagatelas de 50 mil reais(uma semana duas semanas de desenvolvimento pela nossa equipe) e tivemos projetos de 500 mil, 300 mil e por ai vai.

Os programas desenvolvidos pela fábrica levavam o dobro ou triplo do tempo e quando chegavam se já sabe, eram de uma qualidade péssima, parece que o pessoal analista de sistemas da consultoria não tinha feito nada! Os programas com problema de testes de tela foco, validação e na maioria das vezes totalmente fora da necessidade do usuário.

Depois de muito stress em dois anos a fabrica foi sendo deixada de lado e começou a voltar o desenvolvimento um bom para nossa equipe. Hoje a fabrica é utilizada com muita moderação e não vem sendo util até no nesse ano quando falei com um ex-colega.]]> http://www.guj.com.br/posts/preList/59536/514298.java http://www.guj.com.br/posts/preList/59536/514298.java GMT
[quote=TheMask]<desabafo>Por que será que administradores frustrados vêm reinventar justamente em TI práticas fracassadas em outras indústrias?</desabafo>[/quote]

As práticas de outras indústrias não são fracassadas. Elas simplesmente funcionam lá, e talvez em alguma outra indústria de outro ramo.

Mas em TI não funcionam.

Desenvolver um software:
-não é como construir um prédio
-não é como montar um carro numa linha de montagem
-não é equivalente a processo algum do mundo físico

Parafraseando Fred Brooks
[quote]Uma mulher pode gerar um filho em nove meses, mas nove mulheres não podem gerar um em um mês.[/quote]
Isso quer dizer que você pode até colocar o dobro de peões para cavar um buraco na metade do tempo, mas não adianta alocar o dobro de programadores em um projeto para tê-lo feito na metade do tempo. Dependendo da hora, vai até atrasar mais o projeto.

Eis a simples diferença entre um trabalho físico, perfeitamente particionável, de um totalmente interligado, um trabalho intelectual.

Eis por quê práticas e gerenciamento provenientes de outras indústrias não funcionam.]]> http://www.guj.com.br/posts/preList/59536/514333.java http://www.guj.com.br/posts/preList/59536/514333.java GMT
disse tudo...
não consigo visualizar uma fábrica de software utilizando uma metodologia ágil...seja lah qual for..
já trabalhei em 2 fábricas de software, e nelas eu apreendi de tudo...tudo o que NÃO
deve ser feito no desenvolvimento de software. Na minha opnião, desenvolvimento de software é um processo criativo e que valoriza principalmente as pessoas... e uma fábrica de software é o contrário disso. Uma fabrica vende horas .... como se fosse um "commodity".

nas fábricas onde trabalhei, o trabalho poderia ser feito na metade do tempo, com a metade
de pessoas... mas isso numa fábrica não tem a menor importância, o importante é faturar !!!

Sinceramente, acho que as empresas (onde se incluem também as consultorias de 3 letrinhas) que só visam o curto prazo e lucro imediato, estão fardadas a desaparecer.

]]> http://www.guj.com.br/posts/preList/59536/514353.java http://www.guj.com.br/posts/preList/59536/514353.java GMT
Vc ainda ta na Fabrica da Dts?

[quote]Sinceramente, acho que as empresas (onde se incluem também as consultorias de 3 letrinhas) que só visam o curto prazo e lucro imediato, estão fardadas a desaparecer. [/quote]

Concordo plenamente as empresas que começaram com essa história de utilizar fábrica de software há algum tempo, parece que estão acordando e vem pressionando as 3 letrinhas.

]]> http://www.guj.com.br/posts/preList/59536/514366.java http://www.guj.com.br/posts/preList/59536/514366.java GMT
Trocentos estagiários e jr para fazer um subsistema minúsculo que poderia ser feito por um único cara razoavelmente experiente... Ae vc inclui que boa parte dos analistas (salvo raras excessões) que não tem nem idéia do que estão fazendo... Já viu né... Depois tenho que ficar consertando (REFAZENDO) a merda malfeita... fazer o q...


Ah e sem falar que toda vez q meu gerente fala: "dá pra vc resolver aquele probleminha lá?" pode crer que o dia que eu ia perder fazendo isso já virou 3 meses... ]]> http://www.guj.com.br/posts/preList/59536/514439.java http://www.guj.com.br/posts/preList/59536/514439.java GMT ]]> http://www.guj.com.br/posts/preList/59536/514468.java http://www.guj.com.br/posts/preList/59536/514468.java GMT

Economizar no profissional é aumentar seu prejuízo.
]]> http://www.guj.com.br/posts/preList/59536/514480.java http://www.guj.com.br/posts/preList/59536/514480.java GMT
Eu nunca trabalhei em uma fabrica de SW ou d qq outra coisa mas minha opinião é a seguinte:
Cada vez mais eu acho que um software deve ser desenvolvido por pequenas equipes de no maximo 7 pessoas. Acho que equipes de 5 pessoas sao ideais. Mas dependendo do tamanho sistema, se for mto grande, axo que dividir em partes e formar pequenas equipes pra cada módulo é uma boa prática... é claro utilizando como argamassa uma arquitetura bem definida para colar todos as partes no final! É possivel? Ou apenas utopia? Se eu fosse gerente de um grande projeto axo q eu tentaria esse tipo de abordagem!!! oq vcs acham?]]> http://www.guj.com.br/posts/preList/59536/514525.java http://www.guj.com.br/posts/preList/59536/514525.java GMT
Eu nunca trabalhei em uma fabrica de SW ou d qq outra coisa mas minha opinião é a seguinte:
Cada vez mais eu acho que um software deve ser desenvolvido por pequenas equipes de no maximo 7 pessoas. Acho que equipes de 5 pessoas sao ideais. Mas dependendo do tamanho sistema, se for mto grande, axo que dividir em partes e formar pequenas equipes pra cada módulo é uma boa prática... é claro utilizando como argamassa uma arquitetura bem definida para colar todos as partes no final! É possivel? Ou apenas utopia? Se eu fosse gerente de um grande projeto axo q eu tentaria esse tipo de abordagem!!! oq vcs acham?[/quote]

O que você pensa não está errado, o problema, como foi falado é que os manda-chuva não pensam.

Eles acham que aumentar o tamanho da equipe faz as cosias andar mais depressa: mentira. Faz andar mais devagar.
Mais pessoas significa mais comunicação, mais controle. Isso significa menos tempo codificando. Aqui entre o Pair Programming onde a rotatividade dos pares aumenta a comunicação e o controle sem sacrificar o tempo de codificação.

Quem paga não entende o que compra. Isso faz com que se pense que terceirizar e pagar N dezenas milhares é melhor que ter uma equipa interna pagando N milhares. Mas isso acontece porque eles não estão comprando o software. Eles estão comprando a responsabilidade. Se o software der problema eles executam a empresa que o fez.

Um lugar onde de faz algo é uma fábrica. O termo Fábrica de Software não deve ser prejurativo, porque as pessoas não sabem outro nome da "empresa que produz software"
Acontece que o erro é esse: o que a empresa produz não é o software. produzir software não significa criar um bem, significa criar um serviço. Criar um software é como treinar pessoas, ninguém fala em "fabrica de pessoas treinadas".

É o foco que está errado. E com ele toda a nomenclatura e confusão que se cria dai.

Mas, sim, criar um software passa por criar uma "coisa", mas essa "coisa" é apenas uma ferramenta. Imagine-se no circo. No Canhão Humano as pessoas pagam pelo quê ? por ver um canhão disparar ? Não, por assistir a coragem do cara lá dentro.
Ninguém paga para ver a qualidade das cartas do ilusionista, paga para ser maravilhado pelo que ele faz com elas.
E quem cria esses engenhos ? Alguem cria, tem uma engenharia , um saber, uma tecnologia associada. Existem fábricas onde se fabricam essas coisas.

Construção de software é mais ou menos como isso. Alguem cria o software, mas não é isso que se está vendendo. Ou pelo menos não deveria ser. Quando se fala de equipe, scrum, XP, java, .net , etc.. estamos no nivel do cara que fabrica as cartas que os ilusionistas usam. [url=http://sergiotaborda.wordpress.com/a-arte-de-fabricar-software/]Software é muitos mais que isso[/url].


]]> http://www.guj.com.br/posts/preList/59536/514607.java http://www.guj.com.br/posts/preList/59536/514607.java GMT
Nesse sentido de construcao de produtos de software um grande exemplo de fabrica de sw é a fundacao apache.]]> http://www.guj.com.br/posts/preList/59536/514725.java http://www.guj.com.br/posts/preList/59536/514725.java GMT [/quote]

[b]Luiz[/b], enquanto no Brasil for comum as pessoas [b]levarem um por fora[/b] esse tipo de prática vai ser comum, se é que você me entende, acontece a mesma coisa na política, na administração pública, etc.. ]]> http://www.guj.com.br/posts/preList/59536/514745.java http://www.guj.com.br/posts/preList/59536/514745.java GMT Nesse sentido de construcao de produtos de software um grande exemplo de fabrica de sw é a fundacao apache.[/quote]

ótimo exemplo. A fundação apache ( ou a fundação eclipse já agora) é uma fabrica de software ? Eu diria que sim. Mas gostaria de saber o que acha quem diz que "fabrica de software" [i]non ecsisté[/i] ou não deveria existir...]]> http://www.guj.com.br/posts/preList/59536/514776.java http://www.guj.com.br/posts/preList/59536/514776.java GMT
Os projetos dela não nascem pela demanda de um cliente, e sim de uma necessidade coletiva do mundo.]]> http://www.guj.com.br/posts/preList/59536/514778.java http://www.guj.com.br/posts/preList/59536/514778.java GMT
Às vezes, tenho a impressão de que o pessoal culpa as consutorias de três letrinhas ao mesmo tempo em que coloca o cliente como vítima. Será que é isso mesmo? Eu vejo podridão nos dois lados. Tanto o cliente quanto a consultoria são culpados nessa história.

Exemplo: normalmente, o cliente, de cara, não tem uma TI organizada, que é vista mais como um sangue-suga de dinheiro, reativa, e que não busca inovações. Com isso, o cliente, pra resolver seu problema, ao invés de arrumar a casa, vai lá e terceiriza pra uma consultoria. E com isso, a TI do cliente, ainda sem foco e sem gente qualificada que entenda de software, vai simplesmente pedir pra qualquer consultoria que um projetão deve ser feito em X meses e deve ser o mais barato possível.

E aí? A consultoria atrasou a entrega? Sem problemas! Pega o dinheiro da multa contratual e paga uma outra consultoria barateira que faça o serviço. A consultoria não entregou com qualidade? Mas quem se importa? Não é a consultoria que vai perder com isso, muito menos a TI do cliente, que sempre vai colocar a culpa nas terceirizadas. A TI não compra softwares de terceiros, compra bodes expiatórios.

Mas não sou louco, a fábrica de software é um erro! Mas qual é a responsabilidade de quem os contrata? Será que os clientes são tão vítimas assim?
]]> http://www.guj.com.br/posts/preList/59536/514797.java http://www.guj.com.br/posts/preList/59536/514797.java GMT
Acho que são sim. Eles simplesmente não sabem a diferença. Pergunta para eles o que o cara de TI faz.

No caso de empresas estatais, mesmo que tenham um setor de TI p/ atende-las, elas não contratam consultorias diretamente, são as consultorias que ganham licitações, isto é, leva quem oferecer o menor preço(dizem...). E tem o menor preço que oferece os serviços de pior qualidade.]]> http://www.guj.com.br/posts/preList/59536/514818.java http://www.guj.com.br/posts/preList/59536/514818.java GMT
http://fragmental.tw/2008/02/17/architecture-is-about-people-sharing-models/]]> http://www.guj.com.br/posts/preList/59536/514885.java http://www.guj.com.br/posts/preList/59536/514885.java GMT http://www.guj.com.br/posts/preList/59536/514913.java http://www.guj.com.br/posts/preList/59536/514913.java GMT
Manter uma equipe desenvolvendo em waterfall (mas falando que é rup) tem grandes chances de sair mais caro.

Mas enfim, quais são os aumentos de custos que há no caso de manter uma equipe trabalhando com metodologias agéis? Nem licença de MSProject vc precisa. ]]> http://www.guj.com.br/posts/preList/59536/514914.java http://www.guj.com.br/posts/preList/59536/514914.java GMT http://www.guj.com.br/posts/preList/59536/514931.java http://www.guj.com.br/posts/preList/59536/514931.java GMT Discordo. Quando a Toyota, por exemplo, adotou um modelo ágil ela não desviou o foco da sua atividade fim. Uma coisa não exclui a outra, e nem deve!
]]> http://www.guj.com.br/posts/preList/59536/514940.java http://www.guj.com.br/posts/preList/59536/514940.java GMT
Reduzir custos de quem ?! Do cliente ?! Da fábrica ?!
Tudo o que eu já vi em fábricas de SW é custo pra ambos os lados...

[quote]Encargos trabalhistas, por exemplo. Montar uma equipe ágil, treinada e com uma metodologia boa para desenvolver, testar e controlar o software toma tempo e dinheiro. Sem falar que o foco da empresa estaria se desviando da sua atividade fim. [/quote]

E numa fábrica de SW voce não teria esses mesmos custos ?

Mesmo com as melhores das intenções e com um "processo bem conduzido",
a maioria das fábricas de SW precisam de tanta papelada e CMMs da vida,
que esquecem do fundamental, software funcionando com qualidade.
]]> http://www.guj.com.br/posts/preList/59536/514951.java http://www.guj.com.br/posts/preList/59536/514951.java GMT http://www.guj.com.br/posts/preList/59536/514967.java http://www.guj.com.br/posts/preList/59536/514967.java GMT
[quote=alguém escrevendo em miguxês]... axo q ...[/quote]

Adoro miguxês, acho tão meigo...

[]s
Luca]]> http://www.guj.com.br/posts/preList/59536/514969.java http://www.guj.com.br/posts/preList/59536/514969.java GMT [/quote]

A pergunta persiste: custo de quem? Eu respondo: do fornecedor (da fábrica). O custo do cliente aumenta, e muito, com software de qualidade ridiculamente baixa, que precisa de manutenção frequente, não atende aos objetivos originais, foi entregue com atraso e estourou o orçamento.

Ok, fabricas de software podem não ter estes problemas se fizerem as coisas certas. [b]Quais são as coisas certas?[/b]

[quote=marcosalex]
Fábricas de software podem contar com incentivos fiscais que uma empresa de grande porte não pode.
[/quote]

Eu nem tenho certeza se ainda podem e nem se em todo o país, mas ainda que sim isso tem mais a ver com um governo que tenta imitar a Índia do que com eficiência ou benefício ao cliente. Novamente o benefício é para a fábrica e não para o pobre coitado que compra software dela.

[quote=marcosalex]
Tem muitos casos que acarreta custos para ambos os lados mas também já vi vários casos que houve uma redução formidável de custos, principalmente em empresas grandes.
[/quote]

Tendo trabalhado em diversos destes ambientes eu só vi redução de custo do fornecedor. O cliente, tendo comprado um péssimo software, so gasta mais dinheiro.

[quote=marcosalex]
Mas como eu disse, cada caso é um caso. Como todo mercado em fase de mudança, no começo aparecem muitos amadores que queimam o filme da área, mas a medida que a coisa vai se profissionalizando, o cenário muda e fica mais claro, até vir outra onda de mudança.[/quote]

Desculpe mas eu trabalhei em/trabalhei para/comprei de empresas que não são amadoras -com todos os seus selinhos de CMMI 5>- e nenhuma delas apresenta resultado satisfatório. Volto eu com a pergunta: o que é que precisa ser feito (e nenhuma destas empresas faz)?]]> http://www.guj.com.br/posts/preList/59536/514978.java http://www.guj.com.br/posts/preList/59536/514978.java GMT [quote]
Olá

[quote]
alguém escrevendo em miguxês wrote:
... axo q ...
[/quote]

Adoro miguxês, acho tão meigo...
[/quote]
[/quote]

quem é o emo ai?]]> http://www.guj.com.br/posts/preList/59536/514983.java http://www.guj.com.br/posts/preList/59536/514983.java GMT Encargos trabalhistas, por exemplo. Montar uma equipe ágil, treinada e com uma metodologia boa para desenvolver, testar e controlar o software toma tempo e dinheiro. Sem falar que o foco da empresa estaria se desviando da sua atividade fim.
[/quote]

Não entendi essas colocações.
[quote]1 - Encargos trabalhistas:[/quote] Vc tem tb isso com Fábricas de Software com processos em cascata.
[quote]2 - Montar uma equipe ágil, treinada e com uma metodologia boa para desenvolver, testar e controlar o software toma tempo e dinheiro.[/quote] - Vc tb tem isso com Fábricas de Software com processos em cascata.
[quote]3 - Sem falar que o foco da empresa estaria se desviando da sua atividade fim.[/quote] - De onde vc tirou isso??


]]> http://www.guj.com.br/posts/preList/59536/514988.java http://www.guj.com.br/posts/preList/59536/514988.java GMT
Quem faz mais uso de fábricas de software que não empresas de grande porte.]]> http://www.guj.com.br/posts/preList/59536/514992.java http://www.guj.com.br/posts/preList/59536/514992.java GMT E por acaso isso não é repasso para os cliente né?
Um projeto em waterfall pode levar anos para fazer um simples crud, quem passa isso?
O modelo onera o cliente, a prestadora de serviço tem como intuito carregar o desenvolvimento eternamente pois ela ganha ainda mais, engociações contraturais desse tipo favorecem essas empresas que vizam o lucro, não em entregar soluções para seus clientes.]]> http://www.guj.com.br/posts/preList/59536/515006.java http://www.guj.com.br/posts/preList/59536/515006.java GMT http://www.guj.com.br/posts/preList/59536/515058.java http://www.guj.com.br/posts/preList/59536/515058.java GMT
Não estamos falando que terceirizar é errado, estamos falando que o modelo de etrceirização das fábricas são errados.
]]> http://www.guj.com.br/posts/preList/59536/515083.java http://www.guj.com.br/posts/preList/59536/515083.java GMT http://www.guj.com.br/posts/preList/59536/515091.java http://www.guj.com.br/posts/preList/59536/515091.java GMT
S4nchez:

Eu não tenho arrepios, mas minha pele fica verde, minha camisa
começa a rasgar e de uma hora para outra eu fico bombadão.

Jorge


]]> http://www.guj.com.br/posts/preList/59536/515413.java http://www.guj.com.br/posts/preList/59536/515413.java GMT
[quote=furutani]Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).[/quote]

Eu também. Deve ter alguma que use mas eu não conheço nenhuma. Pelo contrário, conheço algumas que se esforçam para conseguir CMM e são extremamente burocratizadas.

[]s
Luca[/quote]

Luca, Furutani:

Eu sempre achei esquisita a idéia de fábrica. Se "fábrica" tenta passar
a idéia de coisa profissional e bem organizada, vamos aplicar a outras
atividades intelectuais para as quais são cobrados profissionalismo e
competência:

Que tal "Fábrica de cirurgias" em vez de clínica ou hospital ?
Que tal "Fábrica de sentenças" em vez de escritório de advocacia ?
Que tal "Fábrica de diplomas" em vez de universidade ?

Se vendemos a idéia de "fábrica", por que nos ofendemos com a idéia
de que nossos clientes querem um produto pronto sem se envolver no
processo ?

Se compro um carro de uma montadora, não preciso ajudar a projetá-lo.
Se compro um pastel na feira, não preciso dar palpite de como fritar.

"Fábrica" passa essa idéia, e não me surpreende que muitos clientes
procurem comprar software como quem compra pastel, porque
é exatamente isso que estamos lhes dizendo.

Jorge


]]> http://www.guj.com.br/posts/preList/59536/515451.java http://www.guj.com.br/posts/preList/59536/515451.java GMT Tem certeza que já não existem algumas dessas fábricas por ai? rsrs


Tem um texto do Rodrigo Yoshima que fala sobre [url=http://blog.aspercom.com.br/2008/04/10/culturaempresarialemalta/]cultura empresarial[/url], é exatamente isso que não se existe nas fábricas, eles querem apenas recusros vendedores de horas, eles não querem pessoas para formarem seus times, por isso a grande rotatividade nesse tipo de empresa, não há o menor comprometimento (leia interesse) da empresa para com seus funcionários, o que acaba sendo mútuo, ai acontece o que vemos de pessoas ficarem as vezes menos de uma semana nessas empresas e já sairem, porque elas só servem pra quando vc quer levantar uma graninha fazendo trocentas horas/mês, como praticamentes todas tem problemas com prazo de entrega e qualidade, sempre há muito o que se fazer nos projetos, mesmo quando eles estão "90%" prontos já, só falta testar rs.
]]> http://www.guj.com.br/posts/preList/59536/515466.java http://www.guj.com.br/posts/preList/59536/515466.java GMT
KKK, Onde será que eu já ouvi e disse isso tantas e vezes?]]> http://www.guj.com.br/posts/preList/59536/515526.java http://www.guj.com.br/posts/preList/59536/515526.java GMT Tem um texto do Rodrigo Yoshima que fala sobre [url=http://blog.aspercom.com.br/2008/04/10/culturaempresarialemalta/]cultura empresarial[/url], é exatamente isso que não se existe nas fábricas, eles querem apenas recusros vendedores de horas, eles não querem pessoas para formarem seus times,
...
[/quote]

Luiz:

Li o artigo do Rodrigo e gostei, mas há também as empresas que adotam o conceito de
fábrica e tentam valorizar funcionários. Trabalhei em uma que fazia isso, do jeito dela: pagava
os vouchers para os líderes de projeto obterem certificação PMP, criou um "prêmio de excelência"
que naturalmente virou "prêmio de obsequência" (o pessoal não leu o Deming), deu treinamento
de "processos" (sim, aquele tipo de processos).

Em troca, havia relativamente pouca rotatividade. Mesmo com toda essa "valorização", a qualidade
deixava a desejar porque uma cultura dessas não promove fazer um bom trabalho. Aquele
"orgulho do próprio trabalho" do qual o Deming falava era muito difícil.

A distância física e psicológica do cliente atrapalha muito: o único projeto em que realmente deu
gosto de trabalhar a pessoa que fazia o papel do que hoje chamariamos de "product owner" fazia
seu trabalho excepcionalmente bem. Nunca a encontramos pessoalmente, mas a comunicação fluiu,
e tivemos um cliente psicologicamente próximo. Incrivelmente, faziamos tudo via conf call com
os EUA, e funcionava. O resultado permitiu que a equipe seguisse um processo que fazia sentido
naquele contexto, incorporando algumas práticas ágeis, sentisse orgulho do próprio trabalho e
recebesse um feedback excelente do cliente.

Infelizmente, esse projeto ficou truncado depois de 4 ou 5 meses e voltamos à deprimente
realidade da maioria dos projetos feitos nesse esquema: o cliente é uma entidade abstrata,
mediada por alguém sem skills de comunicação, os procedimentos e processos são impostos
de cima para baixo, e os vícios são percebidos (por alguns) mas não podem ser corrigidos.
A cultura empresarial favorece colocar tudo no piloto automático (traduzido do
CMMês "processo definido da organização") e acha que isso é bom.

Enfim, a moral da história é que o problema não é a ganância e a exploração de certas empresas.
Mesmo quando não há isso, percebe-se que o esquema de fábrica é furado.

Espero ter contribuído,

Jorge Diz
]]> http://www.guj.com.br/posts/preList/59536/515529.java http://www.guj.com.br/posts/preList/59536/515529.java GMT [/quote]

[b]Luiz[/b], enquanto no Brasil for comum as pessoas [b]levarem um por fora[/b] esse tipo de prática vai ser comum, se é que você me entende, acontece a mesma coisa na política, na administração pública, etc.. [/quote]

André:

Pode ser mesmo que um ou outro leve um por fora, mas me parece que se trata
muito mais da incapacidade de entender quais são as formas saudáveis de
desenvolver software.

Como profissão, não temos esse entendimento; não há um conjunto mínimo de boas
práticas com as quais concordemos.

Por exemplo, os livros que usamos na faculdade foram malhados ostensivamente
nestes fóruns: não imagino um forum de médicos, advogados ou engenheiros
civis fazendo isso ...

Adicione a isto o vício daqueles que gostam muito de gestão e nada de pôr a
mão na massa e perdem o contato com o dia a dia do desenvolvimento (vide a
quantidade de gente fazendo MBAs, virando PMPs, montando PMOs e sonhando
em virar CTOs, CIOs ou, quem sabe, CEOs.

São esses profissionais de três letrinhas (parafraseando o Shoes) que decidem
como, onde, quem e por quanto vai desenvolver os sistemas que fazem
(ou não fazem) funcionar as empresas.

Jorge


]]> http://www.guj.com.br/posts/preList/59536/515543.java http://www.guj.com.br/posts/preList/59536/515543.java GMT Por enquanto, terceirizar é melhor quando:

1) Não consegue a competência imediatamente: não tem cabimento reinventar a roda. Um terceiro é capaz de fazer a transferência deste conhecimento rapidamente. É muito mais prático e rápido do que buscar um profissional no mercado.
[/quote]

Talvez, mas não deve ser desculpa para não capacitar o pessoal interno. Alguém tecnicamente
competente e que entenda o negócio precisa fazer essa ponte, mesmo que essa pessoa não faça
todo o trabalho técnico. Dificilmente tecnologia da informação não seja crítico numa empresa.
O pessoal de fora vai demorar também para entender o suficiente do
negócio para fazer um trabalho minimamente decente.

[quote=marcosalex]
2) Quer uma mudança profunda: seja de que natureza for, tecnológica ou não, transformações radicais são melhor conduzidas por terceiros. A razão? Os profissionais da equipe atual serão sempre um foco de resistência ao novo. Nem sempre seguem o que dizia John Cage "Não temos que temer as novas idéias, mas sim as velhas"
[/quote]

Vc se surpreenderia com as idéias que o pessoal de dentro guarda pra dentro quando
o clima interno não favorece a troca de idéias. Uma empresa terceira que funcione como
exército de ocupação, impondo "mudanças profundas" pode ter um efeito similar ao visto
em Bagdá: radicalização da resistência e sabotagens diversas.

Acho, no entanto, que alguém de fora que seja um bom facilitador pode promover
a mudança através de alguma forma de coaching.

[quote=marcosalex]
3) Competência: sua companhia até pode dominar determinado conhecimento, mas está consumindo investimentos e não necessariamente está remunerando o capital com o retorno compatível com o resto das operações. É hora de pensar em terceirizar, pois o prestador de serviço está mais predisposto a fazer investimentos em qualificação do que sua empresa.
[/quote]

Como disse antes, pode terceirizar parte da força de trabalho, mas mantenha gente capacitada dentro.
Se sua empresa não está disposta a qualificar quem precisa ser qualificado, esse alguém, cedo ou tarde,
vai decidir com os pés. Perder alguém capacitado em tecnologia *e* no seu negócio dá um prejuízo
gigantesco.

[quote=marcosalex]
4) Prazo: se o problema é cumpri-lo, a capacidade um terceiro em alocar recursos é alta. Em geral, ele sempre conta com uma reserva técnica, acionada nestas emergências.
[/quote]

Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.
]]> http://www.guj.com.br/posts/preList/59536/515553.java http://www.guj.com.br/posts/preList/59536/515553.java GMT 3) Competência:
...
É hora de pensar em terceirizar, pois o prestador de serviço está mais predisposto a fazer investimentos em qualificação do que sua empresa.
[/quote]

Não vejo assim. Meu feeling, na condição de quem ministra treinamentos, é que as empresas
"clientes" compram mais treinamento que consultorias, software houses e fábricas de software.
E antes, quando trabalhei em consultoria, sempre tinha a impressão que o pessoal dos clientes
recebia mais treinamento.

Uma explicação possível é que para a consultoria o investimento sai caro: tem que pagar o
treinamento e deixar de receber essas horas de um cliente.

Jorge
]]> http://www.guj.com.br/posts/preList/59536/515556.java http://www.guj.com.br/posts/preList/59536/515556.java GMT Bom, você concordou comigo que a fábrica consegue reduzir custos ( Note que eu sempre estou falando das boas fábricas) e essas conseguem oferecer vantagem competitiva para seus produtos nos clientes.[/quote]

Não! Eu concordei que a fábrica reduz o custo dela própria mas ela em geral [b]aumenta[/b] o custo para o cliente ao entregar software de péssima qualidade, atrasado e com orçamento estourado. Mas pro fornecedor é um negocião.

[quote=marcosalex]
Em empresas que trabalhei e que tive a oportunidade de conhecer, conseguimos reduzir bastante custo com pessoal contratando softwares de terceiros. [...]
[/quote]

Acho que, como o Luiz apontou, você pode estar confundindo fábrica com terceirização. Eu trabalho com terceirização de desenvolvimento de software e não trabalho em uma fábrica.
]]> http://www.guj.com.br/posts/preList/59536/515601.java http://www.guj.com.br/posts/preList/59536/515601.java GMT http://www.guj.com.br/posts/preList/59536/515694.java http://www.guj.com.br/posts/preList/59536/515694.java GMT http://www.guj.com.br/posts/preList/59536/515696.java http://www.guj.com.br/posts/preList/59536/515696.java GMT 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 !!
[/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 [i]contractors[/i] ("PJ") ou ainda em muitos casos fazendo dentro de casa mesmo.]]> http://www.guj.com.br/posts/preList/59536/515800.java http://www.guj.com.br/posts/preList/59536/515800.java GMT http://www.guj.com.br/posts/preList/59536/515994.java http://www.guj.com.br/posts/preList/59536/515994.java GMT
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:[b] fechar escopo, custo e prazo e buscar culpados por atrasos em projetos[/b]. Os clientes são tão culpados quanto os fornecedores pelo fracasso.]]> http://www.guj.com.br/posts/preList/59536/516005.java http://www.guj.com.br/posts/preList/59536/516005.java GMT 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?]]> http://www.guj.com.br/posts/preList/59536/516018.java http://www.guj.com.br/posts/preList/59536/516018.java GMT 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.

[quote=marcosalex]
... o produto entregue não vai ter todos os requisitos necessários.
[/quote]

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

[quote=marcosalex]
[quote=Jorge Diz]
Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.
[/quote]

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]
[/quote]

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.

]]> http://www.guj.com.br/posts/preList/59536/516048.java http://www.guj.com.br/posts/preList/59536/516048.java GMT http://www.guj.com.br/posts/preList/59536/516053.java http://www.guj.com.br/posts/preList/59536/516053.java GMT
Se a pergunta foi para mim, respondo: nenhuma.
Foi isso que quis frisar, aparentemente sem sucesso.
]]> http://www.guj.com.br/posts/preList/59536/516056.java http://www.guj.com.br/posts/preList/59536/516056.java GMT http://www.guj.com.br/posts/preList/59536/516061.java http://www.guj.com.br/posts/preList/59536/516061.java GMT 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.

]]> http://www.guj.com.br/posts/preList/59536/516170.java http://www.guj.com.br/posts/preList/59536/516170.java GMT
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.]]> http://www.guj.com.br/posts/preList/59536/516222.java http://www.guj.com.br/posts/preList/59536/516222.java GMT http://www.guj.com.br/posts/preList/59536/516249.java http://www.guj.com.br/posts/preList/59536/516249.java GMT Que tal desenvolvimento iterativo (e incremental)?

[quote=marcosalex]Ter uma visão global e for atualizando com baselines a medida que as atividades forem se abrindo[/quote]
Que tal um Product Backlog que vai tendo seus itens flutuando pra baixo e pra cima conforme a prioridade/necessidade DO CLIENTE?

[quote=marcosalex]As ferramentas de gerenciamento de projeto hoje em dia fazem isso, já que não é só na nossa área que acontece isso. Os relatórios de baseline ajudam pra caramba a trabalhar esses projetos e tentar diminuir ao máximo o desvio, que na nossa área sempre vai ter.[/quote]
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.]]> http://www.guj.com.br/posts/preList/59536/516266.java http://www.guj.com.br/posts/preList/59536/516266.java GMT Tem que é mais fácil identificar em muitos casos pontos onde pode haver paralelismo e onde não podem! Concordo que existe um limite, mas não se iluda de que não existe nenhuma forma de paralelismo e generalize. Se fosse assim, todo software por maior que seja teria um único profissional trabalhando.
[/quote]

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?

[quote=marcosalex]
Pensa em um exemplo simples: pra alguém fazer um cadastro de clientes, nada impede de outro analista fazer o relatório desse cadastro mesmo que eles tenham de gastar um tempo se comunicando. Em muitas situações não é difícil identificar quando um novo profissional pode ajudar e quando não pode.
[/quote]

Se o desenvolvedor já está no time provavelmente o relatório é uma user story separada e sim, ele pode ser paralelizado [b]dentro do time[/b] se fizer sentido. Se o desenvolvedor vem de fora então seu exemplo está explicado no livro do Fred Brooks, já citado:

[quote=The Mythical Man-Month, Chapter 2]
More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.

Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
[/quote]

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.

[quote=marcosalex]
Entendi. Esse é um problema não só da nossa área, tem muitos projetos com essas características e tem tratamento próprio, mas como você disse, não existe uma fórmula exata, mas tem maneiras de minimizar. Escopo e prazos rígidos é certo que não funcionam, mas dá pra conseguir uma aproximação.
Não é novidade pra ninguém da área que quanto maior o projeto de software, mais difícil é fechar o escopo, custo e prazo, ao contrário da engenharia onde dá pra se ter uma base de tudo e até fazer uma maquete. Mesmo projetos pequenos, dependendo do tipo, pode ser difícil definir os requisitos, isso também todo mundo sabe.
Pra fechar com uma fábrica de software nesses casos o que muita gente faz é fechar contrato por pequenas partes a medida que for esclarecendo o serviço. Ter uma visão global e for atualizando com baselines a medida que as atividades forem se abrindo. As ferramentas de gerenciamento de projeto hoje em dia fazem isso, já que não é só na nossa área que acontece isso. Os relatórios de baseline ajudam pra caramba a trabalhar esses projetos e tentar diminuir ao máximo o desvio, que na nossa área sempre vai ter.
[/quote]

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.]]> http://www.guj.com.br/posts/preList/59536/516267.java http://www.guj.com.br/posts/preList/59536/516267.java GMT http://www.guj.com.br/posts/preList/59536/516385.java http://www.guj.com.br/posts/preList/59536/516385.java GMT Sim, adaptado à realidade do desenvolvimento de software.
[/quote]

Mas modelo iterativo e incremental (com todas as suas variações) [b]é[/b] para desenvolvimento de software.

[quote=marcosalex]
[quote]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. [/quote]
Exato, não consegui entender onde você discorda. No caso da fábrica, o time seria da fábrica. Lembre-se, claro , que sempre tem alguém de dentro do cliente acompanhando o projeto.
[/quote]

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.

[quote=marcosalex]
[quote]Quanto ao MVC, eu ainda não entendi como ele se encaixa nisso tudo. [/quote]
Você não acha produtivo separar alguém cuidando da camada de apresentação enquanto outros cuidam das regras de negócios. E que as métricas pra avaliar cada uma das áreas costumam ser mais semelhantes entre si do que de camadas diferentes? Foi isso que eu quis dizer quando citei o MVC.
[/quote]

Bom, [url=http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas]MVC não é sobre Camadas[/url], 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.

[quote=marcosalex]
[quote]As ferramentas (e, principalmente, as metodologias) de gerenciamento de projeto fazem isso há anos e não resolveram os problemas.[/quote]
Podem não ter resolvido, mas conseguiram mensurá-lo e minimizaram. Um projeto complexo sem gerenciamento costuma atrasar muito, muito mais e sair muito mais fora do escopo. E pior de tudo, esse desvio não é dimensionado, deixando a empresa as cegas do quanto perdeu. A única coisa pior do que o projeto falhar, é não conseguir estimar o tamanho da falha.
[/quote]

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?

[quote=marcosalex]
Em algumas soluções pode até funcionar, ou mesmo em algumas partes do projeto, mas como você mesmo citou, ele não resolve tudo. Mais um motivo para ter um gerenciamento constante e trabalhar com baselines pra acompanhar. Várias metologias prevêem isso, como o tão citado Scrum, por exemplo.
[/quote]

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.]]> http://www.guj.com.br/posts/preList/59536/516739.java http://www.guj.com.br/posts/preList/59536/516739.java GMT Você não acha produtivo separar alguém cuidando da camada de apresentação enquanto outros cuidam das regras de negócios. E que as métricas pra avaliar cada uma das áreas costumam ser mais semelhantes entre si do que de camadas diferentes? Foi isso que eu quis dizer quando citei o MVC.
[/quote]

Marcos, desculpa a sinceridade, mas esse foi o maior absurdo que ouvi nesse fórum até hoje.

http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/

[quote]Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido. Kent Beck [/quote]
]]> http://www.guj.com.br/posts/preList/59536/516814.java http://www.guj.com.br/posts/preList/59536/516814.java GMT http://www.guj.com.br/posts/preList/59536/516868.java http://www.guj.com.br/posts/preList/59536/516868.java GMT http://www.guj.com.br/posts/preList/59536/516871.java http://www.guj.com.br/posts/preList/59536/516871.java GMT Eu nunca disse livremente, mas onde for possível.
[...]
Entre Componentes é uma forma de identificar pontos que pode ter mais de um analista. Mas mesmo nas camadas você pode aproveitar mais de uma pessoa, dependendo do caso. Como eu disse antes, senão todo projeto teria um só analista do começo ao fim. Novamente, eu nunca disse que você pode aumentar o número de pessoas indefinidamente, mas em muitas situações, é sim possivel.
[/quote]

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]
[quote=Jorge Diz]
Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.
[/quote]

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.

[quote=marcosalex]
Achei engraçado seu exemplo mas não entendi. Você acha que acompanhar um projeto nunca vai ajudar a melhorar? É melhor deixar ele caminhando às cegas? Eu acredito que gerenciado você consegue identificar os gargalos mais rapidamente e tomar as ações necessárias antes que a coisa saia do controle. Na pior das hipóteses você vai poder avisar a diretoria com antecedência que o cronograma terá de ser revisto.
[/quote]

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? [b]Não[/b]. 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 [/quote]

Engraçado, eu citei aqui alguns trabalhos -Mythical Man-month, CHAOS Report- estatísticos e acadêmicos. Será que é somente minha opinião?]]> http://www.guj.com.br/posts/preList/59536/516893.java http://www.guj.com.br/posts/preList/59536/516893.java GMT Comonentes podem [b]tecnicamente[/b] ser implementados por times diferentes. Muitas vezes funciona. o problema é que para [b]Componentes de Negócio[/b] 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.]]> http://www.guj.com.br/posts/preList/59536/516894.java http://www.guj.com.br/posts/preList/59536/516894.java GMT Bom, se você acha que um trabalho de interfaces é mais comparável com quem trabalha na regra de negócios, ótimo. Sobre o artigo, ele vai muito em direção ao que falei: gerenciar o processo não é só caso de uso e uml, tem de ser gerenciado de perto analisando caso a caso as atividades. O que sai caro na grande maioria das vezes é deixar tudo andar com a maré.[/quote]

Marcos,

Especializar papéis entre análise e programação já é sofrível. Fazer isso ao nível de camadas e tentar gerenciar essa dinâmica é uma aberração.

Pelas conversas que tivemos nesse fórum dá pra ver que você é bem fã da visão do PMBOK com relação ao gerenciamento de projetos (WBS, escopo detalhado, controle de tarefas e etc...). Atualmente tenho desenvolvido softwares para a área de engenharia (mecânica, elétrica e civil) e vejo que essa visão casa bem com esses tipos de projetos. São projetos que envolvem mais de 10 equipes e centenas de pessoas que muitas vezes não são profissionais do conhecimento (aka peão de obra). Outro ponto: esses projetos tem uma segurança com relação à sua previsibilidade. É um tipo de projeto que a soma das tarefas dá o resultado esperado.

Para projetos de software as tarefas não são importantes para o gerenciamento. O que é importante são os objetivos. São histórias implementadas e não tarefas cumpridas (como o pcalcado explicou). Nosso earned value cresce só com casos de uso funcionando. Escrever casos de uso, fazer modelos, fazer planos, codificar, testes não agregam valor. Como sempre digo, o escopo de um projeto de software é resolver problemas de negócios e não implementar requisitos. É um processo empírico.
]]> http://www.guj.com.br/posts/preList/59536/516981.java http://www.guj.com.br/posts/preList/59536/516981.java GMT http://www.guj.com.br/posts/preList/59536/517439.java http://www.guj.com.br/posts/preList/59536/517439.java GMT http://www.guj.com.br/posts/preList/59536/517455.java http://www.guj.com.br/posts/preList/59536/517455.java GMT Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações.
[/quote]
Nunca disse em muitas, mas "quando possível".
[/quote]

Sim, você disse que em muitas situações:

[quote=marcosalex]
Eu nunca disse livremente, mas onde for possível.
[...]
Entre Componentes é uma forma de identificar pontos que pode ter mais de um analista. Mas mesmo nas camadas você pode aproveitar mais de uma pessoa, dependendo do caso. Como eu disse antes, senão todo projeto teria um só analista do começo ao fim. [b]Novamente, eu nunca disse que você pode aumentar o número de pessoas indefinidamente, mas em muitas situações, é sim possivel.[/b]
[/quote]

[quote=marcosalex]
Isso é fato em projetos de software e qualquer gerenciamento sabe disso. Eu tomaria cuidado com a palavra "sempre" porque se foi verdade na maioria das vezes, já deixou de ter faz um bom tempo. As métricas atuais tratam esse tipo de caso, basta saber usar. Isso vale tanto para fábricas de software quanto para outras empresas (de softwares ou similar).
[/quote]

O CHAOS Report discorda de você. Pode ser sua opinião mas dadas as estatísticas tanto do relatório quanto das pessoas que postaram nesta thread eu creio que voc6e está enganado.

[quote=marcosalex]Você está analisando o pior caso. Será que a maioria dos gerentes de software ainda pensam assim? A grande maioria não, a realidade tem mudado bastante. Novamente eu tomaria cuidado com a palavra "sempre" e generalizações.
[/quote]

Novamente: confira as estatísticas antes de falar em maioria.

[quote=marcosalex]
Todos os trabalhos citados falam de uma abordagem comum para todos os projetos, a famosa "receita de bolo para o sucesso". Gerenciamento nunca foi isso. E nesses trabalhos eles mesmo citam que não estão falando para não usar as metolodias, mas para não adotá-las como regra geral, eu concordo com isso. Gerenciamento é saber quando, onde e em que ponto usar. NESSE PONTO, fábricas de software podem ter um sucesso maior.[/quote]

[b]Nenhum[/b] dos trabalhos citados ala sobre receita de bolo ou sequer descreve metodologias. Antes de criticar algo é sempre bom saber do que se trata.]]> http://www.guj.com.br/posts/preList/59536/517576.java http://www.guj.com.br/posts/preList/59536/517576.java GMT Cite apenas um exemplo real de uma empresa conceituada que conseguiu isso dessa maneira que vc descreve tanto nessa thread!

Agora se quiser exemplos de empresas que não conseguem, podemos fazer uma lista aqui de pelo menos 10 páginas.

Parece que vc esta se esforçando para "vender" um brinquedo quebrado, que todos estão carecas de saber que não da certo, que não funciona, o Phillip cansa de citar autores e mais autores mostrando isso, relatos e mais relatos comprovando a grande porcaria que é trabalhar dessa maneira, mas como sempre, continuam tentando meter isso goela abaixo, vendendo idéias falidas há vários anos, tentando achar meios de justificar os erros para fazer acreditar que se tivesse sido feito corretamente, funcionaria.
Desculpe, mas estamos em 2008, acho pouco provável alguém (que seja do meio, geralmente o cliente não é) ver os fatos, analisar o cenário (como toda hora alguém faz mostrando dados, autores e etc) ainda dar crédito a toda essa maneira fálida de se pensar em software.

]]> http://www.guj.com.br/posts/preList/59536/518179.java http://www.guj.com.br/posts/preList/59536/518179.java GMT http://www.guj.com.br/posts/preList/59536/518230.java http://www.guj.com.br/posts/preList/59536/518230.java GMT Pra cada autor que defende uma idéia é possível citar n que defendem outras alternativas.
[/quote]

Ótimo, então cite e vamos continuar o debate.

[quote=marcosalex]
O estranho é achar que não vale a pena gerenciar um projeto ou ter métricas pra avaliar a qualidade do software.[/quote]

Essa parte tá meio chata. Já foram umas duas ou três vezes que falei aqui que não é sobre não gerenciar ou ter métricas mas sim qual tipo de gerência e métrica é usada, como por exemplo na página anterior:

[quote=pcalcado]
[...]
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]

A conversa estava interessante mas peço que leia as respostas, do contrário fica bem difícil mantêr um diálogo sadio.]]> http://www.guj.com.br/posts/preList/59536/518232.java http://www.guj.com.br/posts/preList/59536/518232.java GMT http://www.guj.com.br/posts/preList/59536/518309.java http://www.guj.com.br/posts/preList/59536/518309.java GMT Como eu já havia dito, cada caso é um caso e pra cada fase do projeto pode ser que o tipo de gerência, metodologia e métrica seja diferente, daí a necessidade de um gerenciamento.
"No silver bullet", se existisse uma fórmula mágica desenvolvimento não seria tão caro e projetos não falhariam tanto. Acho que até aí você concordou comigo. O ponto de discordância é achar que X ou Y "nunca" funcionará ou que A ou B "sempre" falhará.
[/quote]

Hmm.. interessante. [b]Você sabe de onde surgiu a frase "No Silver Bullet"?[/b]

De qualquer forma, favor mostrar onde eu falei que algo sempre falha para que entenda melhor o que está dizendo.

[quote=marcosalex]
O que você chama de cronograma completo? Se for ter um cronograma no início do projeto e se ater a ele, não é só pra software que não funciona, mas em qualquer projeto que o escopo vai se definindo a medida que for caminhando. O problema é achar que por causa disso pode desenvolver sem nenhuma previsão e sem nenhum acompanhamento por acreditar que "como vai furar, não adianta acompanhar, no dia que ficar pronto, eu entrego".[/quote]

Eu não vou nem entrar no cronograma, só vou perguntar quem falou [i]"pode desenvolver sem nenhuma previsão e sem nenhum acompanhamento por acreditar que 'como vai furar, não adianta acompanhar, no dia que ficar pronto, eu entrego'"[/i].

Me parece que você está implicando que se não se usa os métodos que você defende para gerência de projetos (por exemplo um cronograma de tarefas) não há gerência. Se isso for verdade então sinto muito mas você está completamente enganado.]]> http://www.guj.com.br/posts/preList/59536/518326.java http://www.guj.com.br/posts/preList/59536/518326.java GMT http://www.guj.com.br/posts/preList/59536/518370.java http://www.guj.com.br/posts/preList/59536/518370.java GMT Sim. Já estudei esse artigo e a resposta dele "There is a Silver Bullet" do Brad Cox. Acho que a maioria das faculdades também passam trabalho sobre eles, já que são verdadeiros "classicos". hehehe
[/quote]

Pois é, o autor deste artigo chama-se Fred Brooks e é o autor que eu estou recomendando que você leia há duas páginas -o livro que fala sobre como novas pessoas atrasam um projeto.

[quote=marcosalex]
Acho que entendi sua interpretação da minha mensagem. Não me referi necessariamente a cronograma orientado a tarefa, mas em acompanhar de perto o que está sendo entregue. Você não acha que durante o desenvolvimento de um projeto, principalmente maior, é possível eu avaliar alguma parte que ficou pronta e estimar se o tempo gasto está condizente com alguma parte que foi entregue? Mesmo que não possa generalizar, você não concorda que pode acontecer? E se eu identificar que esse desempenho não está caminhando de acordo com o que eu esperava tenho mais chances de mudar a estratégia do que identificar no final?

Se você concordar nesse ponto, a discussão já teria tido um grande progresso.
[/quote]

O que eu não entendi até agora é onde você acha que eu discordei disso. O tópico é sobre Fábrica de Software e não sobre se um projeto deve ou não ser acompanhado. O meu ponto é que os métodos usados pelas fábricas -e não necessariamente os princípios- falham e existem meios melhores.


[quote=marcosalex]Bom, organizando as idéias:
1 A empresa está com um determinado problema e chegou a conclusão internamente que o desenvolvimento de um software resolveria esse problema.
2 Por questão de limitação de recursos (humanos, financeiros, tempo, cronológico, etc) decidiu terceirizar
3 Poderia escolher uma das várias opções: comprar software pronto, contratar uma empresa de software normal pra desenvolver ou contratar uma fábrica de software

Até aí a gente concordou que terceirizar [b]poderia[/b] ser uma opção dependendo do caso. A discordância foi que a metodologia de uma fábrica de software poderia ser melhor do que outras já existentes, certo? Você citou que já teve experiências que no final o produto demorou mais tempo, custou mais e não saiu com a qualidade esperada.[/quote]

Exato e por isso eu não entendi seu pontos nos últimos dois ou três posts antes deste.

O assunto está andando em círculos, então vou tentar concluir:

[b]Gerenciar um projeto é importante. Existem milhões de formas de fazer isso. Uma fábrica se baseia no modelo de linha de montagem, linha de montagem [i]não funciona[/i] para software. Claro que pode funcionar num caso X ou Y mas como regra geral não funciona e as estatísticas mostram isso.[/b]]]> http://www.guj.com.br/posts/preList/59536/518392.java http://www.guj.com.br/posts/preList/59536/518392.java GMT http://www.guj.com.br/posts/preList/59536/518418.java http://www.guj.com.br/posts/preList/59536/518418.java GMT
Bom, uma rápida procura na wikipedia mostra um artigo que resume o pensamento nacional sobre o que é uma fábrica de software:

http://pt.wikipedia.org/wiki/F%C3%A1brica_de_Software

[editado]
Deixando mais claro:
[quote=wikipedia]
Fábrica de Software é um conjunto de Recursos (Humanos e Materiais), Processos e Metodologias estruturados de forma [b]semelhante àqueles das industrias tradicionais[/b]...
[/quote]
[/editado]]]> http://www.guj.com.br/posts/preList/59536/518425.java http://www.guj.com.br/posts/preList/59536/518425.java GMT Marcos vc esta enganado amigo, pois é exatamente por se basear nesse modelo de linha de montagem que se usa essa terminologia "fábrica de software", ou seja, entra (requisitos), processamento (desenvolvimento, teste, homologação) e saída (produto final).

TODAS as empresas que se intitulam/rotual/vangloriam "fábricas de software" que eu conheço aqui em São Paulo trabalham exatamente assim, se existir alguma que trabalhe diferente (o que eu dúvido) nos fale para temos um exemplo real pelo menos.]]> http://www.guj.com.br/posts/preList/59536/518450.java http://www.guj.com.br/posts/preList/59536/518450.java GMT Concordo exatamente com você. Mas pelo que eu entendi de fábricas de software até hoje, elas não se baseiam em linha de montagem e produção em série da forma que você está falando, pelo menos o que eu interpretei dos modelos de fábricas de software que conheço[/quote]

Geralemten seguem o seguinte modelo: Analista de requisitos se reune com o cliente, o cliente inventa um milhão de coisas para o software, o analista faz um documento de requisitos, faz o cliente assinar os requisitos com o sangue, passa os requisitos para o arquiteto\projetista, que faz um monte de diagrama UML e passa para um programador que *traduz* aquele UML em código, compila, faz a build, passa para um testador que faz meia duzia de cliques nas telas do sistema, encontra N erros, e passa os Change Requests para o programador, que corrige os N erros, fazendo referencia do Change Request na alteração que ele teve que fazer, aí o tester fala para o gerentinho do projeto "OK", o gerentinho do projeto entrega o projeto pro cliente, o cliente homologa, passa para o usuário e ele ve que aquela joça não presta.

Ficou meio confuso (propositalmente), mas é mais ou menos assim.]]> http://www.guj.com.br/posts/preList/59536/518479.java http://www.guj.com.br/posts/preList/59536/518479.java GMT
Tome cuidado com essa necessidade exacerbada de gerenciamento de projetos. Como nossos colegas aqui do forum disseram, precisamos sim gerenciar, basta verificar como isso está sendo feito e como pode ser feito. Cuidado para não cair no "Comando Controle"... Desenvolvimento de software é arte, ao menos para mim, arquitetura também vai além da arquitetura e contrução civil no qual o nosso velho modelo cascata baseou-se. Fábricas de software, como todos disseram, seguiram o modelo industrial também, todos numa tentativa desesperada de se "moldar" o desenvolvimento de software.
Convido-o a participar de alguma palestra que fale do manifesto ágil ou mesmo sobre Scrum. Leia alguns artigos, blogs como o do nosso colega "Shoes".
Recomendo o link: http://www.scrumalliance.org/

Abra a mente meu camarada...

Forte abraço,
Dany Gregory.]]> http://www.guj.com.br/posts/preList/59536/591551.java http://www.guj.com.br/posts/preList/59536/591551.java GMT http://www.guj.com.br/posts/preList/59536/591604.java http://www.guj.com.br/posts/preList/59536/591604.java GMT
Como nosso colega disse que desenterrei um assunto jurássico, vamos por o dinossauro de volta porque não queremos um Rex solto por aí certo? Se é que vale o trocadilho.

Grande abraço!
Dany Gregory.]]> http://www.guj.com.br/posts/preList/59536/591976.java http://www.guj.com.br/posts/preList/59536/591976.java GMT ]]> http://www.guj.com.br/posts/preList/59536/650948.java http://www.guj.com.br/posts/preList/59536/650948.java GMT