Não é de hoje que eu ando desiludido com área de engenharia de software e suas sub-áreas, principalmente falando em pesquisa. A engenharia de software, tal qual é difundida, remete à busca de uma verdade absoluta (mesmo que temporária) e de uma certa perfeição na arte de conduzir pessoas. No entanto, neste caso, esta verdade global não existe, não pode ser consolidada e muito menos reproduzida. Não é ciência, é arte. A perfeição depende de tantos fatores que a torna inviável no caso geral. E, apesar de saberem disso, diversos autores remetem a suas criações como verdades absolutas, apresentando algumas pequenas assumptions que ofuscam alguns requisitos bem maiores. Foi assim com XP, Scrum e RUP e será assim, por muito tempo.

Por exemplo, Kent Beck é bem claro ao dizer que XP serve para equipes pequenas. No entanto, esquece de mencionar que não é qualquer equipe pequena. É uma equipe pequena, motivada, atualizada (provavelmente jovem) e com Kent Beck como coach. Veja bem, XP, Scrum e RUP não são nada. Eles podem funcionar ou não, em qualquer lugar, qualquer mesmo, só depende das pessoas, do perfil, de sua motivação. Então, o que é mais importante, o coach ou a metodologia? Um projeto de software não falha ou tem sucesso por causa da metodologia. O projeto falha por causa do coach, do líder, do gerente e de sua equipe. Quantas vezes é mais difícil manter uma equipe motivada do que implementar de fato a XP? Muitas. Então, se o coach e suas ações são o mais importante, não faria mais sentido focar nele ao invés do processo usado por ele?

A reproducibilidade das teorias criadas é outro fator que me incomoda. Em computação gráfica, por exemplo, se eu apresento uma tese e alguns resultados, independente se há pessoas envolvidas ou não, sou obrigado a descrever as condições exatas que aqueles resultados foram obtidos, permitindo que outras pessoas possam gerar o mesmo resultado. Não estou dizendo que existe uma " Silver Bullet " em computação gráfica, por isso mesmo deixamos claro as limitações das técnicas, as variantes envolvidas e os possíveis reflexos de uma implementação que não segue a risca o que foi descrito. A diferença entre as áreas aparece quando alguém tenta seguir a risca o que está escrito, em uma você tem sucesso, a outra, fracasso. Não estou dizendo que deve haver uma solução para todos os problemas, mas para que dado um problema específico, muito específico, exista uma solução que não falhe.

Até hoje, eu ainda não encontrei uma única empresa que implemente a XP tal qual descrita pelo Kent Beck. Todas elas fizeram adaptações, algumas funcionaram outras não. Isto significa que: (i) Kent Beck não descreveu completamente seu " ambiente de execução " por isso ninguém consegue reproduzí-lo (e não conseguiriam mesmo que ele descrevesse) ou (ii) a metodologia não é um caso geral, mas sim específico, pois só funciona onde foi criada (se realmente funciona). Se ela necessita de adaptações, de um Kent Beck como coach, por que não foi descrito no documento publicado? A primeira versão do XP Explained o Kent não falava sequer em adaptação, nem a do RUP (Tanto que deu muita discussão por aí sobre quem pode dizer que está usando XP). Adaptação de metodologias surgiu quando RUP começou a cair. Aí o povo se tocou que há muito mais por trás do desenv. de software do que uma simples metodologia.

No mais, é impressionante a quantidade de " casos de sucesso " que são publicados e apresentados. Casos de sucesso não são mais do que propaganda positiva para o líder daquela equipe. Veja bem, daquela equipe. Se você tentar replicar as condições daquele caso de sucesso, você e seu projeto falharão. Se o próprio líder repetir o projeto, com a mesma equipe, também vai falhar. Engraçado, não? Para que estudar algo que não poderá ser utilizado? Imagino que as pessoas que vão para essas palestras, ou leem estes documentos, procuram desculpas para também usar a metodologia ou a ferramenta em discussão. Algo como uma aposta: " se ele usou e funcionou, porque não iria funcionar comigo? " Aparentemente querem copiar o caso de sucesso de alguém, mas, lá no fundo, já sabem que não vai funcionar. Não vai funcionar porque o mundo já mudou, as ferramentas que ele usou só funcionarão com a liderança exata que ele exerceu. E estas condições, não podem ser medidas.

Se manter atualizado com os recursos a disposição é importante, porém não mais importante do que manter elevada a sua capacidade de entender e conduzir as pessoas. Eu gostaria de ver a Engenharia de Software ser sempre apresentada como ferramenta, e não como uma solucão.

PS: Da forma como está descrito hoje, o Scrum, por exemplo, não prevê saída para problemas como esse.