 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 10. 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.  |
