|
Continued from page 1
 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 can be open space to encourage team communication. |
