 The most
obvious way to start extreme programming (XP) is with a new project.
Start out collecting user
stories and conducting spike
solutions for things that seem risky. Spend only a few weeks
doing this. Then schedule a release planning meeting. Invite customers,
developers, and managers to create a schedule that everyone agrees on.
Begin your iterative development with an iteration planning
meeting. Now you're started.
Usually
projects come looking for a new methodology like XP only after the
project is in trouble. In this case the best way to start XP is to take
a good long look at your current software methodology and figure out
what is slowing you down. Add XP to this problem first.
For
example, if you find that 25% of the way through your development
process your requirements specification becomes completely
useless,
then get together with your customers and write user stories instead.
If
you are having a chronic problem with changing requirements causing you
to frequently recreate your schedule, then try a simpler and easier
release planning meeting every few iterations. (You will need user
stories first though.) Try an iterative
style of development and the just in time style of
planning of programming tasks.
If
your biggest problem is the number of bugs in production, then try
automated acceptance
tests. Use this test suite for regression and validation
testing.
If
your biggest problem is integration bugs then try automated unit tests. Require
all unit tests to pass (100%) before any new code is released into the
code repository.
If
one or two developers have become bottlenecks because they own the core
classes in
|
the system and must make all the changes, then try collective code ownership.
(You will also need unit tests.) Let everyone make changes to the core
classes whenever they need to.
You
could continue this way until no problems are left. Then just add the
remaining practices as you can. The first practice you add will seem
easy. You are solving a large problem with a little extra effort. The
second might seem easy too. But at some point between having a few XP
rules and all of the XP rules it will take some persistence to make it
work. Your problems will have been solved and your project is under
control. It might seem good to abandon the new methodology and go back
to what is familiar and comfortable, but continuing does pay off in the
end. Your development team will become much more
efficient than you thought possible. At some point you will find that
the XP rules no longer seem like rules at all. There is a synergy
between the rules that is hard to understand until you have been fully
immersed.
This
up hill climb is especially true with pair programming, but the pay off
of this technique is very large. Also, unit tests will take time to
collect, but unit tests are the foundation for many of the other XP
practices so the pay off is very great.
XP
projects are not quiet; there always seems to be someone talking about
problems and solutions. People move about, asking each other questions
and trading partners for programming. People spontaneously meet to
solve tough problems, then disperse again. Encourage this interaction,
provide a meeting area and set up workspaces such that two people can
easily work together. The entire work area should be open space to
encourage team communication. 
|
