- What Is Different about an Agile Project?
- Introduction to Extreme Programming
- Isn't XP Just Hacking?
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Introduction to Extreme Programming
Extreme Programming (XP) isn't actually a software methodology in the traditional sense because it avoids precisely defining the organization of a development project. Instead, it promotes values and practices that help people on a software team to do the right thing during the course of their work. Therefore, over the next few pages, we introduce XP by explaining how it is intended to help teams produce useful software over the life cycle of their projects.
Software Project Life Cycle
Software products start with an idea, but usually there is some reason why that idea can't be acted upon immediately. Typically, this is because implementing the idea would mean involving other people or otherwise spending money. However, if the idea is good enough and is sufficiently well promoted, someone might eventually put together a formal proposal, which is how a project starts in most organizations. Once the proposal has been accepted, a budget will be allocated to the project so that the proposal can be developed, and the work necessary to realize the idea begins. The project will then continue until there is no more money or enthusiasm to develop the idea further, at which point it ends; job done, product shipped, everyone is happy. The activities people perform between the start and end of a project are described in terms of a software development life cycle (SDLC).
Iterative and Incremental
An XP project is evolutionary; that is to say, it is iterative and incremental. This means its software is developed in a series of cycles which each deliver some working software (iteration) that builds upon what has gone before (incremental). One of the key aspects of XP is the way software is improved through small incremental changes made in short iterations that last weeks, not months.
The SDLC of an XP project starts with a small team being assembled to implement a number of features which have some value to the people investing their time or money in the venture; in other words, the business. These features are described in terms of a collection of stories which are prioritized by the customer so that the ones with the greatest business value are done first, which is to say the development sequence is decided for business rather than technical reasons. Stories are sized at a few days' work, not more. Each developer then undertakes to implement one or more of these customer stories by splitting each one into its constituent tasks and estimating the total time it will take him to complete the work. The developers continue to undertake stories (according to the customer's priorities) until they are fully committed in terms of the time they have available and their estimates for the work they must do during an iteration.
Iteration and Release Cycles
Life cycle diagrams typically illustrate the separate phases of development with a series of pictures, but as an Agile project doesn't have such distinct phases, it's more appropriate to show its life cycle as a series of timelines; see Figure 3-2.
)
Figure 3-2 Agile software development life cycle: tasks, stories, iterations, and releases
The timeline at the bottom of the figure shows how an Agile team might implement a collection of stories during a weekly iteration cycle such that it releases some software to the business after the third week and then continues with its weekly cycle in subsequent weeks. Though we don't actually show the iterations after the fourth week, you can imagine that a release cycle would be formed by further releases of software occurring at the end of other iterations.
During a weekly iteration, the developers work with each other on the coding tasks needed to implement their respective stories, as shown in Figure 3-2's middle timeline. Each task is completed in a "programming episode" lasting an hour or two, during which test-driven development (TDD; see Section 5) is performed so that dozens of structural (unit) test cases are created; this is shown by the thin vertical bars at the top of the figure. In this way, a customer story is implemented by decomposing it into a series of small tasks, each of which is divided into a series of small steps (tests) which individually take only ten minutes or so to complete.
Iterations Deliver Production-Quality Code
Because the developers are writing production-quality code, even by the end of the first iteration the customer has a working product that supplies at least some of the features the business wants implemented. The customer knows these features work because they pass his acceptance tests, which he wrote during the iteration with the help of a developer; see Section 7. Therefore, this software could be shipped straight into the production environment and start giving some immediate payback, but it is more likely that the customer will decide to wait for a few more iterations so that he has something really useful before disrupting the business by giving it a new release. Accordingly, the second iteration will start and be run in the same way as the first, but new stories may be created and existing ones changed or discarded because the customer, having actually used the product, is now better aware of what is really needed. Slowly, iteration by iteration, the list of valuable features grows until the business representative on the team (customer) decides it is time to release the product into production. This is shown happening at the end of iteration 3, in Figure 3-2.
Project Closure
The team continues with these iteration and release cycles until the supply of stories dries up, which usually happens when the business decides that it has received sufficient value from its investment. At this stage, the project ends and the life cycle is complete. The developers will then write a short document that will help anyone who might need to restart the project in the future, and finally will mothball the project so that they can move on to something more profitable.