Ref: http://articles.techrepublic.com.com/5100-10878_11-1046488.html
I am a skeptic; I don’t deny it. Some even accuse me of being resistant to change. So when a new development methodology comes along with the amount of hype that Extreme Programming (XP) has generated, I'm slow to jump on the bandwagon.
XP was conceived and developed by Kent Beck, who wrote , the book based on his concept. The book addresses the issues faced by small development teams working in an environment of ever-changing requirements. Sound familiar? XP is not so much a standard as it is a series of processes or methods designed to help tackle these issues. Many of the methods suggested by XP followers are intuitive and are already incorporated in some manner within common development environments. The practices Advocates of XP identify 12 rules (or practices) to follow during the development process:- User stories (planning): User stories can be viewed as a watered-down version of use case. The customer defines the desired features for the new application and describes each feature's business value and priority. These are to be kept brief, with only enough detail to give an understanding of the request. The project team will employ the user stories for cost estimating and project management.
- Small releases (building blocks): With XP, you develop and deliver the application in a series of small, frequently updated versions. As each new requirement is added, complete the system and re-release.
- Metaphor (standardized naming schemes): XP systems development requires adhering to a set of standards for items such as variable names, class names, and methods. Employing this system of names should allow for the intuitive understanding of each item.
- Collective ownership: No one person owns or is responsible for individual code segments. In turn, the code is reviewed and updated by everyone on the team, allowing for a more collaborative effort.
- Coding standard: All team members write code in the same way, using the same styles and formats. This allows for rapid code sharing and reduces the learning curve for other developers.
- Simple design: The best design is the easiest one that works. A correct design for an XP system is one that runs all unit and functional tests, meets the business value, and does it only once for each function.
- Refactoring: Communication between team members is crucial. Each member should have a synchronous understanding of the application and should continually work to adjust and improve the code. This allows the system to be constantly revised without duplicating code.
- Testing: Each building block (small release) must be thoroughly tested prior to release. Write the tests first and develop the code to meet the requirements of the test. This allows for a clean application in the long term by flushing out problems before they get lost in a large application.
- Pair programming: XP programmers work in pairs. All code is developed by two programmers who work together at a single machine. The expectation is that pair programming produces higher quality code at the same or less cost.
- Continuous integration: Software builds are completed several times a day. This keeps all developers on the same page by keeping the application up to date with the most recent coding changes.
- 40-hour workweek: For XP practices to be effective, developers must be on top of their game. Experience has shown that tired or sleep-deprived developers make more mistakes and are more subject to burnout—resulting in lower-quality code.
- On-site customer: One of the most important concepts of XP is the need to have the customer as an integral part of the development effort. The customer must be available at all times to set priorities, deliver and establish requirements, and answer questions.