Olá povo, estou aqui para continuar a serie de posts sobre a minha experiência com RUP, no ultimo artigo eu falei sobre a minha antiga empresa e o que aconteceu com ela quando resolveram adotar essa metodologia, expliquei as dificuldades que enfrentamos e ainda que essa mudança não foi uma boa escolha, pois o sistema não foi entregue e a maturidade da empresa não era satisfatória para essa metodologia.

Agora vou falar sobre a minha atual empresa e as dificuldades com essa metodologia, mas antes vou ressaltar que o intuito principal dessa serie de posts não é esclarecer o que é o RUP nem levantar uma bandeira contra ou a favor dessa metodologia somente quero compartilhar minha experiência com a mesma.

Perfil da empresa:

A empresa que estou trabalhando é uma multinacional de grande porte, do tipo que nem conheço metade do povo que trabalha na mesma divisão que eu, ela utiliza o RUP há muitos anos, sendo que possuem o IBM Rational como recurso adicional para o gerenciamento dos artefatos do mesmo,  aqui nós utilizamos todas as documentações que a metodologia prevê, sempre voltadas as Demandas ou seja cada alteração em um ou “n” sistemas, gera uma demanda e a mesma tem toda a documentação responsável por dizer o que tem que ser feito, o que vai ser alterado e o que o cliente espera receber nessa demanda, não há uma centralização de documentação do sistema.

Para explicar melhor vai um fluxograma simples com uma visão bem macro (bem macro mesmo) dos procedimentos:

Cada passo descrito acima tem um ou vários documentos entregáveis, sendo que para evoluir há sempre o “De acordo” do cliente, a entrega das alterações são feitas em interações e o prazo para finalização total de uma demanda simples gira em torno de 3 meses.

Pontos Fortes

• Há um envolvimento pleno do cliente, pois o mesmo visualiza e aprova todos os passos do projeto
• Antes de mandar a demanda para TI o Consultor verifica se a necessidade do cliente dá para ser suprida por algum procedimento simples eliminando assim um desenvolvimento desnecessário
• Antes de envolver os sistemas o arquiteto verifica se há em algum sistema a funcionalidade desejada
• O arquiteto decide em qual sistema pertence a alteração dando assim maior lógica e especialidade aos sistemas
• São feitas varias  entregas descobrindo antes de finalizado se há uma discrepância no que o cliente recebeu e o que ele esperava receber.

Pontos Fracos:

• Primeiro ponto fraco é que o fluxograma acima é Macro, sendo que há muitos outros passos a serem realizados e muitas outras documentações
• Uma demanda simples (acrescentar um campo de classificação) demora até 4 meses para entrar em produção.
• É extremamente caro manter esse esquema de trabalho, sendo necessários inúmeros profissionais e inúmeros documentos
• A linha que divide o que deve ser escrito em um documento ao que deve ser escrito em outro documento, as vezes é tão pequena que acabamos tendo documentos muito semelhantes.
• Apesar do envolvimento do cliente o mesmo não tem muita capacidade de decisão, pois aonde vai ser feito e o que vai ser feito fica a cargo da equipe de TI dizer (alguns Analistas aceitam sugestões do cliente)
• O orçamento é realizado apenas 1 vez  na faze de estimativa, fazendo com que tenhamos que acrescentar 10 a 20% para cobrir eventualidades no projeto
• Caso o cliente queira algo simples como mudar o nome de um campo já especificado o desenvolvimento deve retroceder ao inicio atrasando assim ainda mais a data de entrega, e aumentado ainda mais os custos de manutenção.

Então povo, esse post acabou ficando muito grande vou deixar a conclusão para o próximo e ultimo post sobre o tema, te vejo lá