Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The XP Lifecycle
The lifecycle of an XP project is similar to that of any other development approach: Find out what the customer wants, make sure you know what they want, estimate the effort to complete, build the solution, and deploy to the customer. As you would expect from XP, there is a twist or two. The cycle is much faster than in a classic development approach and may be completed many times. The other alarming difference from a project manager's viewpoint is the lack of documentation present throughout. Hard to find a humble Gantt in the project war room. (Not that Gantt charts can't be used in XP; it's just hard to see how you would build them and what value they would add. Save your copy of Microsoft Project for your next waterfall engagement.)
Broadly speaking, XP projects involve chunking down a vision into releases and the iterations that make up each release. Planning is seen as an evolving process that's refined and tuned over the life of the project.
Let's take a look at the key stages of an XP project.
Exploration
Exploration is where discovery of the system vision and mission occurs. I still remember when I described going on a "journey of discovery" with clients. The manager got that look: "He's finally lost it now!" All we're doing is recognizing and naming what happens during most development projects; the uncertainty, change, and shifting imperatives.
In this inception phase, the customer develops primary high-level user stories and developers estimate time to implement. There's an implicit understanding that any estimates at this stage are rough and will be refined at iteration level as we progress. In some cases, developers spike solutions (spend time prototyping and researching technical issues) to get a more accurate estimation figure. Technology specialists or consultants may be used to validate high-level approaches and they may help in spiking.
The exploration phase is measured in a few weeks or days and the output is a high-level plan. The plan will give the customer and team a sense of budget and release schedule.
Planning
Planning is a short phase in which customers and developers agree on features for the first release. Features (user stories) are delivered in a way that makes both business and technical sense. This XP practice involves customers and programmers working through user stories, estimating, and prioritizing. Calling this practice the planning game can be problematic to management or the marketers. For example, the large consulting firm I work in shies away from the use of some XP monikers and recasts them to more "edible" names.
Really, the name is immaterial; the important thing to grasp is that the event is informal, lightweight, and pragmatic. User requirements are written on index cards and are handled/discussed during the planning game. Using index cards may seem a little anachronistic initially but is a highly effective tool. The simple utility of the cards connects customers and programmers to meet common goals. Another handy side effect is that they never crash or need a reboot!
The output is a release schedule—not a work breakdown structure. The iterations to release are handled separately.
Iterations to First Release
The release is reduced to a number of iterations with a typical length of 1–4 weeks. The initial iteration focuses on the architecture components required to provide a baseline system. Each of the iterations should deliver business value that continues to grow over time. Subsequent iteration content is driven by the customer; they pick the stories they want and developers complete the build. This "customer can change their mind" approach can be frustrating to developers; the only consolation is that the iteration is timeboxed. Timeboxing means that the scope doesn't change—just the user stories being developed. (In our implementation of XP, we usually only add development resources to increase velocity, not to allow "scope creep.")
Iterations are also used to measure progress. Results are then fed back for future planning. During the iteration, the team uses continuous integration supported by automated build frameworks.
At the end of the iteration, customers perform the acceptance tests they've written.
Productionizing
At the end of the release, the product is verified and certified for deployment into the customer production environment. This phase may involve some system or application tuning, depending the target environment. Tuning can be executed in the staging environment, assuming that it mirrors production. (Customers normally refuse developer access to production code, anyway.) The goal is not to continue functional evolution but to stabilize the system.