Concrete Logo
Hamburger button

Os dez maiores erros da abordagem de fábrica de SW, parte 1

  • Blog
  • 26 de Fevereiro de 2013
Share
SW Factory

SW Factory

Se você procurar a definição do termo “fábrica de SW” no wikipedia brasileiro temos a seguinte definição.

“ Fábrica de software é um conjunto de recursos (humanos e materiais), processos e metodologias estruturados de forma semelhante àqueles das indústrias tradicionais, utilizando as melhores práticas criadas para o processo de desenvolvimento, testes e manutenções dos softwares. Utiliza em sua operação indicadores de qualidade e produtividade em cada etapa do ciclo de desenvolvimento de software, bem como busca maximizar a re-utilização de componentes anteriormente desenvolvidos. Tornou-se uma prática comum com o objetivo de massificar a produção de software pela redução de custos.”

Nos utilizando da definição livre da wikipedia podemos começar a lista dos 10 maiores erros relacionados ao uso desta abordagem.

1) “Fábrica de Software é um conjunto de recursos humanos e materiais.”

Fazer SW é um trabalho criativo onde as diferenças de produtividade podem chegar a 10 vezes, feitos por trabalhadores do conhecimento  que são pessoas que precisam ser motivadas e remuneradas para que produzam o seu melhor e tenham seus interesses alinhados com o cliente. Tratar o desenvolvedor como um recurso é não só infantilizar como desumanizar um tipo de profissional extremamente sofisticado e escasso. Inserir este profissional numa forma arcaica e ineficiente de fazer software atrai o que há de menos produtivo para sua “linha de montagem”.

2) “Os recursos são estruturados de forma semelhante a uma indústria tradicional”

Novamente recorrendo a wikipedia para o termo linha de montagem:

“ As linhas de montagens são utilizadas desde então no processo de produção em série, para que o produto em fabricação seja deslocado ao longo de postos de trabalho, mas a sua eficiência depende da combinação de quatro condições indispensáveis (Teixeira et al., 2008, p. 31-33):

  • Componentes estandardizados
  • Movimento mecânico
  • Equipamento de precisão
  • Processos padronizados”

Fazer SW tem mais semelhanças com o processo de criação do primeiro produto que evolui iterativamente de um conceito para um protótipo chegando a uma primeira versão comercial (vide apresentação sobre o desenvolvimento de um novo carro na Toyota), não se trata de produzir a mesma coisa em série repetidas vezes. Os componentes são feitos individualizadamente e de forma criativa para resolver um determinado problema e o nível de padronização é baixíssimo. Precisão e repetição foram eliminadas desta equação a muito tempo e são feitos pelos compiladores e linkers.

3) “…utilizando as melhores práticas criadas para o processo de desenvolvimento, testes e manutenções dos softwares”

A primeira fábrica de SW foi criada em 1969 na Hitachi e o processo waterfall é baseado numa malfadada leitura de um artigo de Winston Royce de 1970, onde ele usou a célebre frase profética  “but the implementation described above is risky and invites failure” . A criação de processos seriais de engenharia leva a uma falta de feedback total não só entre as áreas mas principalmente com o cliente. O produto é tardiamente  testado, tem pouca chance de sucesso e o investimento e alocação de despesas é feita sobre estimativas sem nenhum embasamento.

Adicionalmente a criação de silos de

  • requisitos,
  • arquitetura,
  • desenvolvimento,
  • testes e
  • operação e manutenção

leva a um desalinhamento de interesses. Apesar de ninguém saber o que fazer (como isto não é testado em campo) um tratado extenso de requisitos é feito para um problema que ninguém sabe exatamente qual é muito menos como resolve-lo.

Quem testa tem conflito de interesse com a ida de algo para produção e finalmente quem cria o produto (se ele eventualmente for para produção) não é quem dá manutenção nele.

Estes silos geram uma natural necessidade de burocratização dos pontos de interface e a uma gestão de mudança caótica e impraticável.

4) “…re-utilização de componentes anteriormente desenvolvidos”

A grande dificuldade do reuso que observei nos últimos 17 anos é a combinação de dois fatores

  • A necessidade de padronização de definição de uma forma clara de descrever aquele domínio.
  • A incapacidade da organização de prever o futuro e prescrever “a priori” o que de fato é um ativo reusável ou não e consequentemente como popular o seu catálogo.

O nível de reuso dentro de uma mesma organização é baixíssimo pois o catálogo é  “mal formado” ao contrário do que acontece num ambiente open source onde toda uma comunidade elege o que é um ativo reusavel de forma livre (na prática pelas leis de mercado).

Numa amostra pequena, cada projeto ou iniciativa tende a cobrir um pedaço do espaço do problema que não será visitado desta forma novamente. As iniciativas de SOA por exemplo tentavam prescrever o futuro sobre quais seriam os serviços reusáveis de uma organização e pior gerava um ciclo waterfall dentro de outro ciclo waterfall o que aumentava enormemente a complexidade. Tornávamos um projeto com 13% de chance de sucesso segundo o CAOS Report num projeto impossível.

5 “…Tornou-se uma prática comum com o objetivo de massificar a produção de software pela redução de custos ”

Warren Buffet uma vez disse “Não existe desperdício maior do que produzir com perfeição alguma coisa que ninguém quer”.

Quando analisamos processos produtivos como o método Toyota de Taichi Ono ou leituras como a Teoria das Restrições de Eliyahu Goldratt vemos similaridades na busca da otimização global com frameworks de melhoria continuada.  Se não analisarmos e otimizarmos o sistema como um todo, podemos (via otimização local) criar falsas economias de escala e gerando desperdício de duas formas, produzir a quantidade errada da coisa errada.

Goldratt, teoria das restrições

Se analisarmos o trabalho de Steve Blank e Eric Ries, que reflete o estado do conhecimento do Vale do Silício sobre como fazer produtos e empresas digitais entendemos que o maior desperdício não é fazer errado mas principalmente a coisa errada o que é em muito aumentado pela prescrição e o processo clássico (Waterfall) de lançamento de produto. Blank cita inclusive que o desenvolvimento de novos produtos é uma busca e não uma execução 

A produção de SW é tudo menos massificada, mas uma criação iterativa e incremental que busca materializar uma necessidade de um cliente que

  • Você ainda não sabe qual é,
  • Se ela é um problema que vale a pena ser resolvido
  • Muito menos como você vai resolve-lo.

Pensar numa linha de montagem para atacar um problema deste tipo é a mesma coisa que utilizar cavalaria e guerra de trincheiras no ambiente militar contemporâneo ou mantendo a metáfora militar tentar prescrever a invasão da normandia.