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!!!
12 de outubro de 2008
Exorcisando o RUP
Assinar:
Postar comentários (Atom)
Assinar Feed
Postagens
Comentários
3 comentários:
É interessante a maneira como as pessoas ficaram traumatizadas com o RUP. Normalmente, descrevem um projeto com trezentos Casos de Uso e afirmam que antes de mesmo de terminar a análise de todos os UCs, o projeto foi decretado como virtualmente impossível. Em outras palavras, o projeto só produziu papel!
Trezentos UCs... são UCs mesmo?!! Só produziu papel... é um projeto iterativo mesmo? Pouco provável.
Para usar XP, em minha opinião, existem premissas bem definidas, por exemplo, para termos apenas o código como modelo é necessário: umas linguajem OO para apoiar abstrações aderentes ao negócio, tecnologias que resolvem questões como persistência e transação (JPA, Spring), uma equipe generalista, entre outras questões.
Diferente do RUP, que possui muitos papéis, tarefas, disciplinas para montar soluções em contextos diferentes (tecnológica, equipes geograficamente distribuídas). Inclusive pode ser ágil.
[ ],s
Concordo com você Rodolpho, o RUP pode perfeitamente ter uma cara ágil se o cliente desejar. Mas nesse caso, porque eu deveria gastar milhões com a IBM se eu posso contratar a Caelum, a Fratech, a Aspercom (entre outras), que irão me mostrar como desenvolver software de forma ágil com um custo total de consultoria e ferramental bemmmmmm menor? Afinal, SCRUM, XP, kanbans, post-its e wikis são bem mais baratos do que consultores IBM, Rational Method Composer, Rational Software Architect, etc :)
É isso aí Ugolini. Concordo inteiramente com você. Infelizmente o mercado deturpou completamente o RUP e o processo unificado como um todo.
Sempre defendi que o RUP pode ser adaptável ao ponto de se tornar um processo tão ágil quanto os outros.
O mais importante são as práticas utilizadas e as pessoas inseridas no processo. As pessoas se esquecem que cada projeto tem suas diferenças e o RUP serve para todos esses contextos.
[],s
Postar um comentário