Reading Time: 3 minutes
Yes there is, but XP’s “activities” are not formally identified or described. you’ll find it headed “Define requirements with stories, written on cards” and then throughout the chapter is a mixture of process description and guidance about what use stories are and how (and by whom) they should be produced. And so it goes on, as the books describe XP under major headings; “things done” and “things produced” are described with varying degrees of prescription and detail. RUP’s apparent prescription comes from its completeness and greater formality in its systematic treatment of activities, and their inputs and outputs. XP does not lack prescription, but perhaps in the attempt to remain “lightweight”, the formality and detail are simply omitted. The detail that is present in RUP will have to be added when XP is implemented on a project. Lack of specificity is not a strength or a weakness, but you should not confuse the lack of detailed information in XP with simplicity. At some point, the people on the project will need to know what to do and at that time will need the detail.
Reading Time: 3 minutes
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.
Reading Time: 2 minutes
General XP’s phases are exploration, commitment and steering. At the release level, these align with particular collections of activities, called workflow details in the RUP Project Management discipline.
Exploration and Commitment phases could be mapped into the Plan for Next Iteration and Steering could be mapped into Monitor and Control Project phase.
In Extreme Programming by Kent Beck, there is a lifecycle of an ideal XP project, and the first level headings are exploration, planning, iterations to first release, ‘productionizing’, maintenance and death . These appear to be the top-level phases, but it turns out this is not quite accurate. An XP project will be bounded by an initial exploratory phase and “death” when the project is closed out. But the major beat is the release and each release has an exploration phase . So the exploration phase that brackets the project (and leads into the first release) is a special case in that there is an initial gate to pass at which a decision is made on the wisdom of continuing at all. Both XP releases and iterations have the three phases exploration, commitment, and steering. “Maintenance” really characterizes the nature of the XP project after the first release.