Links
|
Extreme Programming reference page
CS 284 (CSA), Spring 2005
Source: Kent Beck, Extreme programming explained: Embrace
change, Addison-Wesley, 2000.
Index
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.
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)
Coding Testing Listening Designing
Ordering in Waterfall Model vs. ordering in XP.
The planning game Small releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week (...) On-site customer Coding standards
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:
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
Metrics Coaching, i.e., calmly and confidently getting everybody to
make good decisions, rather than taking responsibility for tasks. Tracking Intervention, when necessary.
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).
|