Olá pessoal. Acabei ficando um longo tempo sem escrever, tenho estado anormalmente ocupado nestes últimos meses. Junho foi um mês muito complicado, com as paradas para a Copa do Mundo e a presença no Agile Brazil – isto sem falar em alguns projetos críticos sendo entregues e o tempo dedicado a novos projetos. Com isto, na White Fox, passamos o mês bem sobrecarregados e só agora em Julho é que começamos a voltar ao ritmo normal. Finalmente agora volto a ter um pouco de tempo para escrever alguns artigos!

O evento Agile Brazil foi muito bom. Contou com a presença de grandes nomes do desenvolvimento mundial, como o Martin Fowler e o Philippe Kruchten. E foi excelente pra fazer contato com o pessoal da comunidade .NET do Brasil. Mas este post é sobre algo que conversei bastante com outras pessoas lá e que gera sempre discussões “acaloradas” toda vez que é levantado em uma roda de desnvolvedores (ou em listas de desenvolvedores como a excelente dotnetarchitects): qual o melhor “jeito” de desenvolver software.

Com a aceitação cada vez maior das metodologias ágeis, a minha impressão era que a comunidade estaria mais tranquila sobre metodologias e técnicas para desenvolvimento. Elas sempre evoluem, claro, mas pelo menos em linha gerais, estaríamos em um caminho mais definido. Mas o que eu vejo é que ocorreu algo diferente, uma profusão de metodologias e técnicas e de pessoas que pregam que determinada linha é muito melhor do que qualquer outra. Acho que isto piorou ainda mais porque o modelo “waterfall”, hoje praticamente execrado pela maior parte dos desenvolvedores “modernos”, foi pintando como o maior vilão e origem de todos os males e que a metologia XXX ou YYY chegou para resolver isto!

Longe de mim defenter o uso de waterfall, na maior parte dos cenários. Mas, apesar de todos os problemas e falhas deste tipo de desenvolvimento, o fato é que até hoje temos muitos e muitos exemplos de sucesso,  e que continuam a acontecer ainda hoje. A palestra do Kruchetn foi muito boa neste aspecto, ele citou justamente esta “demonização” do waterfall como um sinal de que nem tudo está bem.

E para quem está começando, eu tenho notado, em geral, uma total confusão. Como as universidades estão alguns ciclos atrás (a maior parte delas ainda prega o waterfall como única e melhor maneira de desenvolver) e sem ter a experiência de ter passado por sucesso e falhas em determinada metologias, os iniciantes ficam sem saber que caminho seguir: Waterfall? nem pensar! Scrum? Como viver com todos os scrum-buts? XP? Como aplicar no meu dia a dia? Isto sem falar nas múltiplas variantes técnicas da construção em si, onde entra TDD, BDD, DDD etc., aliada a uma miríade de plataformas, frameworks, ORMs etc. E sem nem entrar no mérito de linguagens em si, onde temos novamente uma outra gama de escolhas como C#, C++, Java, Rubi, Python etc. E em todos estes, temos muitos “gurus” que afirmam que aquilo é o supra-sumo da agilidade e é a melhor invenção do mundo deste a pólvora, sendo a única maneira de fazer software bem. Realmente é difícil não ficar confuso. Felizmente temos algumas vozes de bom senso, como o Alistair Cockburn, no seu “Juramento de Não-Lealdade”, que talvez comecem a melhorar este cenário.

Na minha visão, escolher uma forma de desenvolver não deveria causar tanta dificuldade. É certo, desenvolver software é algo complicado, exige um misto de dedicação, talento, experiência e muito, muito estudo. Mas, em toda a minha experiência, o que eu tenho visto é que as pessoas que se eforçam para se tornar bons codificadores acabam o sendo de uma maneira geral. Ou seja, um bom programador em C# vai ser um bom programador em Python (claro que uma transição não é simples, pelo volume de novas informações, mas se isto for desejado ou necessário, vai acontecer). Ou seja, os princípios básicos, o cuidado e o gosto pelo que se faz, são fatores mais importantes no sucesso do que qualquer linguagem metodologia, tecnologia ou plataforma que exista. E pra mim, isto vai continuar sendo assim mesmo com o todo o nosso ritmo de evolução… (acho que só vai parar o dia que pudermos solicitar um programa verbalmente e o próprio computador  o gerar… ou seja, daqui a muito tempo!). Óbvio também que nada existe sem contexto, isto é especialmente válido para desenvolvimento de software. Assim, levando em consideração o contexto, algumas escolhas podem levar a uma maior produtividade do que outras.

Para tentar ajudar nestes dilemas, resolvi escrever este e mais um artigo sobre desenvolvimento, e como eu o vejo. Vou colocar alguns princípios que adoto, na medida do possível, de onde eles vieram, e como eu vejo a inserção de toda esta parafernália metodológica/técnica no meu processo de desenvolvimento. Meu objetivo é tentar defender a idéia mais importante dos princípios ágeis, de que pessoas são mais importantes do que qualquer processo, metodologia ou ferramenta, e que os principios básicos ainda são comuns a qualquer atividade de desenvolvimento. Vou também colocar um pouco do meu contexto, para justificar algumas escolhas que faço e como isto afeta a nossa produtividade.

Até a próxima!