|
Definition
Extreme Programming (XP)
is actually a deliberate and disciplined approach to software development. About
six years old, it has already been proven at many companies of all different sizes
and industries worldwide. XP is successful because it stresses customer satisfaction.
The methodology is designed to deliver the software your customer needs when it
is needed. XP empowers software developers to confidently respond to changing
customer requirements, even late in the life cycle. This methodology also emphasizes
teamwork. Managers, customers, and developers are all part of a team dedicated
to delivering quality software. XP implements a simple, yet effective way to enable
groupware style development. XP improves
a software project in four essential ways; communication, simplicity feedback,
and courage. XP programmers communicate with their customers and fellow programmers.
They keep their design simple and clean. They get feedback by testing their software
starting on day one. They deliver the system to the customers as early as possible
and implement changes as suggested. With this foundation XP programmers are able
to courageously respond to changing requirements and technology. XP is different.
It is a lot like a jig saw puzzle. There are many small pieces. Individually the
pieces make no sense, but when combined together a complete picture can be seen.
This is a significant departure from traditional software development methods
and ushers in a change in the way we program.
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, and 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. 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.
<<back |