Comments (8)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Papo commented Permalink

Vou começar sendo bem polêmico: sim, o RUP está morto :-) ! Mas, como escrevi em meu post no link http://josepaulopapo.blogspot.com/2009/08/agile-morto-d-us-salve-agile.html também Agile estará morto em algum tempo. O RUP e o Scrum, para mim, são muito similares. Possuem algumas poucas diferenças (como, por exemplo, a ênfase do RUP na arquitetura executável e a do Scrum em fazer o que é de maior valor para o cliente sempre independentemente dos riscos arquiteturais). Porém, os princípios e as filosofias centrais do RUP e do Scrum são equivalentes. O que aconteceu historicamente no mercado é que a vasta maioria das empresas entendeu o RUP de forma errada. A versão anterior do RUP tem culpa nisso? Eu acredito que sim. O problema é que o produto RUP vinha enorme e era requisitado aos clientes que estes customizassem para sua realidade. Além disso, se enfatizava mais os artefatos que os princípios e práticas ágeis que hoje são essenciais para a engenharia de software. No RUP 7.5 isso está mudando. O processo tem um core agile que pode ser acrescido conforme as necessidades de cada organização e projeto. Ter um processo mínimo e crescer a partir daí é o que levou o Scrum ao sucesso. É só comparar com o que ocorreu com o Extreme Programming, que possuía um número muito maior de práticas. Mas, voltando à questão: para mim o RUP ainda possui muito espaço para crescer. Só que os mentores precisam esclarecer que o que mais importa no RUP são seus princípios e práticas pautados em modelos ágeis e que fazer processo cascata com artefatos do RUP não é RUP. Para mim, o RUP ainda faz sentido em projetos médios e grandes porque suas fases acabam ocorrendo na prática. O Scrum possui a iteração zero, por exemplo. Ela nada mais é que a fase de inception no RUP. E em qualquer projeto de missão crítica, sempre será necessário um período para realização de ciclos de alfa e beta testing ou vulgarmente chamadas de homologação. Essa é a fase de transição e que no Scrum é tratado como iterações com objetivo de reduzir o risco de defeitos em produção. Resumindo: Scrum ou OpenUP para projetos pequenos atende como uma luva o novo paradigma ágil. O RUP atenderá projetos de médio a grande porte nesse paradigma. É exatamente o conceito que a IBM Rational promove como Agility@Scale. <div>&nbsp;</div> Abraços! <div>&nbsp;</div> José Papo<br /> http://twitter.com/josepapo<br /> http://josepaulopapo.blogspot.com

2 Leo_Araujo commented Permalink

Na minha humilde opinião eu acho que o RUP foi/é mal-interpretado.<br /> Já li isso em algum lugar: o RUP é como uma prova de um terno e não o terno. Para se tornar o terno, ajustes devem ser realizados.<br /> Eu tenho feito adaptações, por exemplo, da fase de elaboração para cada projeto que inicio.<br /> Se estou fazendo uso correto do RUP? Não sei. O que sei é que tenho conseguido finalizar os projetos.<div>&nbsp;</div> Léo Araújo

3 mbravoscreen commented Permalink

Bons tempos! Qual foi o primeiro lugar do mundo em que se falou em um mesmo lugar de forma consolidada em iteratividade, casos de uso, casos de teste, atores, stakeholders, foco em aquitetura, artefatos, change management, uml, requisitos, etc.... Se não foi da maneira perfeita,..., é claro que não foi ! Por definição, o RUP nasceu com a cabeça que o mundo é iterativo (o que tenho certeza que ninguém duvida!) e o grande mérito dele sempre foi aceitar desde o momento zero que ele era algo que deveria ser mudado ao longo do tempo e adaptado pois o mundo muda. A melhor maneiraque sempre enxerguei o RUP foi como um livro que como todo o livro, se lê um dia, se aproveita algo diferente a cada dia, a cada versão se muda, é copiado, xerocado, etc... Talvez o maior pai da criança o Sr. Philippe Kruchten (http://en.wikipedia.org/wiki/Philippe_Kruchten) com quem tive a oportunidade de conversar algumas vezes me disse: Mais importante que o processo de se fazer software que está dentro do RUP, é o processo de se mudar o processo. Este processo de mudar processo e de se aceitar isto como coisa natural na engenharia de software é para mim a maior prova de que ele está mais vivo que nunca, ou melhor, mesmo que estivesse morto ele veio deu o seu recado e deixou claro que a medida que a tecnologia de software evoluir o processo de se fazer software vai evoluir. Em mais 10 anos, software será feito de uma forma muito diferente do que é feito hoje. Podemos ter certeza que qualquer processo que se usa hoje não será mais aplicável, mas as organizações continuarão a precisar de uma forma ordenada de mudarem seu processo de desenvolvimento e criação de software. []s MB. <div>&nbsp;</div>

4 forumibm commented Permalink

É possível que o RUP esteja em baixa enquanto produto (gerador de receita) para a IBM, mas mesmo assim, morto não está! Ainda na semana passada estive em uma das turmas da rodada de certificação no RJ, existiam ao menos 3 pessoas fazendo a prova do RUP, ou seja, ainda existe público.<br /> É possível que o RUP morra com todo o legado (PU, AgileUP, OpenUP)?!<br /> Entendo que nenhum processo de desenvolvimento é perfeito, pois eles sempre são generalistas, mas penso também que nenhum processo tem vida própria; ou a empresa tem alguém qualificado para adaptá-lo e obter o melhor do processo no devido momento, ou certamente falhará.<br />

5 rargento commented Permalink

Marco, interessante o seu ponto sobre a mudança do processo. Da maneira que eu vejo é que tivemos uma evolução interessante. Com o lançamento do RMC(Rational Method Composer)em 2005 (?) separamos o conteúdo do processo da ferramenta de criação/edição/publicação do mesmo. Esse ano com o lançamento do MCIF (Measurement Capability Integrated Framework)separamos formalmente a forma de implantação do processo do processo em si. Acho que é uma importante passo pois fica claro como se deve avaliar e gerenciar a mudança independente de onde queremos chegar ou qual processo iremos implementar. Nesse contexto o RUP passou a ser um conjunto de práticas que podem ser implantadas sozinhas ou em conjunto. Ou seja, temos hoje uma ferramenta, o RMC, um método de mudar, o MCIF e o conteúdo do RUP em forma de práticas.

6 AndersonAndernet commented Permalink

Não entendo que o RUP esteja morto pois não sei de fato se ele estava vivo.<br /> O RUP 2003 era um processo grande, pesado e moroso na qual se algum cliente desejava customizar, precisaria do XDE, RPW, RUP Builder, Editor HTML, etc. Situação esta na qual pode ter desmotivados algumas empresas e/ou usuários a de fato efetuar uma customização e focar nos templates. Já vi algumas empresas qeu adoravam o RUP pois tinha o template do documento de Visão e Caso de Uso, ai saiam falando para todos que utilizavam RUP e UML por completo. Com a chegada do RMC, a facilidade de se customizar um processo tornou-se infinitamente mais fácil, sendo que até usuários que não conheciam os conceitos de customização de processos e/ou componentes do RMC poderiam "brincar" e gerar algumas páginas HTML "bonitinhas".<br /> O RMC, apesar de ser burocrático em alguns aspecto é uma excelente ferramenta. Digo burocrático, pois para empresas que não tem nada e querem rapidamente criar/e ou customizar um processo, tem de ter claro a diferença entre "Capability Pattern", "Delivery Process" e configuração de publicação. A própria estruturação dos plugins que vem na caixa do produto, torna-se mais fácil gerar pequenos processos para depois serem evoluidos. Pelo que entendo o RMC é um framework para ser utilizado na criação de processos. A Rational/IBM sempre pregaram que o RUP é um processo que deve ser customizado, ou seja, confusão, compro um processo que precisa ser customizado, não é mais fácil comprar o processo customizado?<br /> As vezes é fácil explicar porque tem a letra "P" no RUP, mas as vezes acho que o RUP deveria se chamar RUF (Rational Unified Framework).<br /> O curioso é que no RUP tem uma disciplina fantástica que muitas empresas não dão atenção por não ser "core", ou seja, a disciplina de Ambiente. Algum dos motivos: A área de governança de TI ou processos ou arquitetura, já sabem descrever processos, porque perder tempo com isso!<div>&nbsp;</div> Abraços<div>&nbsp;</div> Anderson Luis de Paula Silva<br /> http://www.andernet.com.br

7 rargento commented Permalink

Apesar de eu não compartilhar com o Rodolpho do gosto pela opinião alarmista (...) precisamos prestar atenção à mensagem final de seu e-mail, ou pelo menos a minha interpretação do que é a mensagem final, isto é, que a característica de “iteratividade” foi mal aplicada nestes anos. A verdade é que implementamos mal um processo caracteristicamente iterativo mas que na maioria das referências e customizações, aparece apenas como uma casta formal de padronização e pouco uma mudança real do processo. (E vejam que são muitas as referências, inspirações ou cópias de processo que se dizem ser “RUP”). Há um lado da insuficiência de tempo de observação, quero dizer a mudança de processo ocorre lentamente em grandes corporações, mas há um lado do medo do modelo iterativo, seja ele RUP, Scrum, etc.<div>&nbsp;</div> O desenvolvimento iterativo é o elemento chave de melhoria, confirmado pela experiência da IBM Rational e do Standish Group (em avaliação de pesquisa em 10 anos de projetos, Jin Johnson, então presidente do Standish Group apontou processos iterativos como um dos 3 elementos que fizeram melhorar o desempenho de projetos, uns 40.000 projetos foram pesquisados por eles em 10 anos de relatório cáos).<div>&nbsp;</div> Mas reconhecemos que o iterativo é um modelo difícil de aplicar no ponto de vista do gerenciamento e também dos negócios (estou pensando em subcontratações e tercerizações). Só é fácil na perspectiva da engenharia pois facilita a vida do engenheiro de software e do programador, mas não facilita nada ao gerente planejador! Nós frequentemente contemporizamos com o cliente abdicando da iteratividade em prol de outros aspectos mais 'palatáveis'. Quero dizer, por exemplo, implantar técnicas de requisitos sem um processo iterativo. Implantar uma descrição formal do processo (artefatos, WBSs impraticáveis e os malditos templates) sem tocar no ciclo de vida de projeto que é onde está o grande salto. Esta atitude está certa quando reflete um escalonamento de prioridades de melhoria, mas está errada se for simplesmente a eliminação da idéia do iterativo. O mercado brasileiro infelizmente corre mais no último sentido e nossa acomodação como consultores/vendedores não tem apontado com firmeza a direção a seguir.<div>&nbsp;</div> Por outro lado tanto a IBM Rational quanto o mercado trabalharam o lado formal e burocrático do RUP, talvez pela necessidade de ajudar implementações de CMM/CMMi, PMI e SOX. É justamente o alinhamento automático a outros paradigmas que descaracteriza a proposta. Agora o pêndulo mudou, (lembrem-se de que os problemas ainda persistem), o mercado está reconhecendo a direção ágil, os processos devem ser leves e ágeis, isto vai resgatar essa qualidade do RUP. Mas cuidado, o alinhamento automático poderá prejudicar novamente. Quem entende a proposta de framework do RUP sabe que o ponto não é “leveza”. Não é uma questão de tamanho ou "peso" (você confiaria numa oficina que só tem um martelo?). A questão é a capacidade de configurar e customizar, e para isso precisamos realmente de consultores em ação, gente para entender o processo do cliente, adaptá-lo e modificá-lo. Não basta vender treinamento (que já é superior a vender apenas ferramentas), mas vender uma verdadeira melhoria do processo existente no cliente.<div>&nbsp;</div> Mais em breve....<div>&nbsp;</div> Moacyr Mello<br />

8 rodrigoy commented Permalink

Pra mim, o mind-set das pessoas mataram o RUP, assim como vão matar o Agile. Nunca o problema é das ferramentas e das técnicas.<div>&nbsp;</div> Me sinto bastante responsável por essa discussão, já que fui um dos primeiros a dizer que "O que matou o RUP vai também matar o Agile" em palestras e diversos fóruns de discussão. Não se preocupem, pois mais defendo o RUP do que qualquer outro cristão.<div>&nbsp;</div> Minha contribuição está no blog Débito Técnico da Aspercom:<div>&nbsp;</div> http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/