Pessoal,

todo mundo baum?

Essa semana na DZone me deparei com o artigo abaixo falando a respeito da concepção errada das "Fábricas de Software".

É uns dos conceitos que eu mais abomino na TI. Nunca conseguir compreender e compartilhar desta visão de software como algo "manufaturado" em uma "linha de produção" virtual.

Bem, tirem um tempo pra ler. Vale a pena:

Burn Software Factories to the Ground and Let Software Studios Rise https://dzone.com/articles/lets-burn-the-software-factory-to-the-gr... via @DZone

Então, como tantos outras concepções errôneas na TI, "Fábrica de software" é um termo ruim, péssimo ou nem deveria ter existido? :D 

Exibições: 507

Responder esta

Respostas a este tópico

Quando fiz meu TCC sobre Assédio Moral em Fábricas de Software pesquisei a respeito da origem do termo.

É no mínimo curiosa: http://www.itexto.net/devkico/?p=1389

Henrique, excelente artigo!

Valeu!

O artigo da dzone cita um outro artigo da HBR que ainda não li. Mas de imediato gostei da distinção entre desenvolvimento e manufatura. De fato, se fosse pensar em fábrica de software, deveríamos pensar também em manufatura de software. 

Para mim está claro que o trabalho realizado durante o projeto de um software não é de manufatura, mas sim de desenvolvimento. 

Numa etimologia livre, desenvolver significaria "evoluir algo a partir de uma ideia",  e manufaturar significaria "produzir algo a partir de um plano".

Novamente, para mim está claro que o trabalho realizado durante o projeto de um software é de pegar a ideia original para o mesmo e evoluí-la até que ela se transforme num software. Claro que a longo do processo planos são definidos, e o software acaba por ser produzido. Mas isso é algo contínuo. O plano é definido ao longo do caminho. Se fosse possível definir todo o software com antecedência, talvez fosse possível pensar em manufaturar o software. 

Na verdade já se tentou fazer isso. Mas alguém viu funcionar? Eu já trabalhei em projetos de software de tamanho considerável onde TODOS os requisitos do projeto foram levantados e detalhados antes do desenvolvimento começar. Quando começamos a entregar o produto resultante da especificação não era nada do que o usuário necessitava. 

Alguém pode argumentar que a especificação foi mal feita. Mas mesmo que seja bem feita, as necessidades do usuário vão mudar. 

Vou traçar um paralelo. Uma empresa de 100 funcionários contrata uma construtura para construir sua nova sede, e quando a sede fica pronta, com espaço para 100 pessoas, a empresa já possuí 500 funcionários. O projeto foi mal feito? Não. Mas as necessidades de espaço da empresa mudaram.

Software é a mesma coisa. Principalmente software corporativo. As necessidades dos usuários mudam todos os dias. 

Qual a solução? Trabalhar apenas com equipes internas ou outsourcing produzindo e entregando software o tempo todo? Não necessariamente. Os clientes vão continuar querendo comprar software no modelo de projetos, e vão querer saber quanto vai custar e quando irão receber. Mas se quem produz software continuar pensando que a melhor forma de produzi-lo é no modelo de fábrica de software tradicional, vão continuar tendo prejuízo e criando clientes insatisfeitos.

Eu não acho um termo ruim. Da mesma forma que existe software feito por pequenos times de gente boa de servico de forma artesanal (vamos chamar assim, sem nenhum sentido pejorativo, pelo contrário), também existem aqueles sistemas gigantescos em que uma empresona contrata outra empresona lá na Índia, e resolve contratar a migracão de um sistema gigante em mainframe para outra tecnologia mais recente, cujo servico é feito após anos e muitos percalcos e muito choro e ranger de dentes.

É uma realidade horrível, mas economicamente é equivalente às linhas de montagem da foxconn. É exatamente a que se propõe. Impor sofrimento a milhares de desenvolvedores que trabalham em condicões horríveis para fazer coisas de qualidade duvidosa, mas que economicamente se mostrou viável :-)

Há lugar para todos no ecossistema do nosso mercado. :-)

Pra variar bons pontos né Leo? :)

Não li o artigo ainda (prometo que vou) mas concordo plenamente. Faz décadas que meto o pau nisso também. 

O interessante é que eu dava o curso de PSP / TSP na pós de Qualidade de Software do Senac, e o TSP é a versão do CMM criada pelo Watts Humphrey para equipes autogerenciadas. Ele viu que o CMM que ele criou tinha virado fórmula para desenhar linhas de produção e foi adiante, superando o conceito e passando para a metáfora de "célula" como no famoso caso da Volvo.

Quanto ao termo em si, quem achou que essa seria uma boa ideia é um verdadeiro "gênio"..

Terminologia espelha o contexto que voce vivencia, incluindo "termos da moda" que apesar de não se explicar tecnicamente, impulsiona muitas atividades comerciais. Quantos termos utilizados atualmente perderão o sentido ao longo do tempo, mas mesmo assim muitos continuarão utilizando? Que nome daríamos hoje à atividade de construção de aplicativos padronizados a partir de especificações padronizadas? Esclarecendo: Concordo que o termo "Fábrica de Software" nunca se explicou tecnicamente e funcionalmente.

O termo Fábrica é completamente equivocado. A natureza do trabalho de desenvolvimento é relativamente nova e ainda é muito mal compreendida pelas pessoas, incluindo muitos profissionais que trabalham na área no Brasil. Mesmo que a forma de contratação de "programadores" favoreça o baixo pagamento ou condições de trabalho ruins, isso não muda a essência do trabalho: um trabalho de projetar sistemas complexos adaptativos - seja em textos descritivos, em desenhos UML ou código que o computador entenda.

Para os que ainda tem dúvida sobre o assunto, sugiro a leitura do artigo do Martin Fowler chamado "A Nova Metodologia".

Esse artigo é muito bom mesmo Vinicius! valeu

RSS

Badge

Carregando...

© 2018   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço