Acceptance Tests
Often called customer tests, acceptance tests are automated tests written by the customer to show that a story has been implemented correctly. Acceptance tests should be human readable to help document the expected behavior of the system.
Collective Code Ownership
All the code is collectively owned by all the developers. Anyone can and does change any of the code. The programmers use a coding standard to enforce a common style.
In an XP team, the customer is the person who makes the business decisions. This may be a real customer or someone who represents the users of a system such as a business analyst or a product manager.
Continuous Integration
Code is integrated and checked in several times an hour - every time a test passes and the code is refactored.
Engineering Task
Stories are broken down into engineering tasks during iteration planning. Stories describe what the customer needs. Engineering tasks describe what needs to be done to complete the story.
Extreme Programming
Extreme Programming is an agile approach to software development that stresses customer satisfaction and teamwork. XP delivers clean designs and high quality software on a realistic schedule.
First Iteration
The first iteration is special because the team does not have yesterday's weather to predict the velocity. A rough guess will suffice until the first iteration is complete. Many teams use the first iteration to deliver a primitive end-to-end version of the final system.
XP teams work to the regular milestones that occur at the end of every iteration. An iterations usually lasts two or three weeks and starts with a planning meeting. The customer selects a number of stories for each iteration according to Yesterday's Weather.
Iteration Planning
Each iteration begins with a brief planning meeting where the customer selects the stories and describes them to the team. The developers break each story down into engineering tasks, estimate them and then sign up for the tasks that they will be responsible for.
On Site Customer
The customer should available at all times to answer questions about stories and to direct the acceptance tests.
Pair Programming
All production code is written by two programmers sharing a keyboard and a monitor. The pair divides the responsibilities for strategy, tactics, testing and writing code and switches roles every few minutes or whenever one of them is stuck or has a particular insight.
Planning Game
An XP project starts with the planning game. In the planning game, the customer introduces stories and writes them on index cards. The programmers estimate each story and the customer sorts the cards in order of priority. The customer selects the cards for the first few iterations. The result of the planning game is a release plan. The planning game is repeated every few iterations to incorporate new information and understanding.
Project Velocity
The number of story points that are completed in each iteration.
Release Plan
The release plan is the prioritized collection of stories grouped by iteration that results from the planning game. Once the team has settled into a rhythm and has a steady velocity, the release plan can give the customer insight into when a story will be completed or, conversely, how many stories will be completed by a particular date.
Refactoring means improving the design of existing code. In the context of test driven development, code is refactored to removed duplication and express intent as soon as it is written and passes the tests.
Simple Design
An XP team's design philosophy is to always do the simplest thing that can possibly work. The overall system design evolves through constant refactoring to ensure that the system is always as simple as it can be.
Small Releases
XP teams release working software to their customers as early and as often as possible to maximize the opportunities for feedback. The software could potentially be released at the end of each iteration.
Spike Solution
Spike solutions are used to answer tough design questions, to try out new technologies or to help understand a story for estimation purposes.
Stand Up Meeting
Each day begins with a meeting to communicate what happened the day before and what is expected to happen today. Everyone stands up as a reminder to keep the meeting brief.
The story is the basic unit of work in XP. A story represents a chunk of business value that can be tested, estimated and delivered within an iteration. The headline of each story is written on an index card.
Story Cards
An index card with the headline of a story written on it. A story card represents the promise of a future conversation about the story. XP teams use story cards for planning purposes.
Story Points
Stories are estimated in relative terms. A story that will take a couple of days is designated as a one point story and other stories are estimated as one, two or three points. Customers are asked to combine stories smaller than a point and to split stories bigger than three points.
Sustainable Pace
The team works at the same steady pace through the whole project avoiding the need for massive overtime when the deadline arrives.
System Metaphor
A lightweight substitute for architecture that gives the team a shared vocabulary and vision for the design of the system.
Test Driven Development
On an XP project, all production code is written test-first in a tight cycle of test-code-refactor. TDD results in simple designs that are easy to test.
Unit Tests
Often called programmer tests, unit tests are automated tests written by the programmers to test the functionality of a module of code. Beyond their role in automated testing, unit tests are the foundation of test driven development.
Whole Team
The whole team including the customer works together in a single room to maximize the opportunities for communication.
Yesterday's Weather
The number of story points that are completed in the last iteration is used as the most reliable predictor of how many story points will be completed in the next iteration.