RUP Classico, e problemas com os ultimos projetos

Prefacio :
Desde que deixei o pais onde eu utilizava Metodologia Agil (Agile Methodology), estou sendo obrigado a trabalhar com o RUP Classico e acredite nao e facil, sei que muita gente nao consegue acreditar que ser Agil e possivel com projetos maiores e mesmo grandes, tambem muitos tem dificuldade ou simplemsnte nao conseguem idealizar um projeto sem o Ghant Chart do MS Project ou similares. Eles colocam um monte de impecilhos bem classicos de pessoas que somente conhecem uma metodologia ou uma parte de uma cidade e falam que a outra parte nao presta, mesmo sem conhecer, ou seja eles passaram a vida toda fazendo somente uma coisa nesse caso o RUP e infelizmente perderam a criatividade e imaginacao em como resolver as coisas de modos diferentes, mas continuam a achar que aquela verdade deles e a absoluta e imutavel.
Uma coisa que acho muito interessante em trabalhar como Arquiteto e Desenvolvedor e que isso tudo tem muito a ver com a vida em si. E como voce planeja tirar uma certificacao, ou comprar um carro ou mesmo atingir um objetivo, voce pensa em varias maneiras possiveis, claro que existe os Patterns para cada coisa da vida bem como para cada coisa em projetos de TI, mas prefasiando… existe varias maneiras de se partir do ponto A e chegar ao ponto B. Na verdade existe milhares de possibilidades de se fazer isso, tem pessoas que esmeram fazer o melhor que eles podem ate o momento, digo ate o momento pq esse tipo de pessoa sao os autoditadas, e parae les perfeicao e um estado que somente existe no nirvana, eles estao sempre aprimorando, e aprendendo novas coisas, e se voce quer saber sao eles a roda que move o mundo. Depois temos a classe das pessoas normais que somente aprendem alguma coisa via cursos e faculdades e ficam naquilo por anos, e por fim aquele cara que entrou nessa so para ganhar dinheiro, e infelizmente hoje em TI temos rios de pessoas assim, pior alguns em cargos de gerencia e como Gerentes de Projetos. Sao pessoas que estudam muito, na visao deles, pq em TI nunca estudar e muito, pois passamos a vida inteira como um fisico somente estudando e aprendendo, e depois eles passam em uma entrevista de emprego e e ai que os problemas comecam para todos aqueles que estao embaixo dele. Nao sei se voce que esta lendo isso sabe mas o RUP - Rational Unified Process foi criado pela antiga Rational hoje IBM para a Boeing para melhorar a linha de producao dequela fabrica de avioes nos anos 50!
Agora vamos fazer uma comparacao bem rapida… Linha de montagem de avioes dos anos 50 com producao de software no seculo 21!!! Alguem ai consegue ver algo que se conecta?????
Bom repetindo o que vem sendo dito e repetido a tempos “Software nao e como fazer pontes, onde voce na verdade faz somente uma e todas as outras sao copias dela, software e um processo dinamico, criativo e sempre ira ser diferente”
Eu ate hoje com quase 20 anos de TI nunca vi um projeto se igual ao outro, ja vi similares, mas igual nunca, tambem nunca vi, nem a aquipe de desenvolvimento e nem os Gerentes de Projeto lendo documentacao antiga ou mesmo se baseando em projetos antigos para se crier um novo. ISSO NAO EXISTE!
Portando se nao deveria mais existir isso em desenvolvimento de software.


Indo para o que interessa :
Aqui agora vou citar e dar exemplos dos maiores problemas por que meu time passou usando RUP Classico.
Primeira e do meu ponto de vista e um dos mais cruciais pontos, e que ninguem tem um dominio complete nem conhecimento completo do sistema, ou seja muito das integracoes sao feitas na base do bom senso e em suposicoes, isso e terrivel para qualquer area, ja pensou um engenheiro civil ter que contruir aquela ponte do comeco baseado em suposicoes e bom senso o que iria acontecer?
Depois vem a qualidade das informacoes, visto que nao temos contato com o Analista de Sistemas e somente alguns com os famosos Analistas de Negocios, as especificacoes vem muitas vezes com falhas de logica no processo graves e ninguem sabe como resolver isso, e mais uma vez temos que usar bom senso e suposicoes para resolver isso.
Os desenvolvedores tem que fazer a revisao das especificacoes que sao atribuidas pelo GP, como e possivel um pessoa que nao tem ideia do que esta acontecendo fazer revisao de uma especificacao, que pode conter falhas graves, e apontar erros?
E o ultimo dos piores e as constants novas versoes que eles ficam produzindo das especificacoes, ou seja constants mudancas no codigo tambem.
Agora olhando o RUP que tem 4 fases distintas que sao : Concepcao, Elaboracao, Construcao e Transicao.
Nao e preciso nem ter mais um nivel de profundidade em cada uma dessas para ver que isso nao funciona.
Concepcao : Comecando com uma pergunta. Para que concepcao? Qual o objetivo de ser ter uma vaga ideia do que se quer? Somente para amadurecer depois? Desde que o mundo e mundo qdo vc procura uma solucao e pq vc ja tem um problema certo! Entao concepcao e uma fase que deve ser boa para engenheiros civil, aeronautico e outros afim, que nao precisa fazer uma analise para ter comecar a conceber alguma coisa, ele que recebe um requerimento para algo. Ex: Aviao X, devera levar 2 pilotos, atingir velocidade de Mach 2.5 sem pos combustores, ter um teto absolute de 100.000 pes,velocidade ascencional de 18.000mts/min. , ter uma carga de armas de 20ton., ter um radar com capacidade de descoberta entre 60mts a 25km the altura, rastrear 20 alvos simultaneamente, e ter um raio de acao de 2500km.
Ai sim e valido essa ideia de concepcao, mas para software, e diferente, pq primeiro vamos ver como os processos sao feitos, levantar o que pode ser otimizado e informatizado, depois olhar a fundo em todos os processos e como funcionam, o que nao tem nada a ver com concepcao e sim com Analise, que ja devera ser a proxima etapa.
Elaboracao: E aqui que no RUP o projeto vai comecar a tomar forma. Mais uma pergunta tomar forma? Voces conhecem algum analista de sistmas que te da alguma forma de um sistema? Isso e tao furado que ate se vc procurar no Wiki (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process), vc ira ver essa palavra forma la. Nao exister dar forma e ver possiveis erros do sistema, o que existe e o analista ir fazer os levantamentos dos requisitos e problemas que sao enfrentados atualmente e depois prover uma solucao para esses problemas usando uma solucao informatizada ou nao. Me desculpem, mas eu nao consigo ver nenhuma forma de sistema ate aqui. Mais ainda, para que o sistema seja coerente e bem escrito e fundamental que o analista participe ativamente do desenvolvimento, e tenha bons conhecimentos do que ira ser usado no sistema, como linguagem, frameworks e etc, pois com isso ele epode fazer uma analise voltada para os pontos fortes de cada um desses items que serao usados, e ja prover como contornar e resolver problemas decorrentes dos pontos fracos desses items. E isso acreditem faz toda a diferenca entre um sistema que ira dar um bom ROI e o que nao vai.
Mais uma pergunta ue nunca tem resposta. Como e possivel um analista que nao sabe para o que ele esta elaborando isso, nem que linguagem ou ferramentas irao ser usadas, nem o nivel do time que vai trabalhar, passar tudo que ele viu e imaginou e as solucoes que ele esta propondo, por escrito, para um time que vai tentar resumir, preste atencao e isso mesmo resumir, o que ja deveria ser um resumo ed como a empresa trabalha. Como ira ser possivel que todas as informacoes pertinentes irao de fato estar la? Nao e possivel, a nao ser que eles passem a analise inteira como especificacao, pior, o que acontece muito e que eles dividem as tarefas de um processo maior sem lever em conta que muita coisa esta interconectada. E ai muito se perde dos processos e eles ficam imcompletos e mais, precisando de uma manutencao assim que o projeto termina. O que e ridiculo. Ja pensou assim que vc inaugural ponto, vc a fecha para refazer algumas partes pq nao era bem isso o que a prefeitura precisava?
Construcao: E aquii que a lambanca comeca, sem contato com o analista e com um resumo do resumo em mao mais, diga se menos ne, um suporte para duvidas que se baseia somente no que esta escrito e nada mais, como e que voce pode criar uma boa arquitetura de projeto e mesmo codigo coerente com o que realmente ira ser necessario para que se resolva aquele problema do inicio? Como voce vai interconectar as partes que for a separadas, sem criar redundante codigo, e muitos copy and paste? Melhor como voce pode criar uma arquitetura baseando somente em resumos do resumo e ainda por cima com somente uma parte do sistema que ira ser feito passado a voce? Em 100% dos casos se voce quizer fazer algo no minimo descente ira ser preciso um conhecimento mais amplo par aver o que podera ser reaproveitado, que patterns usar, ou criar. Vendo isso, e bem dificil voce ter alta coesao e baixo acoplamento. O que o codigo faz e o reflexo do que foi passado ao time de arquiteto e desenvolvedores, se foi passado partes voce somente pode aprimorar partes, que nao que dizer que irao ser bem e irao corresponder com as espectativas de solucao requeridas na primeira fase. O mais legal e os testes serem aplicados com base nessa documentacao… ou seja muito do que realmente deveria ser testado nao e.
Transicao: Isso e com a parte do pessoal de producao, e eles reclamam bastante, que o codigo nao tem o merge com as outras partes que eles esperam e isso tb toma muito tempo ate que eles tenham o fine tuning.

Claro que ha muito mais problemas que isso, e tambem ira aparecer pessoas que vao falar algo mais ou menos assim “ahhh!! Mas sua emrpesa nao implementou isso ou aquilo e eram fundamental para que seu projeto tivesse sucesso”. Para essas pessoas que pensam de modo similar ou igual e facil resolver isso para provar que RUP nao funciona. Se coloque na posicao do dono da empresa e veja o ROI e a solucao entregue usando RUP e AGILE… garanto que a segunda vai ser mais rapida, barata e ira agregar muito mais a sua empresa do que a primeira, fora que a segunda vai ser a que mais vai se parecer com o que vc tinha em mente do que a primeira.
Nao estou falando que a IBM ou seus produtos nao prestam, pelo contrario, eles tem excelentes produtos e servicos, mas sendo especifico com a metodologia e a producao de software, o RUP nao funciona. Porem e muito bom para o ROI da mesma, pois com isso eles vendem mais ferramentas que na verdade nao agregam muito a producao de software em si e mais como meios de ‘controles’ para as terefas que cada professional em cada etapa usa , recebem por contratos mais longos, suporte e ainda vendem cursos para treinar essas pessoas para aquelas ferramentas. E um Mercado todo novo e rentavel.
Tambem vale frisar que Agile nao e a solucao unica para todos projetos do mundo, pois certos times que nao possuem o feeling, organizacao ou mesmo o nivel de conhecimento necessario para a tarefa nao irao conseguir entregar algo de qualidade.
Com isso finaliso contando problemas que enfrentei quanto a metodologia e o que acarretou para o desenvolvimento. O que acho mais incrivel e que este e meu terceiro projeto aqui, usando a mesma metodologia no terceiro lugar diferente, e todos carecem dos mesmo problemas em maior ou menor grau.
Por fim vale lembrar aqui que RUP e muito bom para pessoas limitadas e nao para os autodidatas, pq com isso eles se sentem bem com o pouco que sabem, nao precisam ficar correndo atras para aprender mais, pq eles estao trabalhando como maquinas mal programadas e faz com que eles tenham orgulho em dizer que so sabem fazer isso ou aquilo, qdo o certo seria que eles tivessem orgulho em dizer, hoje estou fazendo isso, mas amanha aquilo e depois quem sabe, pois estou crescendo como pessoa e como profissional. Quando forem implementer um codigo, um projeto ou mesmo projetos de vida lembrem-se que ha milhares de maneiras diferentes de se chegar la, umas melhores outras nao tao boas, porem muito vai depender da situacao naquele momento e na sua visao para o futuro.