Extreme Programming Practices in Action
- Understanding How XP Practices Work Together
- The Planning Game
- Small Releases
- Metaphor
- Simple Design
- Testing
- Refactoring
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40-Hour Work Week
- On-Site Customer
- Coding Standards
- Summary
- Q&A
- Workshop
See all Sams Teach Yourself on InformIT Programming Tutorials.
Extreme Programming (XP) is the most popular of a whole new breed of simple, fast, and easy-to-use software development approaches. "Sams Teach Yourself Extreme Programming in 24 Hours" differs from the rest of the XP book range in that it guides readers through the entire XP project lifecycle. This book describes the early beginnings of software development; how companies attempted to reverse the tide of project failure through tighter controls. XP is part of a group Agile software development approaches that builds on lessons learned, adding more dynamic, change-friendly methods.
"Sams Teach Yourself Extreme Programming in 24 Hours" is aimed at developers, project managers, testers and designers. Project managers will discover how their roles change under XP, as they place emphasis on the people side of development. Software developers get to grips with unit testing tools, such as JUnit and NUnit. They also gain insight into XP practices such as, Pair Programming, Test First Development and the Planning Game. This book is applicable to both Java and Microsoft development teams.
XP has a rock-solid software engineering base where integrating tests, real-time code review, and quick release cycles all ensure quality of code. The good news is that most of the software development tools used in XP are free!
— Stewart Baird
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this hour we will study the 12 XP practices that you will use in your project. We will cover
What the XP practices are
How the practices work together
The programming, team, and process aspects of the practices
Understanding How XP Practices Work Together
XP has 12 core practices that describe how the team will develop the system. You might notice that most of the XP practices are already in use and are recognized as software engineering best practices; what's new is using them in a concerted way. A good example of how this works is by taking a practice such as "collective ownership of code." In isolation using this practice could lead to chaos because anybody can change the system without constraints. In XP, however, pair programming, coding standards, and testing all balance collective ownership. Therefore, the weakness of a particular practice is mitigated by the other balancing practices.
The other aspect of these best practices that distinguishes XP is how they are taken to extremes. A common practice is done in a more intensive, rigorous manner, pushing the practice as far as it can go. We could separate the practices into three categories, listed in Table 6.1.
Table 6.1 XP Practices Separated by Category
|
Category |
Practice |
|
Programming |
Simple design, testing, refactoring, coding standards |
|
Team |
Collective ownership, continuous integration, metaphor, coding standards, 40-hour week, pair programming, small releases |
|
Processes |
On-site customer, testing, small releases, Planning Game |
Table 6.1 was adapted from Extreme Programming—Explored, by William C. Wake.
As you can see there is some crossover between the three areas. Unlike most software-development methodologies, XP has specific practices that describe how actual coding is done. Practices such as testing and pair programming offer easy-to-follow, practical guidance to developers.
XP is not just mechanical assembling of practices, but is built on values and principles. We can group our XP practices together, reflecting how they relate back the principles of XP. Table 6.2 lists the XP practices and relates them to the underlying core principles.
Table 6.2 The Values and Principles of XP
|
XP Principle |
Related Practice |
|
Fine scale feedback |
Test Driven Development |
|
The Planning Game |
|
|
On-site Customer |
|
|
Pair Programming |
|
|
Continuous process rather than batch |
Continuous Integration |
|
Refactoring |
|
|
Small Releases |
|
|
Shared understanding |
Simple Design |
|
System Metaphor |
|
|
Collective Code Ownership |
|
|
Coding Standards |
|
|
Programmer welfare |
40-Hour Week |
Table 6.2 was adapted from Extreme Programming Core Practices, Portland Pattern Repository. February 12, 2002, http://www.c2.com/cgi/wiki?ExtremeProgrammingCorePractices.
To summarize, the 12 XP practices work together, complementing each other. The sum of the parts is greater than the whole. Now, let's look at each practice in turn.