RUP é Igual a eXtreme Programming
O título desse post pode chocar muito as pessoas :) . Mas de fato RUP é tão diferente de eXtreme Programming assim? O propósito desse post é estabelecer os aspectos em que essas duas metodologias tem em comum e também aqueles aspectos que ambas seguem a mesma idéia porem muitas vezes com abordagem totalmente distintas.
Se você quiser conhecer mais o RUP pode começar lendo dois post anteriores que fiz sobre o assunto. Os links são estes:
A figura a cima demonstra o que estou falando. O RUP é mais formal do que o XP. Eu já mencionei isso antes nesse post. Todos já devem saber a recomendação que utilizamos RUP quando:
RUP é uma metodologia que é dirigia a riscos. Claro que os clientes participam dentro do processo mas a visão e os interesses dos clientes são mantidas por "Analistas". No XP isso é diferente, não existe o Role "Analista", mas por que? Por que o XP é dirigido ao Cliente, isso significa que eles utilizam o cliente em tempo integral no projeto, ai vem a prática Onsite Consumer.
Intensidade
A abordagem do RUP prega que o projeto é desenvolvido de maneira Iterativa e Incremental, logo existe uma intensidade das atividades no projeto. Em determinados momentos existe mais desenvolvimento e em outros momentos existe menos. Você pode estar se perguntando o que isso tem a ver como XP ou se o XP não prega o contrário disso. Certo? Pois bem XP não é uma metodologia tão bem especificada com o RUP, logo existem muitas brechas que dão vazão a determinado tipo de interpretações.
Mas segundo o próprio Kent Beck (Criador da Metodologia), ele fala que em um consultoria que realizou recomendou que um determinado cliente só poderia ter vários programadores através do tempo, de inicio ele iniciaria com poucos programadores e depois iria aumentando gradativamente. O que isso tem a ver como o RUP? Tudo. Esse é o que o gráfico de Baleias mostra.
Arquitetura
De fato a abordagem de arquitetura do XP a primeira vista pode parecer muito diferente da do RUP, será que ela é totalmente diferente mesmo? Se nos olharmos o meio, sim de fato é muito diferente mas olhando para os objetivos, não.
Como assim? No XP a arquitetura começa a ser construída através da Metáfora do Sistema que alem de ajudar todos os envolvidos no projeto a entender o sistema já é parte da arquitetura. Isso de fato é uma prática muito boa do XP. :)
No RUP as coisas são um pouco mais elaboradas, existe o papel de Arquiteto e o processo (RUP) é baseado no na arquitetura. Não significa um grande "Big Design UP to Front", mas sim uma maneira de aumentar a simplicidade do sistema.
O mesmo acontece no XP com a metáfora que é uma coisa boa a qual eu já falei no trecho a cima. Porem não é só isso, por trás disso tudo existe um valor que a "Simplicidade" o XP se utiliza muito desse valor. A idéia é fazer a coisa mais simples que possa funcionar. Vou explicar mais sobre isso na seqüencia e você entenderá por que as coisas são assim no XP. Com um sistema simples, logo os problemas são resolvidos de maneira simples e o mesmo objetivo que o RUP consegue através da arquitetura o RUP consegue também.
Requisitos
Bom aqui é a onde existe mais polêmica, prometo que vou apenas explicar as duas abordagens dos dois processos sem entraras no mérito de qual é melhor, mas em determinados pontos concordo que o Kent Back tem algumas idéias AnarcoPUNK.
Como o XP trata os Requisitos? Na visão de uma Analista de Requisitos de forma absurdamente "tosca"; Como as coisas ocorrem? Pois bem como o XP prega que não devemos viajar com muita bagagem logo não é bom (Segunda o ótica do XP) produzir documentação detalhada.
Nota: Esse valor de não produzir uma documentação detalhada é um valor que existe apenas no XP, as outras metodologias agéis não acatam esse 'valor'.
Por que? Com o no XP o cliente está na sala ele pode passar de forma oral o que deve ser feito para os programadores e como no XP ele "Acolhem a mudança" e sempre fazem "Refactorings" e o código é "simples" eles podem aplicar as mudanças a qualquer momento *sem maiores problemas*
Nota: Vamos ao *sem maiores problemas* na verdade nem sempre é assim, muitas vezes isso pode funcionar bem em outras não e levando o projeto ao fracasso, através do Anti-Pattern chamado "Creeping Requirementes".
No RUP as cosias são diferentes, no inicio as mudanças são mais freqüentes depois o processo prega que devemos "Gerenciar as mudanças" através de uma mecanismo eficiente. Como o RUP prega dois níveis de análise, primeiro uma análise de alto nível de negócio onde 80% dos requisitos de negocio mais importantes eram abordados. Após essa análise de negocio existe um workshop com a arquitetura onde 20% dos requisitos mais importantes para a arquitetura são abordados são revisados. A partir disso que a arquitetura é começada a ser criada.
Como vocês podem perceber o RUP prega mais tempo em requisitos e mais tempo em arquitetura do que o XP, assim as mudanças acabam sendo menores.
Não podemos nos esquecer que boa parte dos Refactorings que acontecem em um projeto XP acontecem por que a metodologia XP não investe um tempo suficiente em requisitos. Como programadores não tem tal habilidade muitas vezes isso é um problema em um projeto XP.
Mesmo assim não quer dizer que não funcione
Existem registros de projetos utilizados em situações totalmente adversas dos cenários habituais de uso das metodologias. Existem registros de projetos RUP que foram executados em uma semana com poucos profissionais e que funcionaram muito bem. Como também existem registros de projetos XP com até 60 pessoas com 2 anos de projeto que foram um sucesso.
Quanto a disciplina de cada metodologia
Esse ponto é muito interessante de ser abordado, por que aqui acontece um fenômeno ao contrário. Por que normalmente as pessoas olham o RUP e dizem: "Bah aquele monte de artefatos e é muita coisa, que horrível!" e as mesas pessoas olha o XP e dizem "Mas que maravilha poucos artefatos, bem mais flexível!" Essa pessoa está totalmente errada!
XP é uma metodologia eXtremamente Disciplinada, onde o número de artefatos opcionais é quase zero. Você deve utilizar todos os artefatos e práticas no XP para dar certo e tirar proveito disso, e não sou eu que estou dizendo isso vem do próprio Kent Back.
Já no RUP a coisa é justamente o contrário, a metodologia é muito mais flexível do que o XP, isso ai mais flexível. A maioria dos artefatos são opcionais. Confira aqui os artefatos mandatários. Por que o RUP é um framework e lá existem diversas práticas para diversas áreas e você não deve distanciar tudo.
Voltando a figura principal e concluindo
A abordagem do XP é diferente em diversos pontos em relação ao RUP, porem existem muitos princípios que são de comum compartilhamento. A diferença maior está na abordagem, que como a figura a cima mostra está no grau de formalismo. Mas quero salientar a diferença quanto a "Client Driven" vs "Risk Driven". É fato que existem situações que uma é muito melhor que a outra. Tal constatação vem tanto do RUP quanto do XP.
Mesmo assim ainda podemos fazer algumas "misturas" de práticas das duas metodologias como a "Integração Continua" do XP com a gerência de Mudanças do RUP.
Abraços e até a próxima.
Se você quiser conhecer mais o RUP pode começar lendo dois post anteriores que fiz sobre o assunto. Os links são estes:
- http://diego-pacheco.blogspot.com/2008/07/rup-importncia-dos-marcos.html
- http://diego-pacheco.blogspot.com/2008/07/rup-verdades-e-mitos.html
A figura a cima demonstra o que estou falando. O RUP é mais formal do que o XP. Eu já mencionei isso antes nesse post. Todos já devem saber a recomendação que utilizamos RUP quando:
- Projeto é grande, ou seja, mais riscos
- Existem muitos programadores + 100
- Necessitamos de mais controle
- Projeto é pequeno, ou seja, menos riscos
- Existem poucos programadores - 10
- Necessitamos de menos controle e + agilidade
RUP é uma metodologia que é dirigia a riscos. Claro que os clientes participam dentro do processo mas a visão e os interesses dos clientes são mantidas por "Analistas". No XP isso é diferente, não existe o Role "Analista", mas por que? Por que o XP é dirigido ao Cliente, isso significa que eles utilizam o cliente em tempo integral no projeto, ai vem a prática Onsite Consumer.
Intensidade
A abordagem do RUP prega que o projeto é desenvolvido de maneira Iterativa e Incremental, logo existe uma intensidade das atividades no projeto. Em determinados momentos existe mais desenvolvimento e em outros momentos existe menos. Você pode estar se perguntando o que isso tem a ver como XP ou se o XP não prega o contrário disso. Certo? Pois bem XP não é uma metodologia tão bem especificada com o RUP, logo existem muitas brechas que dão vazão a determinado tipo de interpretações.
Mas segundo o próprio Kent Beck (Criador da Metodologia), ele fala que em um consultoria que realizou recomendou que um determinado cliente só poderia ter vários programadores através do tempo, de inicio ele iniciaria com poucos programadores e depois iria aumentando gradativamente. O que isso tem a ver como o RUP? Tudo. Esse é o que o gráfico de Baleias mostra.
Arquitetura
De fato a abordagem de arquitetura do XP a primeira vista pode parecer muito diferente da do RUP, será que ela é totalmente diferente mesmo? Se nos olharmos o meio, sim de fato é muito diferente mas olhando para os objetivos, não.
Como assim? No XP a arquitetura começa a ser construída através da Metáfora do Sistema que alem de ajudar todos os envolvidos no projeto a entender o sistema já é parte da arquitetura. Isso de fato é uma prática muito boa do XP. :)
No RUP as coisas são um pouco mais elaboradas, existe o papel de Arquiteto e o processo (RUP) é baseado no na arquitetura. Não significa um grande "Big Design UP to Front", mas sim uma maneira de aumentar a simplicidade do sistema.
O mesmo acontece no XP com a metáfora que é uma coisa boa a qual eu já falei no trecho a cima. Porem não é só isso, por trás disso tudo existe um valor que a "Simplicidade" o XP se utiliza muito desse valor. A idéia é fazer a coisa mais simples que possa funcionar. Vou explicar mais sobre isso na seqüencia e você entenderá por que as coisas são assim no XP. Com um sistema simples, logo os problemas são resolvidos de maneira simples e o mesmo objetivo que o RUP consegue através da arquitetura o RUP consegue também.
Requisitos
Bom aqui é a onde existe mais polêmica, prometo que vou apenas explicar as duas abordagens dos dois processos sem entraras no mérito de qual é melhor, mas em determinados pontos concordo que o Kent Back tem algumas idéias AnarcoPUNK.
Como o XP trata os Requisitos? Na visão de uma Analista de Requisitos de forma absurdamente "tosca"; Como as coisas ocorrem? Pois bem como o XP prega que não devemos viajar com muita bagagem logo não é bom (Segunda o ótica do XP) produzir documentação detalhada.
Nota: Esse valor de não produzir uma documentação detalhada é um valor que existe apenas no XP, as outras metodologias agéis não acatam esse 'valor'.
Por que? Com o no XP o cliente está na sala ele pode passar de forma oral o que deve ser feito para os programadores e como no XP ele "Acolhem a mudança" e sempre fazem "Refactorings" e o código é "simples" eles podem aplicar as mudanças a qualquer momento *sem maiores problemas*
Nota: Vamos ao *sem maiores problemas* na verdade nem sempre é assim, muitas vezes isso pode funcionar bem em outras não e levando o projeto ao fracasso, através do Anti-Pattern chamado "Creeping Requirementes".
No RUP as cosias são diferentes, no inicio as mudanças são mais freqüentes depois o processo prega que devemos "Gerenciar as mudanças" através de uma mecanismo eficiente. Como o RUP prega dois níveis de análise, primeiro uma análise de alto nível de negócio onde 80% dos requisitos de negocio mais importantes eram abordados. Após essa análise de negocio existe um workshop com a arquitetura onde 20% dos requisitos mais importantes para a arquitetura são abordados são revisados. A partir disso que a arquitetura é começada a ser criada.
Como vocês podem perceber o RUP prega mais tempo em requisitos e mais tempo em arquitetura do que o XP, assim as mudanças acabam sendo menores.
Não podemos nos esquecer que boa parte dos Refactorings que acontecem em um projeto XP acontecem por que a metodologia XP não investe um tempo suficiente em requisitos. Como programadores não tem tal habilidade muitas vezes isso é um problema em um projeto XP.
Mesmo assim não quer dizer que não funcione
Existem registros de projetos utilizados em situações totalmente adversas dos cenários habituais de uso das metodologias. Existem registros de projetos RUP que foram executados em uma semana com poucos profissionais e que funcionaram muito bem. Como também existem registros de projetos XP com até 60 pessoas com 2 anos de projeto que foram um sucesso.
Quanto a disciplina de cada metodologia
Esse ponto é muito interessante de ser abordado, por que aqui acontece um fenômeno ao contrário. Por que normalmente as pessoas olham o RUP e dizem: "Bah aquele monte de artefatos e é muita coisa, que horrível!" e as mesas pessoas olha o XP e dizem "Mas que maravilha poucos artefatos, bem mais flexível!" Essa pessoa está totalmente errada!
XP é uma metodologia eXtremamente Disciplinada, onde o número de artefatos opcionais é quase zero. Você deve utilizar todos os artefatos e práticas no XP para dar certo e tirar proveito disso, e não sou eu que estou dizendo isso vem do próprio Kent Back.
Já no RUP a coisa é justamente o contrário, a metodologia é muito mais flexível do que o XP, isso ai mais flexível. A maioria dos artefatos são opcionais. Confira aqui os artefatos mandatários. Por que o RUP é um framework e lá existem diversas práticas para diversas áreas e você não deve distanciar tudo.
Voltando a figura principal e concluindo
A abordagem do XP é diferente em diversos pontos em relação ao RUP, porem existem muitos princípios que são de comum compartilhamento. A diferença maior está na abordagem, que como a figura a cima mostra está no grau de formalismo. Mas quero salientar a diferença quanto a "Client Driven" vs "Risk Driven". É fato que existem situações que uma é muito melhor que a outra. Tal constatação vem tanto do RUP quanto do XP.
Mesmo assim ainda podemos fazer algumas "misturas" de práticas das duas metodologias como a "Integração Continua" do XP com a gerência de Mudanças do RUP.
Abraços e até a próxima.
