Muito legal seu texto e esse resumo histórico que vc colocou com suas experiências. Sou também um desenvolvedor da década de 90 e passei por algumas coisas parecidas. Gostei principalmente da sua análise sobre as más interpretações que as pessoas fazem dos novos conceitos que surgem. E é incrível como geralmente são essas pessoas que estão em posição de decisão nas empresas.

Não sou nenhum especialista em RUP e muito menos em métodos ágeis mas com uma lida no livro do Craig Larman – Utilizando UML e Padrões – acho que compreendi bem o espírito do PU de iterações, abraçar a mudança, não planejar muito para o futuro porque será apenas meras especulações e feedbacks constantes. Quer dizer, logo na primeira leitura aquilo foi uma iluminação pois tudo faz muito sentido e não compreendo como alguém pode interpretar tudo tão equivocadamente a ponto de de dizer que “na fase de concepção deve-se levantar todos os requisitos”. Acho que essas pessoas têm severos déficits de comprensão de texto e saem por aí falando bobeiras. Na empresa onde trabalho recentemente foi adotado o RUP como processo visando atingir o CMM nivel 2. Foi incrível o número de controvérsias e más interpretações e no final foi gerado um processo pesado e burocrático (como se fosse isso que o CMM prega).

Sou um afiquicionado por OO e acho que compreendo bem os conceitos de modelagem. Gostei quando vc diz: “A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.” As empresas adotam Java acreditando que terão automaticamente as vantagens da OO mas o que vejo ser produzido nos projetos são códigos mal projetados (com métodos extensos e classes sem significado) e nenhuma preocupação em modelarem o domínio da aplicação. E o pior que no final, como todos os artefatos foram produzidos, eles acham que o produto tem uma ótima qualidade. Bullshit!

A meu ver o código é o artefato mais importante gerado e isso tem que ser feito com todo o cuidado e dedicação. Um bom código é auto-explicativo, dispensa documentação e pode ser alterado sem muita dificuldade. Por isso penso que as atividades de anáilse e projeto deveriam ser as mais valorizadas e intensificadas com terinamento nas empresas. O grosso do trabalho de desenvolvimento, e também a parte mais difícil, é um bom projeto e é nisso que as empresas deveriam apostar suas fichas, mehorando a habilidade de seus programadores em analisar e projetar.

Recentemente vc esteve em minha cidade, Campo Grande, dando um treinamento organizado pelo Lucas (Landir). Na ocasião não pude participar mas quem sabe no próximo.

Continue o bom trabalho e até a próxima!

Nem tanto pelos conceitos que ele apresentou mas por me fazer relembrar os anos 90, principalmente os clientes! Foi uma volta ao passado, as horas junto com grupos de desenvolvedores comendo amendoim e tomando coca-cola, um ajudando o outro e todo mundo jogando “karateka” ou “Lost World” na hora do almoço!

E tinha os clientes malas que toda hora tinham uma idéia nova para o sistema. Me lembro de uma secretária já senhora que desceu umas três vezes até o “CPD” para me pedir uma alteração em um relatório, na quarta vez eu disse: “Senhora, isso aqui não é fast-food de programa não!” Foi um auê, tive que falar com o diretor e tudo mais.

Saudades dessa época em que desenvolver era pura diversão, fazíamos porque gostávamos da coisa.

Obrigado Rodrigo.

Resumindo: O que vale não são as técnicas, diagramas ou ferramentas mas sim os princípios.
Desde que os princípios sejam bem compreendidos, vc pode até inventar uma metodologia XPTO e chamar de ágil que funcione para a sua empresa.

Aliás antes do Tonhão, a Toyota ja utilizava esses princípios há mais de 30 anos. Leia o livro ‘O Modelo Toyota – The Toyota Way”.

Parabéns pela matéria, me fez retornar àquela época em que fui desenvolvedor no final dos anos 80 e inicio dos 90.

Naquela época o desenvolvimento de software era divertido mas sem deixar de ser responsável. Fazíamos software como se estivessemos escrevendo um livro ou pintando um quadro, era feito por paixão e não por um real à mais no valor/hora.

Sei que isso vai soar como algo surrealista, mas vale a pena perguntar para quem viveu aquela época dentro de empresas desenvolvendo sistemas com dbase, clipper, c(ansi), delphi, vb 3, pascal e etc.

Eu acho que vale a pena resgatar esses assuntos, não como saudosismo, mas sim como conhecimento de como as coisas funcionavam muito melhor.

De qualquer forma o que vale sempre é o bom senso de se analisar cada projeto com suas peculiaridades e definir de forma pensada e inteligente a maneira mais adequada de tocá-lo. A tal busca de respostas fáceis que você citou se traduz em erros fatais na condução de projetos.