XP Practices


There are a small set of practices defined by XP. As with any live methodology, the number of practices, and how they are defined, is evolving. Here we present the original set of practices identified by Kent Beck.

  • The Planning Game . A simple, effective way of determining the contents of a release by combining business value and technical estimates. The plan is constantly updated.

  • Small Releases . Based on short iterations that deliver working software to customers.

  • Metaphor . A simple, shared story of how the whole system works.

  • Simple Design . Do the simplest thing that can possibly work. Let the system's complexity evolve only when absolutely necessary.

  • Testing . Programmers write complete unit tests for all their code. Customers write acceptance tests.

  • Refactoring . Programmers continually refactor the code to make it simpler, clearer, and more flexible.

  • Pair Programming . Two programmers actively develop and test production code at a single machine. This promotes instant review and feedback, and decreases the likelihood of defects.

  • Collective Ownership . Anyone has the right, and everyone has the responsibility, to change any code in the system when they need to.

  • Continuous Integration . Integrate and build the system as often as possible, usually several times a day. Some projects have developed ways for their configuration management tools to perform the integration builds, continuously, whenever new code is checked in.

  • 40- hour Week . Overtime is rare and not allowed for two weeks in a row under any circumstances. [2]

    [2] This practice is usually stated today as "sustainable pace," since most people have trouble believing that anyone in the software industry actually works only 40 hours a week.

  • On-site Customer . A real customer is a member of the team and is always available to help define requirements, develop acceptance tests, and answer questions from the developers.

  • Coding Standards . The programmers adopt a set of rules for emphasizing communication throughout their code.

If you consider the XP practices and how they might apply to your project, you can see how the practices are designed to support each other. This key strength of XP requires significantly more discipline than you might first realize.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net