Essa brincadeira é bem famosa para quem já estudou ou mexeu com engenharia de software, principalmente na parte de levantamento de requisitos de um sistema. Mas há muita verdade por trás dela. Ela nos mostra que a engenharia de software é uma parte bastante humana da engenharia e que a falha de comunicação pode (e muito) atrapalhar no desenvolvimento de um sistema computacional. Aliás, posso dizer com pouca chance de estar falando besteira que a falha de comunicação que faz a grande maioria dos projetos falharem, desde o não-cumprimento dos prazos até o abandono do projeto no meio de seu desenvolvimento por não atender as expectativas.
O grande problema no desenvolvimento de software atualmente é que a maioria se utiliza de uma metodologia conhecida como RUP (Rational Unified Process) no modelo cascata. O problema do modelo cascata é que ele pressupõe que uma vez que os requisitos foram levantados, eles não irão mais mudar durante o processo de desenvolvimento. A partir de então desenvolvem-se as próximas etapas do processo, como documentação, arquitetura de software e codificação, etc.
Só que apesar de todo o esforço que fazemos na hora de levantar os requisitos, eles sempre acabam mudando durante o processo de desenvolvimento. Na hora que o cliente “olha a telinha”, sempre há alguma coisa que “não era bem assim”… Esse é um dos motivos que me fazem acreditar cada vez mais em metodologias agéis. Usando elas, os desenvolvedores já sabem que os requisitos vão mudar durante o desenvolvimento, mas existem práticas para lidar com essas mudanças.
Acredito cada vez mais que o desenvolvimento de um software não é um processo, mas sim um produto artesanal, no sentido que cada software é um software diferente por mais semelhanças que possam existir entre eles. O fato de ser artesanal não quer dizer que não seja profissional…
Logo, não acredito que exista de fato uma “fábrica de software” como algumas empresas dizem e acho difícil um dia existir. Escrever um software tem um pouco de arte: alguma inspiração e depois bastante transpiração para refinar.
Bom, é isso que queria compartilhar hoje!
Bom post, mas acho que melhor do que um produto artesanal, o software deveria ser encarado como obra de arte, assim ao invés de Fábrica de Software, teríamos Atelier de Software, como diria o Prof. Luis Barco.
Nunca tinha pensado no desenvolvimento de software como uma arte, mas, no fim, é realmente isso. Como numa música, em que a gente acha que o acorde não era bem esse, que poderia ficar melhor, vamos sempre achando que não está completo. E ainda temos um apego sentimental com a criação 😉
Depois de entender bem o conceito por trás das metodologias ágeis, a idéia de "fábrica de software" se no mínimo "menos" inteligente.
Imagine qual seria a métrica de uma "fábrica de software":
– Ah, hoje nossa fábrica fez 300 telas de login!
No dia seguinte:
– Ah, hoje fizemos 450 telas de login, melhoramos nossa produtividade em 50%!!!
A idéia por trás da fábrica de software e da engenharia de software tradicional como um todo nasceu como outros tipos de idéia que se baseiam na tentativa de compreender algo novo com pensamentos antigos. Quando criaram a televisão, os programas eram idênticos a programas de rádio, só que filmados =p.
Quando criaram a engenharia de software tradicional, acharam que os requisitos poderiam ser definidos todos de antemão e que o processo todo era prescritivo e não empírico. #EPIC FAIL
Que mais pessoas logo adotem metodologias ágeis.
Uma outra leitura recente sobre o assunto que recomendo muito é:
"My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no."
Da pra ler esse texto por inteiro no PDF que está aqui http://weblogs.asp.net/wallen/archive/2009/07/21/software-engineering-an-idea-whose-time-has-come-and-gone.aspx