A maioria dos projetos de software fracassa. Mas isso não significa que o seu tenha que falhar. A primeira pergunta que o senhor deve fazer é uma pergunta enganosamente simples: qual é o tamanho? Steve McConnell explica em Software Estimation (Estimativa de software): Desmistificando a arte negra:
[For a software project]O tamanho é facilmente o fator determinante mais significativo do esforço, do custo e do cronograma. O tipo de software que o senhor está desenvolvendo vem em segundo lugar, e os fatores pessoais vêm logo em seguida. A linguagem de programação e o ambiente que o senhor usa não são influências de primeiro nível sobre o resultado do projeto, mas são uma influência de primeiro nível sobre a estimativa.
Se todas as outras coisas forem iguais, os grandes projetos tendem a fracassar. Isso provavelmente não é novidade para quem conhece o Lei de Metcalfe e Deseconomias de escala.
Portanto, se os três fatores mais importantes que determinam o resultado de um projeto de software são…
- Tamanho do projeto
- Tipo de software que está sendo desenvolvido
- Fatores pessoais
… nessa ordem, o que mais falta? Se conseguir controlar esses três fatores, se estiver desenvolvendo um site de banco de dados CRUD pequeno e simples com uma equipe dos sonhos de desenvolvedores superestrelas bem unidos, já está tudo pronto? É claro que nunca há nenhum garantia de sucesso do projeto, mas o senhor pode pelo menos dizer que realizou um gerenciamento de riscos adequado?
Não tenho tanta certeza. De acordo com Bill de hra, o senhor também precisa considerar os três pilares:
A conclusão a que chego com isso e com minha própria experiência de migrar meu quinhão de árvores de código-fonte é que o sistema de controle de versão é um efeito de primeira ordem no software, juntamente com dois outros: o sistema de construção e o rastreador de bugs.
Essas escolhas afetam absolutamente todo o resto. Coisas como IDEs, em comparação, não têm importância alguma. Até mesmo a escolha da metodologia pode ter menos importância. Embora eu aposte que há muitas equipes de software e gerenciamento por aí que veem o controle de versão, os sistemas de compilação e os rastreadores de bugs como algo incidental ao trabalho, e não como ferramentas essenciais.
A análise de Bill foi uma surpresa agradável para mim, porque é exatamente a mesma conclusão a que cheguei quando trabalhei com o Sistema de equipe da Microsoft. Quando o senhor tiver os três pilares estabelecidos…
- Controle de versão
- Rastreamento de itens de trabalho
- Sistema de compilação
… é uma grande melhoria na qualidade da engenharia de software para qualquer projeto de desenvolvimento de software. É claro que o senhor não precisa usar o Team System para chegar lá, mas um enorme parte da proposta de valor do Team System é que ele é “engenharia de software em uma caixa”. Ele oferece uma forte integração entre essas três peças pré-instaladas, sem a necessidade de configurações complexas.
Seja como for que o senhor chegue lá, é simplesmente uma boa engenharia de software ter esses elementos essenciais – os três pilares – em vigor antes de ir muito longe em um projeto de software.
Então, se montarmos a equipe dos nossos sonhos de desenvolvedores superstars bem unidos trabalhando em nosso pequeno e simples site de banco de dados CRUD com um excelente conjunto integrado de controle de origem, rastreamento de itens de trabalho e ferramentas de compilação, já terminamos? Será que mitigamos todos os principais riscos do projeto e nos preparamos para trabalhar sem esforço e sem peso? cair no poço do sucesso?
Infelizmente, não.
Bill observa que escolher uma estrutura pouco adequada ao seu domínio de problemas também pode ter um efeito paralisante em sua produtividade.
A verbosidade relativa das linguagens de programação não é o mais interessante, tampouco a doutrina de digitação. O que é interessante é a cultura das estruturas e o que as diferentes comunidades consideram valioso. Minha impressão é que, no Java, muitas estruturas da Web – pense em JSF ou Struts 1.x – consideram a Web algo que o senhor contorna usando padrões de software. O objetivo é sair da Web e voltar para o middleware. Ao passo que uma estrutura como Django ou Rails foi criada especificamente para a Web; a integração com a empresa interna não é um objetivo.
O suporte a ETag é apenas um exemplo; há tantas coisas que frameworks como o Rails/Django fazem, desde padrões arquitetônicos em torno do gerenciamento de estado, design de URL, testes, envio de modelos, paginação de resultados, até a coloração de tabelas, que o efeito cumulativo sobre a produtividade é surpreendente. Suspeito que projetar para a Web, em vez de em torno dela, é pelo menos tão importante quanto a escolha da linguagem.
Portanto, talvez a verdadeira lição aqui seja que o sucesso de um projeto de software não tem a ver com fazer uma coisa certa em particular; é a tarefa muito mais assustadora de não fazer nada errado. Isso certamente lhe dá um novo apreço por aqueles raros projetos de software bem-sucedidos que, de alguma forma, conseguiram arrancar a vitória das garras da derrota.