Extreme Programming (XP)
Steven J Zeil:
Abstract
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”
In this lesson we will explore these component ideas and how they combine into a cohesive development model.
1 Values
- Communication
- Simplicity
“What is the simplest thing that could possibly work?”
Beck notes that many people don’t hear the 2nd half of the question and respond “We can’t possibly make this system simple because…” If it really won’t work, it won’t work. But that’s not the point. There still is a simplest thing that will work.
“bias your thinking toward eliminating wasted complexity”
-
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.
- “Responsibility cannot be assigned. It can only be accepted.”
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
Team size (Gladwell):
-
12 is the max number of people that can interact with each other in a day
-
150 is the limit to recognizing the faces of everyone on the team
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
Why a week? Beck suggests that it is a natural unit for teams to work in. Everyone focuses on Friday. It is easy to tell if you have fallen behind and need to re-allocate tasks or stories so that you will have something deployable,
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
- identify bottlenecks, especially external
Quarterly planning meshes well with traditional business schedules.
“Themes” help refocus team o nthe “big picture”.
3.4 Integration
Ten-Minute Build
-
Automated build should build and run tests in ten 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