|
 Extreme
Programming (XP) was created in response to problem domains whose
requirements change. Your customers may not have a firm idea of what
the system should do. You may have a system whose functionality is
expected to change every few months. In many software environments
dynamically changing requirements is the only constant. This is when XP
will succeed while other methodologies do not.
XP
was also set up to address the problems of project risk. If your
customers need a new system by a specific date the risk is high. If
that system is a new challenge for your software group the risk is even
greater. If that system is a new challenge to the entire software
industry the risk is greater even still. The XP practices are set up to
mitigate the risk and increase the likelihood of success.
XP
is set up for small groups of programmers. Between 2 and 12, though
larger projects of 30 have reported success. Your programmers can be
ordinary, you don't need programmers with a Ph.D. to use XP. But you
can not use XP on a project with a huge staff. We should note that on
projects with dynamic requirements or high risk you may find that a
small team of XP programmers will be more effective than a large team
anyway.
|
XP requires
an extended development team. The XP team includes not only the
developers, but the managers and customers as well, all working
together elbow to elbow. Asking questions, negotiating scope and
schedules, and creating functional tests require more than just the
developers be involved in producing the software.
Another
requirement is testability. You must be able to create automated unit
and functional tests. While some domains will be disqualified by this
requirement, you may be surprised how many are not. You do need to
apply a little testing ingenuity in some domains. You may need to
change your system design to be easier to test. Just remember, where
there is a will there is a way to test.
The
last thing on the list is productivity. XP projects unanimously report
greater programmer productivity when compared to other projects within
the same corporate environment. But this was never a goal of the XP
methodology. The real goal has always been to deliver the software that
is needed when it is needed. If this is what is important to your
project it may be time to try
XP. 
|
