Extreme Programming
Extreme Programming (XP) is one of the more well known Agile methodologies. As its name suggests it is a programmer-centric methodology that emphasizes technical practices to promote skillful development through frequent delivery of working software. Although XP (and Agile methods as a whole) is often characterized as less rigorous then traditional techniques, this could not be farther from the truth. XP got its name when its founders asked the question, "what would happen if we took each technique/practice and performed it to the extreme? How would that affect the software process?" An example of this is the practice of code reviews. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value. In truth, full adoption of all of XP's practices requires a high level of discipline, teamwork, and skill.

One of the characteristic distinctions between XP and other methodologies is its cycle time and level of ceremony. XP recommends very short iterations between one and four weeks. XP is also a very low ceremony methodology. Minimal artifacts in an XP project include story cards, code, and unit tests.

But XP is most commonly known for its technical practices. At the heart of XP are four core values: communication, simplicity, feedback, and courage. From these values 13 practices are derived. Theses practices are:

1. Planning Game: Plan work incrementally.
2. Small Releases: Release as quickly as possible to increase time to market, and get feedback as soon as possible.
3. Metaphor: If possible, define a metaphor for the system being developed. For example, the shopping cart metaphor is widely used to describe an online ordering system.
4. Simple Design: Use the simplest design that will work for the functionality (user story) being implemented. Do not design for things that may never actually be used.
5. Testing: Test everything, and try to automate the testing if possible.
6. Refactoring: Instead of designing the entire system up front, design as you go, making improvements as needed. Change the implementation without changing the interface to the functionality, and use automated testing to determine the impact of the refactoring.
7. Pair Programming: Programming in teams of two (or three) allow for a discussion to occur in real-time that addresses requirement, design, testing, and programming concerns.
8. Collective Code Ownership: Anyone on the team can make a change to any code at any time.
9. Continuous Integration: The entire code base is constantly being rebuilt, and retested in an automated fashion.
10. Sustainable Pace: Ideally, team members do not need to work more than 40 hours per week to meet project deadlines. Burning the midnight oil is chunked by management in favor of consistent, predictable, repeatable delivery.
11. Whole Team: The team functions as a whole. Members are encouraged to be more generalized than specialized. Learning about all technologies and requirements is encouraged.
12. Coding Standards: In order to maximize communication, coding standards are defined by the team, and used to ensure consistent coding practices.
13. Onsite Customer: Having constant and direct access to the customer allows the team to work at the fastest possible speed.

These practices support one another, as illustrated in Figure 1, and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

Figure 1. XP Practices. The practices in XP support one another and thus care should be taken to understand these relationships when modifying XP.

Another distinction between XP and other Agile methodologies is its approach to requirements gathering. The primary requirement artifact in XP is the user story. Visibly, a user story is nothing more than a note card with a short description on it. But user stories actually are comprised of the card (reminder of promised functionality), conversations between developers and requirements donors, and tests (all types: unit, integration, acceptance, etc.).

There are two primary types of planning activities that are referred to in XP parlance as planning games: the release and iteration planning games. And each planning game is characterized by three phases: exploration, commitment, and steering.

Release planning begins with the customer writing story cards and prioritizing them. Programmers then estimate the stories from which a velocity can be derived. Velocity describes how much work the team can accomplish in any given time frame. The customer then chooses a scope for the release based either on desired functionality or release date. The steering activities for release planning occur at iteration boundaries when progress towards the planned release date can be tracked and adjustments can be easily made.

Iteration planning follows a similar pattern to release planning. Each iteration begins with developers taking stories and breaking them into tasks. Programmers accept responsibility for tasks and estimating the tasks that they are responsible for. Each programmer's load is compared to their historical performance to determine whether anyone is overcommitted and to allow the workload to be balanced across the team. Throughout the iteration programmers partner to complete tasks by writing unit tests and code. Periodically throughout the iteration a member of the team checks on the progress of the team and communicates this information to all team members so adjustments can be made.

There are a small number of roles on an XP project. These include:

• Customer—The customer creates and prioritizes the stories that need to be implemented. Because the customer sets the priorities she controls what will be delivered in any given release and can control the release date by adding and removing stories.
• Programmer—Programmers collectively estimate stories, but individually accept responsibility for tasks which they estimate, write tests, and code.
• Coach—The coach monitors the software development process, mentors team members on XP process and techniques, and focuses the team's attention on potential problems or optimizations.
• Tracker—The tracker monitors the progress of the team and alerts them when adjustments to the schedule or a re-balancing of tasks might be required.