Extreme Programming Overview
Why XP
The cost of fixing things increases profoundly the longer we wait.
Stretching out design just makes the errors cost more, whether found
inside design, or in a later phase.
The right lesson is to find out right away whether we've made a
mistake. The best way to do that is to take an idea through analysis,
design, code, and test in the shortest possible time. -- Ron Jeffries
The following graph (from Boehm's famour book, Software Engineering Economics) shows that
the cost of change increases exponentially with time with the waterfall model.
Therefore, it becomes important to keep changes to a mimimum once an application is in production.
Kent Beck's idea is that the cost of change can be flattened by making software more malleable.
Rather than following the waterfall method, one goes through short iterations. A variety of
practices allow the application to be modified more easily over time. Thus Extreme Programming
emphasizes less design up-front, whereas waterfall pushes all of the design to the beginning
of a project.
XP Equation
XP contends that every project balances 4 principal variables:
Time, Cost, Scope, and Quality. XP fixes the time, cost, and quality. Therefore
only scope can be varied during the project.
XP Values
- Communication
- Feedback
- Implement the Simplest Solution
- You Aren't Going to Need It
- Once And Only Once: Avoid Repetition
- Courage
- Sufficient Time
- Sufficient Resources
- Constant cost of change
- Developer Effectiveness
- Freedom to experiment
XP Practices Complement One Another
Technical/Programming |
Test-Driven Development |
Frequent/Ongoing Refactoring |
Continuous Integration |
Paired Programming |
|
Design/Architecture |
System Metaphor |
Simple Design |
Coding Standards |
Collective Code Ownership |
|
Project Management |
Planning Game |
Customer Rep On Team |
Frequent Releases |
Sustainable Pace |
Acceptance Tests |
|
XP Process
Iteration Planning
Each iteration consists of stories.The business decides which stories
to implement.The developers estimate how long each story will take to
complete. Stories should be broken such that they have a clear beginning
and end. Also, stories should be small enough so that at least five
8-10 can be completed per month.
Story and Task Cards
Story cards represent features and are defined primarily by the business.
However, Q&A and the development team itself may also assign story cards in
some instances. All stories must ultimately be approved by the business.
Stories can be split and modified as needed. Task cards represent tasks
that need to be performed to accomplish each story.
Velocity
Developer estimates are measures in "ideal hours." In other words, the
number of hours it would take to complete a task without interruptions
or major problems. Velocity represents the ratio of ideal hours to
the actual time it takes to complete a task. For example, if
40 hours worth of ideal time stories are placed into the first
iteration, and only 20 hours of stories are actually completed, then
the velocity is 0.5. For the next iteration, only 20 hours worth of
ideal time tasks should be taken on. The goal is to know what is possible
and therefore to do the highest priority tasks that can fit into an
iteration.
Stand-up Meeting
During an iteration, there is a brief daily meeting. Team members
state what they did yesterday, what they plans to do today, and
bring up any obstacles that may be in their way.
Bullpen Environment
XP Advocates an open environment to make paired programming and interaction with the
customer representative easier.
XP Roles
Customer
The customer drives the project. He/she sets goals and prioritizes features.
Business decisions are the customer's job.
Developer
The development is responsible for technical planning (architecture, design)
and for providing a solution that satisfies the customer.
Tracker
The tracker keeps track of the schedule. The tracker's job is to maintain valuable
project statistics and to make sure the project is meeting its objectives.
Coach
The coach is basically a mentor who helps guide the team. The coach is the most
experienced practictioner of XP and can help resolve ambiguities as well as
technical challenges.
Rights and Responsibilities
Customer Rights
- Chooses stories for each iteration
- Can add or remove stories from iteration
- Determine which features to implement next
- Measure the progress of the project at any time
(acceptance tests)
- Stop the project at any time without losing investment
Customer Responsibilities
- Trust the developers' technical decisions
- Analyze risk correctly
- Choose the stories with maximum value
- Provide precise stories
- Work within the team
Developer Rights
- To estimate their own work
- Work a sensible and predictable schedule
- To produce code that meets the customers' needs
- Avoid the need to make busines decisions
Developer Responsibilities
- Follow the team's guidelines
- Implement only what is necessary
- Communicate constantly with the customer