Desde quando RUP é Waterfall?

Assuntos Gerais Agile
#1

Olá pessoal,

Eu hesitei bastante antes de criar este tópico, mas não deu pra aguentar. Vi na outra thread(“Processo em cascata ou processos ágeis”) uma discussão insana, sem pé nem cabeça, que contrapunha RUP e desenvolvimento Iterativo.

Estou criando este tópico para pôr uma pedra nesse assunto definitivamente:

  • RUP é (e SEMPRE foi) iterativo E incremental;
  • o ÚNICO artefato obrigatório do RUP é (e sempre foi) o código;
  • RUP não manda você fazer primeiro modelo e depois implementação;
  • RUP não propõe a visão Fordiana de linha de produção;

O que o RUP manda:

  1. Foco no usuário: defina a solução utilizando casos de uso;
  2. Mitigue riscos o mais cedo possível: ataque as funcionalidades mais importantes e difíceis primeiro e teste a arquitetura;
  3. Valide o progresso do projeto frequentemente: produza software de maneira iterativa e incremental;

Iterações+Foco na Arquitetura+Casos de Uso=RUP

Fonte: o próprio RUP.

Alguém aí discorda mesmo disso? Se sim, poderia, por favor apontar uma fonte que suporte a afirmação (mochuara, principalmente)?

Um abraço,
Rodolpho

#2

Rodolpho,

Quando vc diz que RUP é iterativo, voce diz como desenvolvedor ou consultor RUP?

Se for desenvolvedor (e iteratividade é algo realmente tão essencial!), entao explore esse fato, ganhe dinheiro e seja feliz!

Senão,

O máximo que posso fazer é entender sua posição.

#3

Eu já havia pedido o mesmo na outra thread, mas nunca obtive resposta.
Mas acho que não precisava ter levantado novamente essa bandeira. Aquele tópico por si só já foi bastante inflamado.

#4

Um processo iterativo usa o contato com usuários reais desde a primeira versão para extrair feedback e investir no refinamento da visão original do que o sistema deve fazer.

O próprio fanboy RUP (caraca, nem sabia que existia isso!) ai em cima, diz que no RUP, foco no usuário significa utilizar casos de uso!!!

#5

Ué mochuara… se você se dá ao luxo de ser um troller contra o rup, por que não deixar ele ser também um fanboy?

#6

Me intrometendo um pouco, acho que o problema não é bem o RUP, o problema é que as empresas criam processos SOBRE o RUP distorcendo-o de forma a parecer um processo waterfall… sujando a imagem do mesmo.

#7

Mochuara,

Eu não disse que foco no usuário SIGNIFICA usar casos de uso. Eu disse: use casos de uso e foque no usuário. E quem diz isso não sou eu, mas o próprio RUP.

Sobre Iterações o RUP diz duas coisas:

  1. O objetivo de toda iteração é produzir um produto de software testável. A única exceção admitida é na iteração de concepção (mais ou menos como na iteração 0 do SCRUM).
  2. Ao final de toda iteração é feita uma “Avaliação da Iteração” onde o cliente/usuário/patrocinador pode conferir o resultado e dar feedbacks para que a equipe corrija o rumo se necessário.

Fonte: RUP

Você é sempre evasivo e obtuso nas suas respostas e parece que gosta bastante de ser irônico.

Pode, por favor, me dizer porque diabos você acha que o RUP não é iterativo e onde ouviu ou leu esse monte de bobagem?

Abraço,
Rodolpho

#8

Samuel,

É. Mas o RUP tem sua parcela de culpa. Eu não gosto da maneira como o RUP é documentado: acho muito complicado e tira o foco do que é essencial. O SCRUM, por exemplo, tem uma documentação enxuta, objetiva e eficiente (O SCRUM Guide, por exemplo).

Minha opinião é que a maneira como o RUP está documentado (sobretudo os diagramas de atividade) induz as equipes/empresas/pessoas inexperiêntes ao erro.

Um abraço,
Rodolpho

#9

Pois é ViniGodoy… eu percebi. Mas não dá pra aguentar ler tanta bobagem e ficar quieto.

Vamos ver onde isso dá…

Um abraço,
Rodolpho

#10

O RUP em si é um processo iterativo e incremental.

[]s

#11

[quote=rugolini]Mochuara,

Eu não disse que foco no usuário SIGNIFICA usar casos de uso. Eu disse: use casos de uso e foque no usuário. E quem diz isso não sou eu, mas o próprio RUP.

Sobre Iterações o RUP diz duas coisas:

  1. O objetivo de toda iteração é produzir um produto de software testável. A única exceção admitida é na iteração de concepção (mais ou menos como na iteração 0 do SCRUM).
  2. Ao final de toda iteração é feita uma “Avaliação da Iteração” onde o cliente/usuário/patrocinador pode conferir o resultado e dar feedbacks para que a equipe corrija o rumo se necessário.

Fonte: RUP

Você é sempre evasivo e obtuso nas suas respostas e parece que gosta bastante de ser irônico.

Pode, por favor, me dizer porque diabos você acha que o RUP não é iterativo e onde ouviu ou leu esse monte de bobagem?

Abraço,
Rodolpho
[/quote]

Então vc esta dizendo que o RUP:

  • possui iterações curtas

  • ao final de cada uma, tem-se um release beta que consiste em software executavel, e

  • cada release beta é validado pelo usuário final

Esse deve ser o Rodolpho Unified Process, porque o RUP não diz isso nos livros, muito menos na pratica.

No RUP o sistema não é validado pelo usuário final ao fim de cada iteração, apenas na fase de transição.

#12

Não está ocorrendo confusão entre:

UP: Processo Unificado

e

RUP: Processo Unificado da Rational

???

Abraços

#13

Mochuara: “No RUP o sistema não é validado pelo usuário final ao fim de cada iteração, apenas na fase de transição.”

Nossa Mochuara, você realmente não sabe o que está dizendo. Onde você leu isso? Pode, por favor me indicar (precisamente) a fonte?

Sobre suas colocações, vamos ver o que o RUP diz:

  1. Mochuara: "possui iterações curtas"
    RUP: “The duration of an iteration will vary depending on the size and nature of the project, but it is likely that multiple builds will be constructed in each iteration. This is a consequence of the continuous integration approach recommended in the Rational Unified Process (RUP) […] each build itself represents a mini-iteration.” - CHECK

  2. Mochuara: "ao final de cada uma, tem-se um release beta que consiste em software executavel"
    RUP: “An iteration encompasses the development activities that lead to a product release-a stable, executable version of the product” - CHECK!

  3. Mochuara: "cada release beta é validado pelo usuário final"
    RUP: “Note that evaluation criteria are established when each iteration is planned. The release will have planned capability which is demonstrable.This allows us to demonstrate the application to end users and other stakeholders, or have them use the application directly, enabling them to provide rapid feedback on how we are doing.” - CHECK!

Sobre a fase de transição: “The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.”

Aqui você pode ler e estudar (de graça) o RUP (em português ou inglês): http://www.wthreex.com/rup/

Mochuara, todo o texto acima foi tirado DO RUP (da Rational, não do Rodolpho). Portanto, recomendo que você leia e estude antes de afirmar coisas que não sabe. Isso é ruim pra todo mundo.

Tem muita gente, por exemplo, queimando o filme do SCRUM dizendo bobagens como: só pra times/projetos pequenos, etc.

Você me perguntou se falo como consultor ou desenvolvedor… falo como ambos: eu pratico e ensino RUP a mais de 10 anos. Uso-o nos meus projetos (que são pequeninos e com equipe idem) e utilizo como base para melhorar a eficiência de times de desenvolvimento de software de empresas de todos os tamanhos.

Ok?

Um abraço,
Rodolpho

#14

luizSC,

Qual a diferença entre “UP: Processo Unificado” e “RUP: Processo Unificado da Rational” ? Um é a encarnação do outro.

O RUP é um produto formado por uma biblioteca de conhecimento e uma ferramenta para customização dessa biblioteca (Rational Method Composer). Mais informações em http://www-01.ibm.com/software/awdtools/rup/.

O UP é o processo criado a partir do Objectory, processo criado pelo Jacobson na década de 80 e o Booch Method, criado por Grady Booch, com contribuições de Philip Krutchen, David Harel e James Rumbagh. O processo foi publicado no livro “The Unified Software Development Process” (http://www.amazon.com/Unified-Software-Development-Process/dp/0201571692) - que recomendo fortemente ao Mochuara.

O RUP segue os princípios propostos pelo UP, entretanto existem outras variações de processo baseados no mesmo princípios, como:

Agile Unified Process (AUP), criada por Scott W. Ambler
Basic Unified Process (BUP), criada pela IBM que deu origem ao OpenUP (http://epf.eclipse.org/wikis/openup/)
Enterprise Unified Process (EUP), uma extensão ao Rational Unified Process
Essential Unified Process (EssUP), criada por Ivar Jacobson
Open Unified Process (OpenUP), o processo de desenvolvimento criado pelo consórcio Eclipse
Oracle Unified Method (OUM), criado pela Oracle
Rational Unified Process-System Engineering (RUP-SE), uma versão do RUP voltada para Engenharia de Sistemas.

Um abraço,
Rodolpho

#15

[quote=rugolini]
Aqui você pode ler e estudar (de graça) o RUP (em português ou inglês): http://www.wthreex.com/rup/

Mochuara, todo o texto acima foi tirado DO RUP (da Rational, não do Rodolpho). Portanto, recomendo que você leia e estude antes de afirmar coisas que não sabe. Isso é ruim pra todo mundo.[/quote]

Essa é a entidade oficial de RUP que vc cita como fonte? Um link cheio de google ads?

[quote=rugolini]
Você me perguntou se falo como consultor ou desenvolvedor… falo como ambos: eu pratico e ensino RUP a mais de 10 anos. Uso-o nos meus projetos (que são pequeninos e com equipe idem) e utilizo como base para melhorar a eficiência de times de desenvolvimento de software de empresas de todos os tamanhos.

Ok?

Um abraço,
Rodolpho[/quote]

Que bom! Waterfall é um processo perfeitamente válido (mesmo não sendo iterativo) e bastante utilizado pelas empresas. Não tenho duvida que muitos projetos de sucesso são feitos usando RUP, por exemplo.

Mas RUP é waterfall por não proporcionar o design iterativo, não me lembro de ter dito que ele era ineficiente.

#16

Cara, RUP é um processo iterativo sim e qualquer documentação a respeito do mesmo diz isso.
Se na prática as pessoas não o fazem iterativamente é outra estória.
Sua afirmação não tem fundamento e só está servindo para aumentar sua quota de mensagens

#17

Mochuara, você disse: "Mas RUP é waterfall por não proporcionar o design iterativo. "

Você pode, por favor me indicar a fonte para essa afirmação? Onde você leu isso?

Extraído do RUP:

“In the RUP, the architecture evolves iteration after iteration to become refined and polished. As each iteration includes integration and test, the architecture is quite robust by the time the product is delivered.”

Se você tiver dificuldades com inglês, segue a tradução:

“No RUP, a arquitetura evolui iteração após iteração para tornar-se refinada e polida. Como cada iteração inclui integração e testes, a arquitetura torna-se bastante robusta quando chega a hora do produto ser entregue.”

Fonte: RUP, novamente aqui você pode LER o RUP http://www.wthreex.com/rup/smallprojects/index.htm)

Isso é: o Design no RUP é incremental. O RUP é um processo iterativo E incremental. Tudo é feito de maneira incremental: captura e definição dos requisitos, análise e design, implementação, testes e implantação. Tudo é incremental.

Ok?

#18

Oi, não sei se é certo perguntar aqui mas, é pura curiosidade:

Quais grandes empresas utilizam o RUP?

#19

Lucas,

Eu trabalho na IBM Rational e infelizmente não tenho autorização para publicar as referências sem autorização dos clientes.

Posso afirmar que dezenas de grandes empresas usam, em todos os segmentos, mas principalmente energia e petróleo, financeiro/bancário/seguros, governo e Jogos.

Este último é um ramo que eu gosto bastante de citar: ouço muito por aí que “RUP é pesado e burocrático” e “XIBRUTS é leve e ágil” (sinceramente foi a primeira vez que vi alguém advogando que o RUP é cascata :slight_smile: e se existe uma indústria de desenvolvimento de software que precisa de processo eficiente é a de Games. Um dos processos de desenvolvimento mais bem sucedidos nessa indústria é o GUP - Game Unified Process, que usa como base o UP e mistura elementos do XP. Vale a leitura: http://www.gamedev.net/reference/articles/article1940.asp

E no Brasil foi criado uma variação desse processo, específicamente para jogos móveis (que tem como características equipes muito enxutas e prazos apertadíssimos). Vale MUITO a pena a leitura (alô Mochuara!): www.dominiopublico.gov.br/download/texto/cp000585.pdf

Se você ler o artigo do Kevin, vai perceber que o desafio de mudança cultural é sempre o mesmo: MINDSET. Eu sinto isso na pele todos os dias, principalmente em empresas médias e grandes.

É muito difícil mudar a maneira de pensar Waterfall para Iterativo. Costumo dizer a adoção de um novo processo ocorre em ondas: colocamos bastante energia para adotar novas práticas e no começo as equipes se empolgam, os resultados positivos aparecem. Depois de um tempo, a consultoria termina, as pessoas dos times vão sendo trocadas e a coisa recua, mas sempre para um patamar sempre superior ao do início da onda. Depois uma nova onda se inicia e o ciclo se repete.

Infelizmente, assim como tem o ScrumBut, existe o WUP: Waterfall Unified Process. Que acontece quando a empresa usa o vocabulário, os (malditos) templates de documentos, mas se mantém presa ao processo cascata.

Eu acredito que existam mais empresas grandes usando WUP do que RUP. Mas o movimento ágil renovou nosso gás, pudemos identificar problemas na abordagem inicial e continuar a perseguir nosso objetivo que é banir de vez essa praga chamada “abordagem em cascata”.

E nisso, eu acredito, estamos todos juntos. Sejam XisPêzeiros, SCRUMzeiros, Agilistas, RUPianos, LEANistas… Juntos chegaremos lá! :-))))

Um abraço!
Rodolpho

PS: sobre as referencias, se estiver interessado em algo mais específico, pode me contactar diretamente.

#20

@rugolini

Eu sinto muito mas ao mesmo tempo que concordo contigo eu tenho que alfinetar o RUP. Muito mau documentado e deu margem a muitas interpretações. Ao contrário o SCRUM que tem a documentação melhor, como você bem disse. Esse segundo sofre do inverso, pois muita gente esquece que estamos desenvolvendo software e acha que colar papelzinho de post-it e ficar em pé numa reunião de 15 minutos todos os dias vai resolver todos os problemas.

Por isso que eu concordo com tudo que o meu amigo Rodrigo Yoshima diz no post abaixo e que com certeza já deve ter falado contigo sobre esse assunto:

Abraços,