Ref: http://articles.techrepublic.com.com/5100-10878_11-1046568.html

Have you noticed that the old way of developing applications just doesn’t work anymore? According to Software Magazine, only 28 percent of IT projects succeeded in 1998, and the success rate diminishes as the cost and size of the project increases. The pace of business has increased, and from an IT standpoint, that calls for extreme measures. Extreme programming (XP), to be specific.

Traditional projects tend to use sequential phases, with most of the work completed in one phase prior to starting the next one. Although the phase names may differ, these are the primary activities:

• Customers write requirements.
• Developers write functional specifications.
• Developers write technical and design specifications.
• Developers write code.
• Developers write test cases for unit and system testing.
• Customers write user acceptance tests.
• Developers migrate the system to production.

If you’re using this approach, you may notice the following:

• Customers are involved only at the beginning and the end of the process, with little feedback in between, which can cause major disconnects between what is needed and what is delivered.
• Requirement changes can be a major disruption, since every prior activity will need to be redone.
• Developers tend to add many “undocumented” features and functions to eliminate any potential rework—even if the user never asked for them.
• There are likely to be one or two “super” developers who dominate the development effort, which may get the project done but also puts the company at risk if they decide to leave the firm.
• Testing in the later stages of the project can be a major undertaking since all the separate components need to be integrated prior to any comprehensive testing.
• Users don’t trust the developers since there’s no transparency in the process, and developers don’t trust the users since their changes are a major inconvenience. And of course, this mutual distrust deteriorates as delivery dates slip.

Despite these problems, we continue to use methodologies similar to those mentioned earlier, although we know (deep inside) that they’re too rigid and too bureaucratic to enable the delivery of effective IT applications at the speed of business today. We need a better way—and it’s provided by Extreme Programming (XP).

Kent Beck created XP as a lightweight methodology that’s especially effective for small- to medium-size projects with ambiguous or rapidly changing requirements. It’s lightweight because although there are practices you must do in order to be extreme, it is not process-centric. And it’s called extreme because it takes many fundamental development practices to an extreme level to emphasize their importance and to accelerate the pace of programming for the delivery of a business application—the primary reason we all develop software.

XP’s organizing principle is to embrace change. Since change is an inevitable truth of any software development effort, why not develop methods for dealing effectively with change rather than build bureaucratic change processes and procedures? The bureaucratic approach just distracts from the ultimate goal of delivering the software product. For this, XP has a kind of hierarchy of tenets, including values, principles, and practices. Its values of communication, feedback, simplicity, and courage, together with core principles such as rapid feedback, incremental change, and quality work, provide developers and customers with a foundation for developing high-quality software products quickly. But XP’s 12 practices are the real drivers of results.

The 12 practices of XP

1. The planning game: Create a simple plan that everyone can understand and refine it as the project evolves—customers write the stories (requirements), developers estimate the stories, and customers prioritize the stories.
2. Small releases: Get the highest priority stories completed within, say, three weeks, with a goal of a production release within three months.
3. Metaphor: Get everyone on the same page with a system metaphor, building a warehouse or a factory, which will also help in consistent naming of classes and methods.
4. Simple design: Create the simplest thing that will work.
5. Testing: Create the tests before programming and run them often.
6. Refactoring: Get rid of everything except the simplest thing that will work.
7. Pair programming: Work side-by-side with someone (on the same terminal) to create better programs in less time.
8. Collective ownership: Remember that everyone owns all the code, and no one owns any piece of code.
9. Continuous integration: Integrate all the components at least once a day, if not more.
10. The40-hour week: Keep everyone fresh and rested so they can be at their best when they program.
11. On-site customer: Have at least one customer on the team, writing functional tests, setting priorities, and making business decisions as the code is being written.
12. Coding standard: Since all the code is shared, some discipline is needed in writing and documenting code so anyone can work on any program.

Although some of these practices can stand on their own, their strength comes from using as many of them as possible since they work so well together. For example, having a full suite of reliable tests available along with continuous integration can give developers the confidence to refactor or implement new code quickly. If the code passes the tests, they know the change will work and won’t disrupt production. Also, having an on-site customer facilitates planning the work, and simple designs lead to small releases, which are fully functional (because of the tests), which means people can go home at a reasonable hour.

XP benefits
XP provides benefits to developers, customers, and ultimately, the business. Overall, it provides a basis for mutual trust and commitment to the initiative, rather than the typical adversarial relationship that tends to emerge between developers and customers as projects mature. The underlying reason is that both parties are empowered to make the decisions they’re most capable of making: Customers make the business decisions, and developers make the technical decisions.

You may be saying, “Of course—but isn’t that true with any methodology?” Well it should be, but it isn’t. Customers tend to write the requirements and then go back to their day jobs. And because of their lack of access and involvement, developers are left to make business decisions so they can move the project forward. Vendors have also been known to contact customers directly and persuade them to make technical decisions they’re not qualified to make in order to close a sale, leaving developers completely out of the loop on an initiative they will eventually need to support. XP eliminates this dysfunctional behavior.

For developers, XP provides:

• The big picture, giving meaning to the effort.
• A prioritized list of features and functions that are needed.
• The ability to provide work estimates rather than have them assigned.
• Access to the people and resources that help them deliver results.
• An opportunity to do quality work that matters.
• A civil and humane working environment.

To customers, XP provides:

• Complete transparency into the project from beginning to end.
• Consistent and productive results.
• The ability to change the direction of the project without absorbing major costs and disruption.

To the business: