| 
Roles 
Practices 
Core Practices Practice | Description |
|---|
Whole team, or Onsite customers | The whole team programmers and customers work together in a common project room. One or more customers sit more-or-less full time with the team; they are expected to be subject matter experts and empowered to make decisions regarding requirements and their priority. The customer contribution includes detailed explanation to the programmers of the features briefly summarized on story cards, Planning Game participation, clarification, and writing acceptance tests in collaboration with a programmer. The purpose is in response to the consistent project failure research indicating that more customer involvement is paramount to successful projects. The first release of XP spoke of only one onsite customer; this has been recently revised to emphasize a group of customers. | Small, frequent releases | Evolutionary delivery. Not applicable to all projects. Not to be confused with organizing one release cycle into many short iterations. | Testing: Acceptance testing & Customer tests | Testing practices in XP are very important. All features must have automated acceptance (functional) tests. All tests (acceptance and unit) must run with a binary pass/fail result, so that no human inspection of individual test results is required. The acceptance tests are written with collaboration of the customer they define a testable statement of what acceptance means. This is called Customer Tests in XP. | Testing: Test-driven development and unit testing | Unit tests are written for most code, and the practice of test-driven development (and test-first development) is followed. This includes the practice that the unit test is written by the programmer before the code to be tested. It is a cycle of test Õ code, rather than code Õ test. Usually, the open-source XUnit testing framework family (such as JUnit) is applied (see www.junit.org). All acceptance and unit tests are automatically run repeatedly in a 24/7 continuous integration build and test cycle. See p. 292 for a detailed example. | Release planning game | The Release Planning Game goal is to define the scope of the next operational release, with maximum value (to the customer) software. Typically a half-day one-day session, customer(s) write story cards to describe features, and developers estimate them. There may also exist story cards from prior exploration phase work. The customer then chooses what's in the next release by either 1) setting a date and adding cards until the estimate total matches the time available, or 2) choosing the cards and calculating the release date based on their estimates. | Iteration planning game | The Iteration Planning Game goal is to choose the stories to implement, and plan and allocate tasks for the iteration. It happens shortly before each new iteration (1 3 weeks in length). Customer(s) choose the story cards for the iteration. For each, programmers create a task list (on cards or whiteboard) that fulfill the stories. This is followed by a volunteering step in which the programmers choose a set of tasks. They then estimate their task lengths. If tasks are not estimated in the half-day to two-day range, they are refactored. | Simple design | Avoid speculative design for possible future changes. Avoid creating generalized components that are not immediately required. The design should avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible. | Pair programming | All production code is created by two programmers at one computer; they rotate using the input devices periodically. Pairs may change frequently, for different tasks. The observer is doing a real-time code review, and perhaps thinking more broadly than the typist, considering tests and so forth. Certainly, team productivity is not simply a function of the number of hands typing it is more nuanced. The XP claim is that the combination of cross learning, the peer pressure of more disciplined practice observance and more hours actually programming than procrastinating, defect reduction due to real-time code review, and the stamina and insight to carry on when one programmer is stuck, all add up to an overall team improvement. | Frequent refactoring | Refactoring in the XP context is the continual effort to simplify the fine-grained code and larger design elements, while still ensuring all tests pass. That is, cleaning the code and design, without changing functionality. There is supposed to be "lots" of refactoring in XP. This practice is also known as continuous design improvement. The goal is minimal, simple, comprehensible code. It is achieved by small change steps, verifying tests after each, and ideally the use of refactoring tools, now available in some IDEs. | Team code ownership | Any pair of programmers can improve any code, and the XP value system is that the entire team is collectively responsible for all the code. The value of "it's her code, and her problem" is not endorsed; rather, if a problem or chance to improve is spotted, it's the spotter's responsibility. A related goal is faster development by removing the bottleneck associated with change requests in an individual code ownership model. The obvious danger of modifying code one did not originally write is ameliorated in XP by some of the other practices: The guaranteed-present unit and acceptance tests running within an automated continuous integration build process inform you if you broke the code, your pairing partner brings another set of eyes to the change, and common adherence to coding standards ensures all the code looks the same. | Continuous integration | All checked-in code is continuously re-integrated and tested on a separate build machine, in an automated 24/7 process loop of compiling, running all unit tests and all or most acceptance tests. There are several open-source tools for this, built on the ubiquitous Ant technology, including CruiseControl and Anthill. | Sustainable pace | Frequent overtime is rightly considered a symptom of deeper problems, and doesn't lead to happy, creative developers, healthy families, or quality, maintainable code. XP doesn't support it rather, it promotes "no overtime." | Coding standards | With collective code ownership, frequent refactoring, and regular swapping of pair programming partners, everyone needs to follow the same coding style. | System metaphors | To aid design communication, capture the overall system or each subsystem with memorable metaphors to describe the key architectural themes. For example, the C3 payroll system was described in terms of an assembly line of checks with posting rule "machines" operating on them, extracting money from different "bins." Many have reported this the least necessary practice. |
Workproducts Story Cards Figure 8.3 shows a simple story card: A handwritten note on a paper index card. During the Planning Game, many of these are written. This spartan example was chosen to emphasize the minimalist approach to recorded requirements that XP encourages.[2] [2] In fact, when XP expert Ron Jeffries reviewed this chapter, he felt even the number "3" on this real-example card was excessive.
Figure 8.3. sample story card 
The story cards record user stories: features, fixes, or nonfunctional requirements that the user wants. There can even be a story card to create documentation. Stories are usually in the one-day to three-week range of estimated duration. Contrary to some misunderstanding, XP stories are not use cases or scenarios. They usually represent features. Note that XP prefers a feature-driven approach to describing requirements rather than the use-case-driven approach that UP promotes. In XP, oral communication is preferred, and the story card purpose is not to detail the user story, but to jot a summary, make references to other documents, and in general, to view the card as "a promise to talk" (in Alistair Cockburn's words) with the customer who wrote it, by the developers implementing it. Since whole team together is an XP practice, the card donor should be readily available. XP coaches vary on their advice regarding granularity for estimation. Some say stories can be in the two-day to two-week range of effort, others recommend stories be estimated in units of one, two, or three weeks, but not in finer person-day units. Task List During an Iteration Planning Game, the team convenes around a whiteboard, and generates a list of tasks for all the stories chosen for the iteration. Another popular alternative is to generate individual task cards. Once a task is chosen by a volunteer, they enter an effort estimate (in ideal engineering hours) tasks should be in the 1 2 day range. Visible Graphs The idea is to easily communicate to the team something they find useful to measure. Measure at least one thing. XP doesn't mandate what that should be, though known examples include acceptance tests defined and passing, story progress, and task progress. Other Practices and Values Onsite customer proxies Many groups wishing to apply XP cannot find full-time "ultimate" customers to work in the project room. For example, consider a new internal system for (very busy) commodity traders. And this problem is common for commercial products for an external market. The common solution is to designate customer proxies that do join the team in the project room, have good (though not as ideal as true customer) knowledge of the domain and requirements, and that represent the ultimate customers. If proxies are used, it is important that the true customers at least participate in end-of-iteration demos, and preferably, in the Planning Games. Customer on call When the onsite customer is not present, arrange matters so that the customer representative is committed to fast access, such as via a mobile phone. Embrace change The overarching attitude that XP promotes is to embrace rather than fight change, in the requirements, design, and code, and be able to move quickly in response to change. Only by volunteering (accepted responsibility) Tasks are not assigned to people. Rather, during the Iteration Planning Game, people choose or volunteer for tasks. This leads to a higher degree of commitment and satisfaction in the self-accepted responsibility, as has been explored in [DL99]. Very light modeling XP encourages programming very early and does take to "extreme" the avoidance of up-front design work. Any more than 10 or 20 minutes of design thinking (e.g., at the whiteboard with sketches or notes) before programming is considered excessive. Contrast this with Scrum or the UP, for example, where a half-day of design thought near the start of an iteration is acceptable. Minimal or "just enough" documentation With the goal of getting to code fast, XP discourages writing unnecessary requirements, design, or management documents. The use of small paper index cards is preferred for jotting brief descriptions, as are verbal communication and elaboration. Note that the practice of "avoiding documentation" is compensated by the presence of an onsite customer. XP is not anti-documentation, but notes it has a cost, perhaps better spent on programming. Metrics XP recommends daily measurement of progress and quality. It doesn't mandate the exact metrics, but to "use the simplest ones that could work." Examples include numbers of completed tasks and stories, and number and success rate of running tests. Visible wall graphs The collected metrics are daily updated on wall graphs for all to easily see. Tracking and Daily Tracker The regular collection of task and story progress metrics is the responsibility of a tracker. This is done with a walk-about to all the programmers, rather than email; commenting on this and very telling of the XP attitude Ron Jeffries (one of the XP founders) said, "XP is about people, not computers." Test metrics can be automatically collected by software. Incremental infrastructure XP recommends (as do the other iterative processes) that the back-end infrastructure (for example, a persistence layer) not be the main focus of implementation in the early iterations, but rather, only enough is implemented to satisfy the user-functional requirements of each iteration. Common project room XP projects are run in a common project room rather than separate offices. Pair programming tables are in the center of the room, and the walls are clear for whiteboard and poster work. Of course, people may have a private space for private time, but production software development is a team sport in XP. Daily stand-up meeting As in Scrum, there is a daily short stand-up (to keep it short) meeting of status. Ideal engineering hours (IEH) Task estimates and possibly story estimates are done in terms of IEH, or uninterrupted, dedicated, focused time to complete a task. Story estimates To estimate larger stories, some XP practitioners recommend using only coarse values of one, two, or three week durations rather than IEH or day-level estimates.
|
