O termo "fábrica de software" apresenta uma abordagem para o desafio de muitas organizações para o desenvolvimento de software. Sugere-se uma estrutura de profissionais, processos e metodologias num formato semelhante à estrutura de uma fábrica tradicional, monitorada por uma série de indicadores de qualidade e produtividade em cada etapa, buscando massificar a produção de software, gerando mais software no menor prazo possível com um nível de qualidade aceitável, e com o menor custo possível.
Greenfield (2004) apresenta a idéia básica dessa abordagem: "Outras indústrias aumentaram sua capacidade passando do artesanato, onde produtos inteiros são criados desde o início por indivíduos ou pequenas equipes, para a fabricação, onde uma larga gama de produtos é montada rapidamente com componentes reutilizáveis, criados por diversos fornecedores e onde as máquinas automatizam as repetições ou as tarefas subalternas. Elas padronizaram processos, projetos e embalagem, usando de linhas de produtos que facilitam a reutilização sistemática e cadeias logísticas que distribuem o custo e o risco. Algumas são, hoje, capazes de uma personalização em massa, onde as variantes do produto são criadas de forma rápida e não dispendiosa, de acordo com o pedido, para atender às necessidades específicas de clientes individuais."
Ainda conforme Greenfield (2004), na indústria em geral, essa reutilização sistemática pode gerar dois tipos de economia: de escala e de escopo. A economia de escala ocorre quando várias cópias idênticas de um único projeto são produzidos em série. Por exemplo, em uma gráfica, para gerar a matriz de impressão de um livro, há um custo, mas para imprimir mil exemplares do mesmo livro, o custo por unidade é menor. Geralmente a matriz exige um custo de desenvolvimento. A produção das cópias segue um processo diferenciado, pautado pela automação e mecanização, que tem um custo mais baixo.
A economia de escopo é caracterizada quando há reutilização de práticas, processos, ferramentas e materiais para o desenvolvimento de mais de um projeto. Tomemos como exemplo a fabricação de um carro: ele é composto por diversos componentes, como chassi, interior, farol, etc, e às vezes diversos modelos de automóveis aproveitam projetos já existentes desses componentes, variando um item ou outro. Por exemplo: não é incomum verificar que entre alguns modelos de automóveis da mesma marca, vários componentes são bem parecidos (farol, direção, etc.).
E aplicando esses conceitos na produção de software, há situações em que se terá a economia de escala, como no caso em que um mesmo produto (por exemplo, um Sistema Operacional ou uma suíte de escritório) é comercializado em grande escala (definição conhecida como "software de prateleira"), mas em boa parte das situações de desenvolvimento se desenvolve um produto para atender uma necessidade específica da organização, gerando apenas um "original" do mesmo. Nesses casos, não há economia de escala. Mas é possível obter a economia de escopo, conforme Greenfield (2004): "Podemos então ver onde maçãs estão sendo comparadas com laranjas. A produção nas indústrias físicas foi ingenuamente comparada ao desenvolvimento de software. Não faz sentido procurar economias de escala no desenvolvimento de nenhuma espécie, seja de software, seja de bens físicos. Nós podemos, por outro lado, esperar que a industrialização do desenvolvimento de software explore economias de escopo."
Nesta visão, e sob o contexto em que grande parte das fábricas de software desenvolvem um produto por demanda (ou seja, não há "produção em série" nem economia de escala), é uma visão errônea visualizar uma fábrica de software como uma linha de produção de automóveis, por exemplo, mas visualizar a fábrica de software como a área de desenvolvimento do projeto de um automóvel me parece mais conveniente. É um trabalho que requer muito mais atividade mental do que "braçal". E infelizmente, existem "donos" de fábricas de software com a primeira visão apresentada, querendo que desenvolvedores trabalhem como operários, produzindo "x" linhas de código por hora a um custo mais baixo possível. E essa abordagem errônea faz com essas fábricas tenham uma alta rotatividade de pessoal, o que torna difícil de implementar o que seria justamente o maior benefício que uma idéia de fábrica poderia trazer para o desenvolvimento de software, que seria a reutilização de componentes de outros projetos, processos maduros e bem estabelecidos, que resultariam na economia de escopo.
E pela natureza da atividade, a retenção dos talentos se torna fundamental. Voltando à comparação com a área de desenvolvimento do projeto de um automóvel, pode-se afirmar que a qualidade do trabalho das pessoas envolvidas estará representado no resultado final. No desenvolvimento de software é semelhante.
Enfim, algumas visões erradas nas implementações de um ambiente de fábrica de software fizeram com que o conceito fosse desvirtuado para algo errado e ineficiente. Comparar fábrica de software com uma linha de produção "em série" também não é a melhor comparação, e pode levar a conclusões erradas sobre o seu conceito. Implementar processos eficientes, buscar a reutilização e reter talentos não é ir contra o conceito de fábrica de software, mas sim utilizá-lo da forma adequada.
Referência
----------
GREENFIELD, J. O caso das fábricas de software. Disponível em <https://msdn.microsoft.com/pt-br/library/aa480032.aspx>. Acesso em 28 de maio de 2015.
Nenhum comentário:
Postar um comentário