Extreme Programming reference page

CS 284 (CSA), Spring 2005

Source: Kent Beck, Extreme programming explained: Embrace change, Addison-Wesley, 2000.

Index

• Rationale
• The four values
• Basic principles
• The four basic activities of a software team
• The XP practices
• The planning game
• Management strategy
• When not to use XP (examples)

Philosophy

Rationale

• The cost of making changes during software development is no longer exponential. With modern software development tools, the curve now flattens throughout the lifetime of the project.

• Therefore, armed with tools, we freely invest in production stages of the software development process, with crucial safeguards such as good communication, constant feedback, and a focus on simplicity, rather than focusing on thorough pre-production planning.

The four values

• Communication

• Simplicity

• Feedback

• Courage (to do things differently than before)

Basic principles

Fundamental principles

• Rapid feedback

• Assume simplicity

• Incremental change

• Embracing change

• Quality work

Less central principles

• Teaching learning (cf. liberal arts)

• Small initial investment

• Expect to win (attitude)

• Concrete experiments

• Open, honest communication

• Work with people's instincts, not against them

• Responsibility accepted, not given

• Local adaptation (of the methodology)

• "Travel light" (be an intellectual nomad)

• Honest measurement (including degree of accuracy)

Methods

The four basic activities of a software team

• Coding

• Testing

• Listening

• Designing

Ordering in Waterfall Model vs. ordering in XP.

The XP practices

• The planning game

• Small releases

• Metaphor

• Simple design

• Testing

• Refactoring

• Pair programming

• Collective ownership

• Continuous integration

• 40-hour week (...)

• On-site customer

• Coding standards

The planning game

Two groups of players: User ("Business") and Development. The goal of the game is to maximize the value of the software produced by the team, deducting the cost of development and risk incurred during development. The strategy is to invest as little as possible to produce the most valuable functionality (as assessed by User) as quickly as possible, while reducing risk. Then, iterate.

User people have to decide the following:

• Scope

• Priority

• Composition of releases (how much is enough)

• Dates of releases

Development (a.k.a., Technical) team must decide the following:

• Estimates (amount of time/effort required to complete a task or story)

• Consequences (e.g., choice of database system)

• Process (i.e., how the tasks will be implemented)

• Detailed scheduling

Moves of the game

• Exploration: write a story; estimate a story; split a story if necessary.

• Commitment phase: User sorts stories by value; Development sorts stories by risk; Development sets velocity; User chooses scope.

• Steering phase:

  • Iteration: User selects one iteration (e.g., 2-3 weeks) worth of the most valuable stories, resulting in an end-to-end system.
  • Recovery: If Development realizes it has overestimated velocity, it can re-estimate and reset velocity, and ask User to determine most valuable stories to retain in current release.
  • New story: If User realizes it needs a new story during an iteration, User can write the story. Development then estimates, User removes equivalent quantity of stories from remainder of this release and inserts the new story.
  • Reestimate: If Development believes current plan is inaccurate map of development, Development can re-estimate remaining stories and reset velocity.

Details

• User sorts stories by value into three categories:

  1. Essential for system functioning;

  2. Significant user value but less essential;

  3. Would be nice.

• Development sorts stories by risk into three categories:

  1. Can estimate the task precisely;

  2. Can estimate the task reasonably well;

  3. Cannot estimate the task.

Management strategy

• Metrics

• Coaching, i.e., calmly and confidently getting everybody to make good decisions, rather than taking responsibility for tasks.

• Tracking

• Intervention, when necessary.

Caveats

When not to use XP (examples)

• Resistant culture.

• Big spec required up front.
• Just don't like the idea...
• Commitment to project measured in overtime hours.
• Project scale too large (unless you can work around the "single integration thread").
• Takes too long to get feedback.
• Costly test the system.
• Physical environment.
• Team too large (e.g., >20) or too small (e.g., one or two).

rab@stolaf.edu, March 14, 2005