12 de outubro de 2008

Exorcisando o RUP

3 comentários

Decidi criar uma série de posts para desmistificar o (mal afamado) Rational Unified Process. A motivação nasceu depois de ouvir um monte de bobagens tanto de pessoas que aplicam no dia a dia quanto de pessoas que tem pré conceitos e nunca aplicaram o processo. Entre os preconceituosos encontro pessoas que tem verdadeira ogeriza ao termo RUP.

1o MITO: O RUP é pesado

A expressão nasceu em contrapartida ao termo "lightweight" (leve). Mas o que, afinal, é um processo "pesado"? Refere-se a burocrático? Lento? Incapaz de absorver mudanças? Com foco "nos meios" e não no fim?
Se "pesado" referir-se a um destes adjetivos, afirmo categoricamente: o RUP não é pesado.
A justificativa curta é: o RUP pode ser tão "leve" quanto necessário. No livro "Agile Software Development", Cockburn afirma que projetos grandes devem ser suportados por processos com cerimonial "menos leve" e que o processo sempre deve ser adaptado. O RUP é totalmente adaptável.

2o Mito: O RUP tolhe o desenvolvedor

O RUP define papéis, muitos (mais eu gostaria, é verdade) e um deles é "implementer" ou implementador. Você deve ter pensado: olha aê! Tá me reduzindo a um reles digitador.
Antes de mais nada deixa eu lembrar você de uma coisa: desenvolvedor, no linguajar do mercado, é o cara que põe a mão na massa e cria o software. Isso é um CARGO ou POSIÇÃO, como queira. O "implementer" do RUP é um PAPEL. Ou seja, o Desenvolvedor (cargo) preenche o papel de "implementer". Dentre outros! Isso mesmo, o cargo/posição do desenvolvedor deve ser mapeado para os papéis do RUP. Isto é a tal "adaptação" do processo.
Numa empresa que queira tomar uma abordagem "ágil", por exemplo, o desenvolvedor fará os papéis de: Requeriments Specifier/Reviewer, Software Architect/Reviewer, Designer, Implementer e Tester. Só para citar alguns.
Pô mas isso é muita coisa! Claro que é? Por acaso você trabalha pouco?
Acontece que grandes empresas (principalmente) estão em um processo furioso de terceirização e as "áreas de metodologia" dividem o jogo entre os que especificam (os analistas) e os programadores (os que codificam). O RUP, por ser o processo formal mais adotado hoje em dia, acaba pagando o pato pois o processo desenhado pela a empresa foi "inspirado/baseado" no RUP.

Bom, este é só um começo. Tenho dezenas de outros mitos a detonar. Caso tenha alguma idéia, por favor comente.

Abraço!!!