RUP pode ser ágil?

scottys0 wrote: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 ?

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:

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

Ahhh, se este cara fosse engenheiro de software da SEI hoje em dia...

Robert wrote: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.

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...

Horácio wrote:
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:

Humberto wrote:
hum...hum... hum..

rodrigoy wrote:

Horácio wrote:
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.

HelloWorld Membro desde: 21/11/2003 16:51:13 Mensagens: 13 Offline

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)

O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational) é um processo de Engenharia de software criado pela Rational Software Corporation. É um método proprietário de desenvolvimento de software, e provê técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.

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

.

rodrigoy wrote: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)

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

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.

cv wrote:

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

Tem certeza?!?

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...

coutinho wrote:
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.

IBM wrote:
The RUP process framework with IBM Rational Method Composer includes:

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

coutinho wrote:

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

.

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.

What is classpath? Membro desde: 10/05/2006 12:50:14 Mensagens: 7 Offline

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

Robert wrote:
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!)

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

Robert wrote:
Na minha opiniao , pode ser dificil integar RUP com XP, pelos seguintes motivos:

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:

coutinho wrote:
visando justamente agilizar e organizar o ciclo de vida do software garantindo qualidade.

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

Agile Manifesto wrote:
Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

rodrigoy wrote:

cv wrote:Bom, a ThoughtWorks nao eh nem fabrica, nem do Fowler

Tem certeza?!?

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

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

(em outras palavras, sim, tenho certeza

)

cv wrote:

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

(em outras palavras, sim, tenho certeza )

Exibido!

É que realmente pensei que ele era o dono da padaria aí...

hshshshshs

Um trecho de um artigo do Fowler:
http://www.martinfowler.com/articles/newMethodology.html#rationalUnifiedProcess

HelloWorld Membro desde: 21/11/2003 16:51:13 Mensagens: 13 Offline

'

Notícias, artigos e o maior fórum brasileiro sobre Java