One reason is that XP doesn’t have the scope of RUP. This is quite intentional: XP is about programming to meet a business need. How that business need occurred and how it’s modeled, captured, and reasoned about is not XP’s main concern. The XP team member who is the customer presents the distillation of requirements as stories to the XP development team;
they are also the arbiters of business value. The magic of how the stories came to be expressed (or expressible) in that form is not the concern of XP. So, for example, what RUP describes in its Business Modeling discipline is outside the scope of XP (Business Modeling in RUP has ~14 artifacts). XP describes a process that has regular releases to the customer. The logistics of deployment of these releases are not the concern of development,
so the RUP Deployment discipline is largely outside the scope of XP (Deployment in RUP has ~9 artifacts). Therefore, for a small project amenable to XP, you would expect to omit ~23 artifacts when tailoring RUP.
Another reason is that XP asserts that requirements and design capture can be done rather simply: requirements are captured as user stories (which may sometimes have to be split) that are then decomposed into tasks which, in essence, are the design keeping in mind a metaphor for the system. Is this possible for all systems? Definitely not.
Is it possible for some systems? Certainly, and to be fair to XP it doesn’t claim to address all systems. Also, perhaps the XP authors had their tongues firmly planted in cheek when making these claims.
The desired behavior of larger, more complex systems can be very difficult to articulate without some systematic approach such as use cases. Neither will it be possible to rely on conversation between customer and developer to consistently elaborate complex user stories, human memory being as fallible as it is.
Also, developing the structures that realize complex behavior in large systems is aided by the ability to form and reason with various abstract views of the architecture of that system. The artifacts RUP describes in the Requirements (~14 artifacts) and the Analysis and Design disciplines (~17 artifacts), enable it to cope with the variety, size, and complexity of these systems.
In RUP’s small project roadmap, the count of artifacts (for Requirements and Analysis & Design) is reduced to seven, with some of the reduction achieved by simply referring to the composite artifact. This is no sleight-of-hand; it deals with artifacts in just the same way as XP.
For example, because of the way it’s likely to be realized in a small project, RUP says the following about the Design Model:
“The Design Model is expected to evolve over a series of brainstorming sessions in which developers will use CRC cards and hand-drawn diagrams to explore and capture the design. The Design Model will only be maintained as long as the developers find it useful. It will not be kept consistent with the implementation, but will be filed for reference.”
Finally, RUP allows for a greater formality (and “ceremony”) in project management, where this is necessary, and in some contract arrangements it will be. Again, many of RUP’s project management artifacts (there are 15 in the Project Management discipline) are part of composite artifacts, and need only be realized as separate documents when the formality of the project demands it.
For example, in RUP the Software Development Plan “contains” artifacts such as the Risk Management Plan and Product Acceptance Plan. In smaller, less formal projects it may be possible to deal with the issues addressed by these plans simply with a paragraph or two in the Software Development Plan. In the small project roadmap in RUP, the number of project management artifacts is reduced to six.
Based on IBM whitepaper “A Comparison of the IBM Rational Unified Process and eXtreme Programming”. Download full version in PDF format. (Size: 363KB)