Extreme programming practices


Extreme programming is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Fine-scale feedback

Pair programming

is a method of programming in which code is produced by two people programming together on one task. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers trade roles after minute to hour periods.
The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication..

Planning game

The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:
  • Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
  • *Exploration Phase: In this phase the customer will provide a shortlist of high-value requirements for the system. These will be written down on user story cards.
  • *Commitment Phase: Within the commitment phase business and developers will commit themselves to the functionality that will be included and the date of the next release.
  • *Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed.
  • Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases:
  • *Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards.
  • *Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
  • *Steering Phase: The tasks are performed and the end result is matched with the original user story.
The purpose of the Planning Game is to guide the product into delivery. Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery using a straightforward approach. The Planning Game approach is used in development frameworks beyond just software systems. For example, it is used by teams in the context of business agility.

''Release planning''

Exploration phase
This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.
  • Write a Story: Business has come with a problem; during a meeting, development will try to define this problem and get requirements. Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story. The story is written on a user story card.
  • Estimate a Story: Development estimates how long it will take to implement the work implied by the story card. Development can also create spike solutions to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements.
  • Split a Story: Every design critical complexity has to be addressed before starting the iteration planning. If development isn't able to estimate the story, it needs to be split up and written again.
When business cannot come up with any more requirements, one proceeds to the commitment phase.
Commitment phase
This phase involves the determination of costs, benefits, and schedule impact. It has four components:
  • Sort by Value: Business sorts the user stories by Business Value.
  • Sort by Risk: Development sorts the stories by risk.
  • Set Velocity: Development determines at what speed they can perform.
  • Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined.
    Sort by value
The business side sorts the user stories by business value. They will arrange them into three piles:
  • Critical: stories without which the system cannot function or has no meaning.
  • Significant Business Value: Non-critical user stories that have significant business value.
  • Nice to have: User stories that do not have significant business value.
    Sort by risk
The developers sort the user stories by risk. They also categorize into three piles: low, medium and high risk user stories. The following is an example of an approach to this:
  • Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
  • *Completeness
  • **Complete
  • **Incomplete
  • **Unknown
  • *Volatility
  • **low
  • **medium
  • **high
  • *Complexity
  • **simple
  • **standard
  • **complex
All indexes for a user story are added, assigning the user stories a risk index of low, medium, or high.
Steering phase
Within the steering phase the programmers and business people can "steer" the process. That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong. This is the chance to adjust the plan accordingly.

''Iteration Planning''

Considering team velocity storypoints to be planned. Iteration duration can be 1 to 3 weeks.
Exploration phase
The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.
  • Translate the requirement to tasks: Place on task cards.
  • Combine/Split task: If the programmer cannot estimate the task because it is too small or too big, the programmer will need to combine or split the task.
  • Estimate task: Estimate the time it will take to implement the task.
    Commitment phase
Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.
  • A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
  • Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
  • Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
  • Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.
    Steering phase
The implementation of the tasks is done during the steering phase of the iteration.
  • Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
  • Find a partner: The programmer will implement this task along with another programmer. This is further discussed in the practice of pair programming.
  • Design the task: If needed, the programmers will design the functionality of the task.
  • Implement the task using test-driven development
  • Run functional test: Functional tests are run.

    Test driven development

are automated tests that test the functionality of pieces of the code. Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further conditions under which the code may fail.
Test driven development proceeds by quickly cycling through the following steps, with each step taking minutes at most, preferably much less. Since each user story will usually require one to two days of work, a very large number of such cycles will be necessary per story.
  • Write unit test: The programmers write a minimal test that should fail because the functionality hasn't been fully implemented in the production code.
  • Watch the new test fail: The programmers verify the test does indeed fail. While it may seem like a waste of time, this step is critical because it verifies that your belief about the state of the production code is correct. If the test does not fail, the programmers should determine whether there is a bug in the test code, or that the production code does support the functionality described by the new test.
  • Write code: The programmers write just enough production code so the new test will pass.
  • Run test: The unit tests are executed to verify that the new production code passes the new test, and that no other tests are failing.
  • Refactor: Remove any code smells from both the production and test code.
For a more intense version of the above process, see Uncle Bob's Three Rules of TDD.

Whole team

Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator. All the skills necessary to deliver the software product should be present on the team.