• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RUP Vs XP

 
Ramu Meda
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can some body explain in nutshell, the applicability of these two i.e RUP and XP for the J2EE projects in particular ? where should use what and what the advs of each for a praticulat scenario ?
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Really depends on the individual project. Does your company or customer require a process that defines a lot of artifacts? Will the customer be co-located with you? There are a lot of issues to consider. The more formal the process needs to be the less likely XP will be appropriate but it can be done. In some cases it isn't an either-or proposition. Check out this article.
[ April 27, 2004: Message edited by: John Wetherbie ]
 
Mike Winter
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ramu Meda said:
Can some body explain in nutshell, the applicability of these two i.e RUP and XP for the J2EE projects in particular ? where should use what and what the advs of each for a praticular scenario ?

Please read Luke Hohmann: "beyond software architecture".
In brief, XP & RUP are not mutually exclusive, they each contain aspects of the other, hence the difficulty of separating concerns to distinct arguments. Rup has a tendency to go to waterfall model with process or artifact bloat, but scales well beyond teams greater than a few tens of people. XP does not scale well, but sometimes RUP is too much and the process monkeys still insist on doing RUP, where a pragmatic approach may suggest the heavyweights step aside for anything that can be done in a short time frames by less than 5 developers using X 'less docs' P.
You notice I left a gap in that posture and this is the essence of the arguments, neither approach is a silver bullet and each contain best-practices that should be favored over the other when scale and agility are at odds.
The best practices of XP that I particularly am interested in include pair-programming and test driven development. These may be effectively executed in both methods without breaking any rules, and so I assert, they are examples of best-practice that should be practiced. I think user-story-cards are somewhat wishful thinking. Rarely do users truly know what they want, but dialog and face-to face communication is critical in developing the user-stories. This is done in both schools of thought.
However, large scale scoping and planning is difficult at best and so fear plays a considerable part in causing what Robert Martin calls "process bloat", in response to the unknown. I think there is almost always choice, and the autocrats that impose process become self limiting and to ask them in their state of fear to take a leap of faith with 'minimal skimming requirements' and 2 week iterations is a challenging process of enrollment and trial with little room for error.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ramu Meda:
Can some body explain in nutshell, the applicability of these two i.e RUP and XP for the J2EE projects in particular ? where should use what and what the advs of each for a praticulat scenario ?

RUP is a process framework - it defines a whole bunch of activities and artifacts you need to choose from to build your own, individual process.
XP is a set of minimal practices - you are supposed to use them all at the beginning of a project and adapt them and add additional ones as when you experience the need.
XP can technically be seen as an instance of RUP, though they seem to be somewhat different in culture. In fact, Rational even provides an XP plugin for its RUP software.
In my opinion, for a team up to a dozens developers, XP is a quite good starting point.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Winter:
XP does not scale well

At least that's what Kent Beck feared when he wrote his book. And it's probably still advisable to start learning XP in rather small teams.
On the other hand, Thoughtworks is known for running much larger "XPish" projects than Kent ever had dreamed of; and I rember Robert Martin stating that every time he starts a new project, he feels as if he can scale XP to an even bigger team.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic