| XP is best summed up by its set of values and practices: Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. (Ron Jeffries, "What is Extreme Programming?") The four values at the core of XP are communication, simplicity, feedback, and courage. These come from a realization by Kent Beck that much of what has plagued software development can be traced to failures in one of these four areas and, consequently, that improvements in these areas would lead to a significantly better development process. The four values lead to a set of 12 practices, which essentially form the rules of XP. It is worth noting that this fairly short list of things to remember is just about right to fit into the short-term memory of a pair of programmers, thus enabling XP practitioners to be so disciplined in following the rules. They can actually keep them in mind instead of having to check a 500-page manual! Here's a description of the 12 practices, which we've grouped under the values from which they're primarily derived. This is mostly as an aid to memory, because several practices are driven by more than one of the values: Communication Onsite customer. The development team has continuous access to the customer or customer team, who actually functions as part of the project team. The customer describes the system functionality in user stories, negotiates the timing and scheduling of releases, and makes all decisions that affect business goals. He's always available to answer questions regarding the details of user stories during programming tasks. He helps with functional testing and makes the final decisions on whether to allow the system to continue into production or stop it. Pair programming. Teams of two programmers working together write all the production code. This means at least two people are always intimately familiar with every part of the system, and every line of code is reviewed as it's written. Coding standards. Everyone codes to the same set of standards, to keep the code consistent and devoid of idiosyncratic quirks that could complicate understanding and refactoring by the entire team. Simplicity Metaphor. Each project has an organizing metaphor from which the names of programming entities (e.g., classes and methods) are drawn, providing a simple way to remember the naming conventions. Simple design. XP developers always do the simplest thing that could possibly work. They never solve a more general problem than the specific problem at hand, and they never add functionality sooner than needed. Refactoring. Duplication and needless complexity are removed from the code during each coding session, even when this requires modifying components that are already "complete." Automated unit tests are used to verify every change. Feedback Testing. Unit tests are at the heart of XP. Every piece of code has a set of automated unit tests, which are released into the code repository along with the code. The programmers write the unit tests before they write the code, then add unit tests whenever one is found to be missing. No modification or refactoring of code is complete until 100% of the unit tests have run successfully. Acceptance tests validate larger blocks of system functionality, such as user stories. When all the acceptance tests pass for a given user story, that story is considered complete. Continuous integration. Additions and modifications to the code are integrated into the system on at least a daily basis, and the unit tests must run 100% successfully, both before and after each integration. Small releases. The smallest useful feature set is identified for the first release, and releases are performed as early and often as possible, with a few new features added each time. Courage Planning game. The customers and developers cooperate in planning the order and timing of the features in system releases. The customer provides system specifications in the form of user stories, and developers provide the estimates of the time and effort required for each. The customer then makes the decision on which stories to implement and in what order. The developers and customer jointly negotiate a sequence of short iterations, each implementing a new set of stories, culminating in the final release, containing all the stories. Collective code ownership. No one person owns the modules. All programmers are expected to be able to work on any part of the system at any time and to refactor any part of the system as necessary, to remove duplication. Sustainable pace. Everyone works at a pace that can be sustained for the long term without sacrificing his or her sanity, health, family, or productivity. Occasional bouts of overtime may occur, but consecutive weeks of overtime are considered a sign that something is very wrong. |
