Extreme Programming (XP)

Steven J Zeil:

Last modified: Dec 4, 2016

Extreme Programming (Kent Beck, 1999) is an agile approach characterized by

pair programming,
test first
short development cycles (7-10 days) between releases,
sustainable pace
Search for simplest increments with no “big design up front”

1 Values

Communication
Simplicity
“What is the simplest thing that could possibly work?”
Feedback
- Understanding what has changed & what we are getting wrong
- Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.
Courage
- a bias toward action
Respect
- care about the team members
- care about he project

2 Principles

Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
Mutual Benefit: “Every activity should benefit all concerned.”
- e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs
- negative example: extensive internal documentation
Self-similarity
- when you find a pattern (code or work practices) that works, stick with it
Improvement

“In software development, ‘perfect’ is a verb, not an adjective.”
Diversity: skills attitudes, and perspectives
Reflection:
- time is set aside to review how well development is going,
- informal reflection within team is encouraged
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
- critical, difficult problems approached many ways
Failure
- should not be feared
- prototypes and experiments are useless if only employed when we are sure they will succeed
Quality
- Quality is not a control variable. Projects don’t go faster by accepting lower quality."
Baby Steps
- Organizations can add XP practices incrementally
Accepted Responsibility
- “Responsibility cannot be assigned. It can only be accepted.”
  - Whoever signs up to do work also estimates it.
  - The person implementing a story is responsible for design, implementation, and testing.

3 Practices

(Beck, Extreme Programming Explained, Figure 3)

We’ll focus on the primary ones in the upper half of this diagram.

3.1 Teamwork

Whole Team

Team must span the required skill set for the project
People need a sense of belonging, of shared purpose
- Splitting people across projects detracts from these

3.1.1 Sit Together

Open space big enough for whole team
- small spaces nearby for privacy

3.1.2 Informative Workspace

“An interested observer should be able to walk into the team space and get an idea of how the project is going in fifteen seconds.”
- Story & task boards
- “big, visible charts”

3.2 Energized Work

“Work only as many hours as you can be productive”
“and only as many hours as you can sustain”

3.2.1 Pair Programming

Write all production programs with two people sitting at one machine.

Pairs…
- keep each other on task
- clarify ideas
- avoid frustrating “stuck” points
- keep each other accountable for team quality standards
Thinking an be done alone, but not coding
Rotate pairs frequently
- e.g., every hour or so
- Eventually, each invidiual should pair with everyone on the team

3.3 Planning

Stories

Units of planning.

“the word ‘requirement’ is just plain wrong. Out of one thousand pages of ‘requirements’, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not ‘requirements’; they weren’t really mandatory or obligatory.”

Stories lead to earlier estimation than requirements
- Encourages team to think in terms of greatest return from smallest investment.

3.3.1 Weekly cycle

Opening meeting
- Review progress so far
- Have customers pick a week’s worth of stories
- Break stories into tasks.
Start week by writing automated tests for the stories
Rest of week is implementation and debugging
At end of week, software is deployable with new functionality

3.3.2 Quarterly Cycle

At the start of a quarter, reflection and planning
Reflection
Planning
- identify bottlenecks, especially external
  - devise a reaction or workaround
- Pick the “themes” for the quarter
  - Pick a quarter’s worth of stories to meet that theme
  - Include some slack: minor stories that can be dropped if you fall behind

3.4 Integration

Ten-Minute Build

Automated build should build and run tests in tem minutes
Anything longer should be done less frequently.

“A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn’t give you time to drink your coffee.”

3.4.1 Continuous Integration

Integrate and test changes every couple of hours

“Team programming isn’t a divide and conquer problem. It’s a divide, conquer, and integrate problem”
- Asynchronous (sometime after checking of changes)
- Synchronous (on demand by team)
  - provides an opportunity for reflection
Integration should produce the complete product

3.5 Programming

Test-First Programming

Write a failing test before changing any code.
Addresses:
- scope creep: putting in code “just in case”
- coupling and cohesion: If it’s hard to write a test, you have a design problem, not a testing problem.
- Trust: (team building)
- Rhythm

3.5.1 Incremental Design

Create conditions where changes in design do not have exaggerated costs (a la Boehm)
Adapt the design to changes in (or discovery of) requirements