Conversa vai, conversa vem, e esse assunto volta a ser tema de discussões no GUJ. Apesar de muito já ter sido dito sobre o assunto, é incrivel como muitos profissionais de TI ainda tem resistência em aceitar que algumas coisas simplesmente não funcionam, até mesmo quando os resultados destrasos da aplicação dessas práticas já estão muito bem documentados.
Com relação as fábricas de software e o modelo de produção em massa, algumas questões chamam atenção:
1. Software não é um prédio, uma casa ou uma ponte.
A idéia de que se poderia, desenvolver software de qualidade, da mesma maneira como engenheiros constróem um prédio, ou uma ponte por exemplo, é no mínimo despropositada.
Um prédio é uma estrutura rígida, imutável e com certeza você não poderá fazer um refactoring na sua estrutura. Não podemos simplesmente adicionar mais salas, quartos ou janelas à um andar, sem que tenhamos impactos na estrutura da construção.
A construção de um prédio, é intuitivamente o resultado de atividades sequenciais interdependentes. Não sei como construir um prédio, nas não preciso ser mestre de obras ou engenheiro civil, para saber que preciso ter as paredes concluídas antes de partir para o telhado. Que preciso garantir que o fundamento da construção, terá resistência suficiente para aguentar o peso do cimento, aço, tijolos, etc. A engenharia consegue prever com precisão considerável, antes do início da obra, quais o custos envolvidos num projeto.
Mas software não é assim. Desenvolvimento de software é muito mais empírio e artesanal. Muito mais humano do que as diferenciais e integrais que fazem com que um prédio fique de pé, imóvel durante anos.
A subdivisão enorme do trabalho e definição de fases distintas num enorme Waterfall, é algo que funciona na construção civil, mas nunca obteve sucesso no desenvolvimento de software.
Segundo Craig Larman, é evidente o fracasso dessa abordagem:
There isn’t one simple answer to why the waterfall is so failure-prone, but it is strongly related to a key false assumption underlying many failed software projects that the specifications are predictable and stable and can be correctly defined at the start, with low change rates. This turns out to be far from accurate and a costly misunderstanding.
Applying UML and Patterns – Larman, Craig
As fábricas de software repetem os mesmos erros de 50 anos atrás: insistem em mensurar os projetos como um todo antes de iniciá-lo, instalam metodologias burocráticas, utilizam métodos de gerenciamento inflexíveis, montam equipes enormes e dividem as atividades em fases , produzindo software como numa linha de montagem.
2. Desenvolvimento de software não é um commodity.
A maioria das fábricas de software, infelizmente, vendem horas. Horas de programadores, analistas de negócio, analistas de sistemas, testadores, arquitetos, etc.
Esse tipo de abordagem gera algumas situações bem interessantes: projetos atrasados, cronogramas imprecisos, desinteresse pela qualidade do serviço, pouco comprometimento dos profissionais e principalmente muito custo para o cliente.
Na maioria das vezes, o cliente tem problemas e não sabe como resolvê-los, e busca em empresas de tecnologia a soluçao dos seus problemas. Veja, não existe nada de errado em terceirização. É compreensível que uma empresa foque esforços no seu core business ao invés de contratar/capacitar profissionais de TI ensinando-os como programar.
Mas é fundamental que qualquer empresa conheça muito bem seus fornecedores, antes de contratar qualquer consultoria com CMMi 5.
3. Desenvolvimento de software é mais humano do que se possa imaginar.
One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.
But this raises a key question: are the people involved in software development replaceable parts?
The New Methodology – Fowler, Martin
Uma fábrica, por definição, ignora o fator humano no desenvolvimento de software, não levando em consideração a coisa mais importante: as pessoas. Geralmente são adotados inúmeros processos de qualidade CMM’S, CMMi’s, MPS.BR na tentativa de tornar as pessoas substituíveis. A maioria desses modelos de qualidade, definem detalhes inúmeros de processos, artefatos de entrada e saídas, diagramas, checklists, templates de documentos, etc. Ninguém precisa conhecer do negócio do cliente apenas saber preenhcer os formulários. Ninguém precisa pensar em melhores soluções. Pois todas as soluções já estão pré-formatadas, bastando apenas ao profissional seguir religosamente os procedimentos pré-estabelecidos.
Programação é um processo criativo e que depende de soluções idealizadas e implementadas por pessoas. E o envolvimento destas é fundamental. Não é por acaso que empresas como Google, Yahoo, Flickr, Facebook fazem questão de anunciar publicamente fotos de seus escritórios cheios de puffs e sofás extravagantes, com pessoas trabalhando de bermuda e chinelo.
Bruce Eckel define a raiz de todos os problemas no desenvolvimento de software como sendo humanos:
We are in a young business. Primitive, really — we don’t know much about what works, and we keep thinking we’ve found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.
A man I’ve learned much from, Gerald Weinberg, wrote his first couple of books on the technology of programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying “no matter what they tell you, it’s always a people problem.”
Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it’s all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.
As fábricas de software ainda colocam os processos acima das pessoas, numa tentativa de produzir sistemas independentes do intelecto humano. Como se isso, fosse possível.
Mas …
Felizmente existem pessoas que não pensam dessa forma. E muitas outras metodologias vem ganhando espaço no mercado. Acho que ainda estamos apreendendo a desenvolver software e muito ainda está por vir. Mas algumas empresas já perceberam que algo está errado. Por isso, acredito que o mercado sempre irá se ajustar, fazendo a seleção do que realmente é melhor, e condenando, empresas que visam apenas o curto prazo e lucro imediato.
Tags: fábrica, metodologia, software
