Abstract
Extreme Programming (Kent Beck, 1999) is an agile approach characterized by
In this lesson we will explore these component ideas and how they combine into a cohesive development model.
“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
Courage
Respect
care about the team members
care about he project
Humanity: concern for the team members
Economics: Make sure that what you are doing has value to the customer.
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
Improvement
“In software development, ‘perfect’ is a verb, not an adjective.”
Diversity: skills attitudes, and perspectives
Reflection:
Flow: continuous flow of activities rather than discrete phases
Opportunity (rather than problems)
Redundancy
Failure
Quality
Baby Steps
Organizations can add XP practices incrementally
Accepted Responsibility
(Beck, Extreme Programming Explained, Figure 3)
We’ll focus on the primary ones in the upper half of this diagram.
Whole Team
Team must span the required skill set for the project
People need a sense of belonging, of shared purpose
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
“Work only as many hours as you can be productive”
“and only as many hours as you can sustain”
Write all production programs with two people sitting at one machine.
Pairs…
Thinking an be done alone, but not coding
Rotate pairs frequently
Stories
“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.”
Opening meeting
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,
At the start of a quarter, reflection and planning
Reflection
Planning
Quarterly planning meshes well with traditional business schedules.
“Themes” help refocus team o nthe “big picture”.
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.”
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”
Integration should produce the complete product
Test-First Programming
Addresses:
Create conditions where changes in design do not have exaggerated costs (a la Boehm)
Adapt the design to changes in (or discovery of) requirements