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.
An example of the project with duration of 1 year and 1000 function points will be described below.
RUP lifecycle
Using the default RUP lifecycle, most probably the earliest opportunity to deliver anything approaching production quality to the customer would be at the end of the first construction iteration, which occurs six months into the project. However, at this time, RUP could deliver about one quarter, or 250 function points, of the total capability. XP delivers 83 function points monthly and approaching production quality will be delivered after three month and will be deliver the same 250 of 1000 function point.
Normally in RUP the first delivery to the customer would occur at the end of construction, which in this case would be 10 months into the project, at which time essentially all capability would be present (1000 functional points), This does not mean this is the first time the customer has seen the product with RUP, the customer is invited to the iteration assessments and can see the evolving product under test. XP will deliver 830 of 1000 functional points till the end of RUP’s construction phase.
Why does this difference exist between RUP and XP? It occurs because, in this default case, the assumption is that there is enough risk in the architecture of the solution (because, for example, it is unprecedented, or the technology is new, or the nonfunctional requirements are particularly onerous) to warrant two iterations in elaboration to stabilize it, in advance of trying to build the customer-required functionality. This means that by the end of elaboration, only the architecturally-significant requirements will have been explored (and possibly implemented).
XP does not do this. It proceeds to deliver a series of vertically complete solutions with each release, the assumption being that the architecture will not break between releases or that refactoring can repair any breakage that does occur. We believe that this limits the sensible application of XP to classes of system that can be built on existing architectures of known capability.
XP techniques such as pair programming and refactoring could be embedded within a larger RUP project, but only once the architecture is stable.