Extreme Programming - ilya-khadykin/notes-outdated GitHub Wiki
Extreme Programming (XP) is a newcomer to the software development methodology world. Considered by many to be “the way programmers really want to work”, XP emerged in the late 90’s and has been adopted by companies ranging from the two-person garage shop to the Ford Motor Company. The thrust of XP is that the customer gets what he wants, when he wants it, even when the spec changes late in the game.
Principles of Extreme Programming
XP is based on a set of proven practices that are all designed to work together, although many folks do pick and choose, and adopt only a portion of XP’s rules. These practices include things like:
- Make small, but frequent, releases.
- Develop in iteration cycles.
- Don’t put in anything that’s not in the spec (no matter how tempted you are to put in functionality “for the future”).
- Write the test code first.
- No killer schedules; work regular hours.
- Refactor (improve the code) whenever and wherever you notice the opportunity.
- Don’t release anything until it passes all the tests.
- Set realistic schedules, based around small releases.
- Keep it simple.
- Program in pairs, and move people around so that everybody knows pretty much everything about the code.