RUP pode ser ágil?

41 respostas
R

flaleite:
nefertiti:
flaleite:

  • Usando um processo ágil cada iteração deve ser “entregue” ao cliente, então isso serve como uma “prototipação”

Com certeza. Pelo menos no RUP, a utilização de ‘pequenos protótipos’ é recomendada porque a cada iteração realizada você pode mostrar ao cliente. Ocorre uma evolução do protótipo até chegar ao ‘produto final’ (apesar que não existe produto final porque o software nunca é finalizado completamente… :D…sempre existem modificações a fazer )

Até mais

Patty

Você considera RUP um processo ágil?

Saiu essa discussão aqui no tópico sobre protótipo…

Eu lhes pergunto. O RUP pode ser ágil?

[não sou da IBM e não defendo RUP]

41 Respostas

B

Depende do que tu quer dizer com “ágil”.

Se deres uma definição mais específica talvez tenha uma resposta mais específica. 8)

R

www.agilemanifesto.org

:?

D

Não conheço bem esta metodologia, mas pelo que entendi ela pode ser adaptada para se tornar ágil.

Na página de artigos da Agile Alliance tem alguns artigos sobre o assunto:
http://www.agilealliance.com/articles/AgileArticlesCatSearch?category=Rational%20Unified%20Process

A IBM também tem um plugin para utilizar o Extreme Programming junto com o RUP http://www-128.ibm.com/developerworks/rational/library/4156.html

R

Não é uma dúvida, é uma discussão!

Queria entender porque todo “agilista” logo de cara acha que está contrapondo o ®UP…

G

O RUP é um framework. Ele ser ágil depende de como você implementa. Há uma implementação minimalista bastante famosa, chamada dX - em alusão ao diferencial, he he - que se aproxima brutalmente de XP.

http://www.objectmentor.com/publications/RUPvsXP.pdf

Então eu diria que sim, o RUP pode ser ajustado para ser ágil.

C

Mas, se vc vai ajustar RUP pra ser agil, pq nao usar um processo agil logo duma vez? :wink:

G

And that’s the million dollar question… :slight_smile:

D

Incrível, mas tem clientes que pedem que se use RUP como processo de suporte ao desenvolvimento (não, eu não estou passando mal!). Logo, num caso assim, acho que flexibilizar o RUP para torná-lo ágil é válido. Nos demais casos onde não haja uma cláusula contratual obrigando o uso de RUP, entre flexibilizá-lo ou usar XP/SCRUMM, acho mais fácil a segunda opção.

R

Acredito que nenhum processo é “out-of-the-box”. Seguir qualquer processo à risca mesmo que seja XP pode te transformar num “tradicionalista”. Certo? :oops:

Você aplica as metodologias [color=red]exatamente[/color] do jeito que a literatura manda? Você não faz algumas adaptações (mesmo que pequenas)? :wink:

D

Acredito que nenhum processo é “out-of-the-box”. Seguir qualquer processo à risca mesmo que seja XP pode te transformar num “tradicionalista”. Certo? :oops:

Você aplica as metodologias [color=red]exatamente[/color] do jeito que a literatura manda? Você não faz algumas adaptações (mesmo que pequenas)? :wink:

Eu entendi o que você quis dizer, Rodrigo, mas acho que o ponto que o Carlos quis comentar não foi bem este. Acho que a questão seria: “o que é melhor: ajustar algo que é grande, complexo e tradicionalmente não-ágil como o RUP para torná-lo ágil ou simplesmente adaptar as práticas do XP/Scrumm para as suas necessidades?”.

R

Daniel, é verdade, bom, podemos usar o AUP nesse caso que a customização já está feita… Mas sobre o que você falou das empresas exigirem o RUP não é fato isolado. Rola direto!!!

Geralmente o gestor que está comprando o projeto acha que estará mais seguro se o processo for distribuido por uma empresa (IBM). Bom, cada louco com a sua mania…

:wink:

R

Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.

R

Robert:
Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.

Robert, aí é que vc se engana. Não é que a atividade principal do XP é codificar. Para falar a verdade a maneira de se modelar é que é diferente. Eles usam um modelo mental, ou um modelo rascunhado, ou até mesmo a questão de você fazer os testes antes de codificar é considerado o modelo.

Até mesmo o pair programming pode ser considerado uma atividade de modelagem (um pensa no operacional o outro pensa na tática). Tudo isso é para compensar a especificação mais leve que o processo prega.

Muitos metodologistas defendem que os processos ágeis não são gambiarra e nem mesmo 100% desprovidos de documentação. Como já falei, não gosto quando XP vira desculpa para sair fazendo as coisas sem processo nenhum.

F

Os gerentes de projetos e afins adoram metodologias como RUP e metodos de qualidade como CMM* simplesmente por que tem muito papel e documento, ( quilos alias ) o cliente precisa ter informacoes sobre o projeto. e ele muitas vezes nao sabe ler codigo, entao … quer tranquilidade melhor para um gerente do que mandar 100 emails por dia com 2 documentos anexados pro cliente “se divertir” e largar do pé do supracitado ?

D

Papéis e documentos são importantes na medida certa. O problema (que é o que costuma acontecer) é quando tentam usar a burocracia como álibe para prováveis problemas que o projeto enfrentar (e que provavelmente vão existir).

Como eu escrevi em um post no meu blog (é, marketing pessoal mesmo), Horácio já dizia:

Ahhh, se este cara fosse engenheiro de software da SEI hoje em dia… :smiley:

C

Robert:
Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.

No XP a atividade principal eh entregar software funcinoando o mais rapido possivel - codificar eh uma das coisas necessarias pra isso, mas nao se pode confundir as duas. :wink:

R

cv, aí na fábrica do Fowler vcs estão aplicando sempre XP, ou outras metodologias ágeis? Rola alguns projetos num Unified Process mais tradicional? (casos de uso, design, implementação, teste)

Pergunto isso porque o maior entrave para usar metodologias ágeis aqui no Brasil é o cliente (digo isso em fábrica de software, que é onde trabalhei nos últimos 6 anos). O cliente não quer trabalhar fácil, e muitas vezes nem iterativamente.

Queria saber como são os contratos aí no UK…

R

Já que está citando personagens da turma da mônica, o Humberto diria:

:lol:

D

rodrigoy:
“Horácio”:

Dum vitant stulti vitia, in contraria currant /
O tolo, ao tentar evitar o erro, acaba fazendo o contrário.

Já que está citando personagens da turma da mônica, o Humberto diria:

Tudo bem que o Horácio que eu citei é um personagem histórico, mas ele não é pré-histórico.

C

Bom,

O RUP não é um Framework, é um Processo de Engenharia de Software que pode, e deve ser customizado, para atender as necessidades de cada projeto ou de uma empresa, visando justamente agilizar e organizar o ciclo de vida do software garantindo qualidade.

É como a UML: na versão 2.0 temos 8 diagramas, mas quem usa todos em um unico projeto? Você tem um leque de opções baseadas em um segmento, basta escolher o que melhor atende a necessidade. É para isso que existem Engenheiros e Arquitetos de Software, para definirem essas coisas… geralmente são pessoas que possuem N certificações…

Ah, lembrando que, usando o RUP deve-se passar por todas as fases do ciclo (4 fases) e as disciplinas (são 9), só precismos escolher bem quais artefatos usarmos… (só não me lembro quantos mil artefatos possui o RUP)

No desenvolvimento do software, um Framework é uma estrutura de suporte definida em que um outro projecto do software pode ser organizado e desenvolvido. Tipicamente, um Framework pode incluir programas de apoio, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes do seu projecto
.

C

Bom, a ThoughtWorks nao eh nem fabrica, nem do Fowler :wink:

Nao tem nenhum projeto usando RUP. Se a premissa eh que TEM que usar RUP, a gente prefere pular fora do que ficar se torturando.

R

Tem certeza?!? :roll:

http://www.thoughtworks.co.uk/profiles/Fowler,+Martin.html

Bom, não quis dizer que ele é o dono absoluto… e realmente, definir o que é fábrica de software também é bem difícil… :slight_smile:

P

http://www-306.ibm.com/software/awdtools/rup/

coutinho:

Essa definição não está exata. Desenvolvimento de software é muito mais que codificação e construção de programas e ele faal apenas disso.

R

Pessoal,

Desculpem se fui superficial, afinal nao gosto de postar nada sem uma explicacao razaovel, cientifica. Afinal, aqui neste forum so tem fera.

O problema que vi na pratica com o RUP, e que eu trabalhei numa empresa de software que aplicou RUP e passou anos fazendo modelagem de um sistema, sem implementar nada. Deve-se evitar esse extremo. (A propria empresa percebeu isso).

Na XP, codificar e desejado assim q se tenha uma ideia clara, apos uma boa conversa com o cliente, seguindo um processo bastante rigoroso.
O objetivo da XP nao e entregar qualquer codigo funcionando, mas um codigo de qualidade, por isso , usa-se testes automaticos, refatoring, etc.

Na minha opiniao , pode ser dificil integar RUP com XP, pelos seguintes motivos:
RUP e um processo baseado na engenharia de software tradicional, em que se acreditava que a documentacao deve ser extensiva e completada antes da implementacao.
(Se eu estiver errado me corrijam!)

Em processos ageis nao da pra fazer isso, devemos ser ageis!
Precisamos manter algum codigo funcionando que atenda as expectativas do cliente, e modificar esse codigo a fim de se obter qualidade.

Bem, se existem alternativas, seria adaptando as duas estrategias.
Tudo e possivel, nao devemos ver as coisas como opostos, afinal, isso e a base da sabedoria chinesa :slight_smile:

P

Isto é um processo em waterfall, o RUP (quando usado ‘de verdade’ - e eu nunca vi isso) é iterativo incremental.

Lembre-se que o tem principal da thread é agilidade, não XP. RUP não precisaria se integrar com XP para ser ágil.

Falando nisso, ainda sobre o coutinho:

O ágil aqui é um pouco mais específico e baseado em:

C

Tem certeza?!? :roll:

http://www.thoughtworks.co.uk/profiles/Fowler,+Martin.html

http://www.thoughtworks.co.uk/profiles/Villela,+Carlos.html

(em outras palavras, sim, tenho certeza ;))

R

cv:

http://www.thoughtworks.co.uk/profiles/Villela,+Carlos.html

(em outras palavras, sim, tenho certeza ;))

Exibido! 8) É que realmente pensei que ele era o dono da padaria aí… :lol:

hshshshshs

E

Um trecho de um artigo do Fowler:

C

C

Desculpe, mas a matéria não esta dizendo que o RUP é um framework, se sim, que o RUP com IBM® Rational® Method Composer (o framework em questão)

Vamos aos fatos, supostamente, simples perguntas e respostas:

  1. Qual framework é usado na empresa em que você trabalha?
    Possivel Resposta: HIBERNATE, VELOCITY, STRUTS, etc

  2. Qual Processo de Desenvolvimento é usado na empresa?
    Possivel Resposta: RUP, MDA, etc

Agora vamos responder como se o RUP fosse um framework

  1. Qual framework é usado na empresa em que você trabalha?
    Possivel Resposta: RUP, MDA, etc

  2. Qual Processo de Desenvolvimento é usado na empresa?
    Possivel Resposta: Nenhum, só tem framework lá…

pcalcado:

Essa definição não está exata. Desenvolvimento de software é muito mais que codificação e construção de programas e ele faal apenas disso.

O que mais se aplica? se essas palavras não conseguem definir um framework… cite mais definições de framework… tenho curiosidade…

falows…

R

MDA não é framework… que literatura defende isso?

Coutinho, o texto é claro ao dizer que o RUP é um framework de processo…

[]s

C

rodrigoy:
MDA não é framework… que literatura defende isso?

Coutinho, o texto é claro ao dizer que o RUP é um framework de processo…

[]s

Exato! viu só como fica fora de contexto, é bem isso que eu quis mostrar, assim como MDA não é framework o RUP tb não é

Processo != Framework

P

coutinho:
pcalcado:

The RUP process framework with IBM Rational Method Composer includes:

http://www-306.ibm.com/software/awdtools/rup/

Desculpe, mas a matéria não esta dizendo que o RUP é um framework, se sim, que o RUP com IBM® Rational® Method Composer (o framework em questão)

Desculpe, mas está sim, basta traduzir corretamente a frase:

“O framework de processo RUP com o IBM Rational Method Composer”, e o Composer é uma suíte da qual o RUP faz parte agora.

Outra página:

IBM:

IBM Rational Unified Process®, or RUP®, is not only software engineering process, but also an industry-wide platform for best practices. By adopting proven best practices and a customizable process framework, software development organizations are finding they are able to communicate more clearly and deliver higher-quality software more predictably. “Our biggest challenge is ensuring the communication on the respective levels on the team. I think where Rational has really helped us is that it has standardized a language of how the teams talk to each other,” says John Pritchard, Architect for Lockheed Martin.

http://www-306.ibm.com/software/success/cssdb.nsf/CS/JENS-5WWRAH?OpenDocument&Site=rational

Ou outra:

http://www-306.ibm.com/software/awdtools/rmc/index.html

Mas se restar alguma dúvida faça esta pesquisa no Google:

http://www.google.com.br/search?hl=pt-BR&q=site%3Aibm.com+rup+framework&btnG=Pesquisa+Google&meta=

Repetindo: Frameworks não são apenas estruturas de programação como Hibernate, Spring e etc.

Framework é um conceito que pdoe ser aplicado em diversas áreas.


http://www.google.com.br/search?q=define:framework&hl=pt-BR&lr=&oi=definel&defl=en

É tudo uma questão de procurar.

C

Não acho que seja uma questão de procurar, até porque eu já sei do que se trata e tenho minha opinião muito bem formada.

Bom, não vou questionar mais, senão vamos ficar aqui, paginas e mais paginas, uma dizendo que é e o outro dizendo que não é!

Agora, só acho que deveriamos então, sugerir a IBM Rational alterar o nome do RUP (Rational Unified Process) para RUF (Rational Unified Framework)

Para finalizar, uma coisa é possuir frameworks, ser constituidos por, e outra é ser um framework.

Encerro por aqui meus argumentos. Não quero causar confusão

falows… desculpe qualquer coisa

F

Sim, o UP pode ser ágil ! :smiley:

Os autores do UP não tinham a intenção de tornar o processo burocrático em meio a um infinidade de artefatos, isso porque ele tem um conjunto enorme de artefatos opcionais.

Para que você utilize UP agilmente , escolha um conjunto menor de artefatos e tarefas, buscando a simplicidade.

Como o desenvolvimento é iterativo, crie o Plano de Iteração de forma adaptável.

C

Fabricio, releia o seu post, e identifique as falhas e furos com o Agile Manifesto :wink:

F

Ok cv,

não percebi qualquer furo nele. Se você puder identificá-los … :wink:

Vc pode fazer uma analogia ao UP com uma farmácia, onde a farmácia dispõe de uma infinidades de medicamentos, e o paciente escolhe qual ou quais estarão sendo úteis para o seu tratamento, a mesma coisa com o UP, dispões de muitos artefatos opcionais, todos são opcionais, menos o código (claro). Desse ponto de vista como o processo é iterativo, e o manifesto ágil propõe isso, então estaria perfeitamente adaptável, lógico que no processo ágil você não vai colocar artefatos e atividades desnecessárias, você vai escolher aqueles que melhor se adequa a metodologia, se for 1 ou 2, ótimo,contato que siga estes principios:

:arrow: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

:arrow: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

:arrow: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

:arrow: Business people and developers must work together daily throughout the project.

:arrow: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

:arrow: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

:arrow: Working software is the primary measure of progress.

:arrow: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

:arrow: Continuous attention to technical excellence and good design enhances agility.

:arrow: Simplicity–the art of maximizing the amount of work not done–is essential.

:arrow: The best architectures, requirements, and designs emerge from self-organizing teams.

:arrow: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

C

Voce tambem pode fazer uma analogia entre RUP e uma Kombi '79 que vende caldo de cana na feira: sempre tem um barulhinho aqui, uma peca faltando ali, e a ultima vez que o motor viu uma troca de oleo foi ha umas duas decadas. Mas enquanto o treco andar a mais de 20 por hora vc ta comemorando. Dai quebra, pega fogo ou nao funciona mais, e vc fica se perguntando o que aconteceu – mas, antes de realmente conseguir investigar, ja comprou outra Kombi.

Eu nao engulo esse papo de artefatos opcionais. Se todos artefatos sao opcionais, menos o codigo, entao cade a consistencia e a tao-chamada qualidade que os pregadores do RUP tanto pregam?

D

coutinho:
Não acho que seja uma questão de procurar, até porque eu já sei do que se trata e tenho minha opinião muito bem formada.

Bom, não vou questionar mais, senão vamos ficar aqui, paginas e mais paginas, uma dizendo que é e o outro dizendo que não é!

Agora, só acho que deveriamos então, sugerir a IBM Rational alterar o nome do RUP (Rational Unified Process) para RUF (Rational Unified Framework)

Para finalizar, uma coisa é possuir frameworks, ser constituidos por, e outra é ser um framework.

Encerro por aqui meus argumentos. Não quero causar confusão

falows… desculpe qualquer coisa

O que eu acho que está lhe faltando é uma definição correta do que é framework. Frameworks não são apenas “bibliotecas ao redor das quais você organiza e constrói seu projeto”, mas é uma estrutura pré-definida que ajuda a servir como guia para construir alguma coisa (dica: veja a definição de framework em http://dictionary.reference.com/search?q=framework ). Sendo assim, não vejo nenhum problema em considerar o RUP como um framework para processos de desenvolvimento. :wink:

R

coutinho:
rodrigoy:
MDA não é framework… que literatura defende isso?

Coutinho, o texto é claro ao dizer que o RUP é um framework de processo…

[]s

Exato! viu só como fica fora de contexto, é bem isso que eu quis mostrar, assim como MDA não é framework o RUP tb não é

Processo != Framework

MDA também não é processo… :roll: :? :!:

F

Não pode, aliás uma Kombi 79, que vende caldo de cana, não sugere muita coisa além de vender caldo de cana, se eu quiser um suco de laranja, ou um açai, ou mais , se quiser fazer um pedido a domicilo, esta kombi dificilmente vai me suprir, então não se pode comparar com o RUP, que propõe a escolha de diversas receitas de como fazer tal artefato e de como realizar tal tarefa, e quem realiza determinada tarefa.

cv:

Eu nao engulo esse papo de artefatos opcionais. Se todos artefatos sao opcionais, menos o codigo, entao cade a consistencia e a tao-chamada qualidade que os pregadores do RUP tanto pregam?
O dinamismo está justamente aí, eles não determinaram que você deve usar todos, isso porque cada projeto tem características próprias, e o RUP como sendo um framework de processos, deve prover extensões para a concepção, elaboração, construção e transição de n-projetos.

Criado 23 de maio de 2006
Ultima resposta 5 de jun. de 2006
Respostas 41
Participantes 12