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 ?
Regards<br />Ramu Meda<br />moderator of yahoo groups scdjws_meda,scjp_meda,scwcd_meda,scbcd_meda,java-architect,ooad_meda, weblogic_meda, oracle9isql_meda, oracle9idbf1_meda<br /> <br />You will find Excellent resources there !
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 ]
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
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.
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.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
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.