O conceito de Fábrica de Software parece muito atrativo a princípio, mas peca em diversos pontos. Um caso ocorreu com um cliente meu há algum tempo.
Eu fui chamado para ajudar na definição de um projeto. O sistema era um pequeno website teoricamente componentizado (utilizando algumas das técnicas de Component-Based Design) que seria projeto-piloto de uma grande série, muito lucrativa para meu cliente.
O problema é que o usuário (que era uma outra empresa) já havia feito boa parte do trabalho de levantamento do sistema, o contato dos técnicos do cliente seria com os analistas de negócio do usuário final, não com os usuários. Acontece que boa parte não significa tudo e quem já trabalhou com processos em cascata (waterfall) sabe que isso costuma não dar muito certo.
O cliente trabalha em fábrica de software utilizado RUP. Alguns artefatos de análise já estavam prontos, mas não todos. Considerando que a análise já era considerada pelo usuário como feita ele, obviamente, não iria pagar por ela. Na instância de RUP utilizada pelo meu cliente (se não me engano homologada pela IBM até) deveria haver uma fase de projeto (design) após a análise, e esta fase recebia como insumo os artefatos produzidos na análise.
Legal, mas cadê os artefatos?
Como RUP não é minha especialidade, eu fui chamado para avaliar os artefatos existentes, a arquitetura a ser utilizada e dar um parecer sobre a viabilidade ou não do projeto no aspecto técnico. Olhando aquele monte de casos de uso e sequer um domain model pronto meu parecer foi claro: não há como entregar este sistema utilizando a metodologia atual sem completarmos a análise.
Bom, e agora? Minha sugestão foi mudar a metodologia de desenvolvimento. O cliente não exigia qualquer metodologia, apenas a produção de um documento de arquitetura extremamente minucioso e por isso mesmo ineficiente, mas que poderia ser gerado por uma metodologia ágil.
Metodologias ágeis pressupõem contato constante com o cliente e no caso nosso cliente seria o analista de negócios, que estava disponível para dirimir dúvidas. Trabalhando com iterações curtas e entregas frequentes o usuário estaria sempre vendo e corrigindo o curso, sem necessidade de uma grande fase de análise (seja num modelo iterativo como RUP ou não). Não é um case para XP, mas diversas técnicas ágeis podem ser facilmente empregadas neste cenário.
A sugestão foi bem aceita pelo corpo técnico, mas a gerência entrou em desespero. A fábrica já funcionava com a metodologia há alguns anos, mesmo não sendo nenhum exemplo canônico de eficiência, como mudar de uma hora para outra? O tempo a ser tomado para a mudança, argumentei, não seria tão longo com um líder de equipe e alguma dedicação. A equipe de técnicos era muito boa, acima da média na verdade, e não teria tantos problemas em assimilar as novas técnicas.
O problema não é a metodologia que a fábrica usa, nem o tempo, nem sequer a clássica resistência à metodologias ágeis. O problema era que aquilo era uma fábrica! Uma fábrica produz quase sempre a mesma coisa e sempre do mesmo modo. Se você muda o modo como as coisas são produzidas, como fica a teórica vantagem de ter uma fábrica?
Então, ou projetos para fábricas devem seguir o mesmo molde ou você tem muitas fábricas. Uma fábrica que permita dinamismo de processos não está seguindo os princípios do conceito, de padronizar para baratear. Muitas vezes as empresas de desenvolvimento fazem sim a mesma coisa repetida ad eternum, na minha experiência a maioria dos pequenos projetos é feita desta maneira.
Ocorre que nem todos são. Mesmo entre projetos pequenos de sites e aplicações web nós temos casos como este, que tirariam muito mais proveito de uma metodologia com características específicas (seja RUP, XP ou Scrum) do que a utilizada. Considerando que eu nunca vi uma fábrica que realmente cumprisse as vantagens teóricas sem desvantagens muito impactantes (como sacrificar qualidade pelo preço).
Mas este post nem visa criticar a vantagem teórica de fábricas de software, o foco é outro. A idéia da historinha é mostrar que alguém montando uma fábrica deve ter em mente é que este modelo de desenvolvimento não se aplica a todos os projetos que a empresa pode ter pela frente. Se sua empresa pode se dar ao luxo de negar um projeto porque não atende às exigências da fábrica ótimo, mas se não pode você deve ter um plano-B.
No caso específico deste projeto as pessoas competentes ainda estão discutindo o que fazer dele.
