Extreme Programming Glossary
Filed Under Terms | Posted on December 27, 2007
Extreme Programming has a glossary of its own. Some of the terms used in it may not be familiar to people used to other development processes, so here is a list of some of the terms used.
Extreme Programming: Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development “best practices” to their logical extremes — turning them all up to “10″.
Yagni: “You aren’t gonna need it,” a general refrain when someone suggests building functionality for the system that isn’t required by any current user story.
DTSTTCPW: Do the simplest thing that could possibly work. In general, XP says don’t overdesign your system
OAOO: Once and only once is just shorthand for the first two items in the XP definition of “simplest”.
(1) says you need to say everything that needs to be said once.
(2) says you need to say it only once, avoiding duplication.
Test-Driven Development: TDD is a computer programming technique involving writing test cases first; then, implementing just the code needed to pass the test. Test-driven development gives rapid feedback as part of an Extreme Programming methodology.
Egoless programming or collective code ownership: Everything is coded to a single set of standards, and anyone on the project is expected to take ownership of anything, at any time.
Metaphor: All members on an XP team use common names and descriptions to guide development and communicate on common terms.
Refactoring: XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.
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.
Acceptance Test: A test written by the customer, (or QC on the customer’s behalf) that tests the entire system to ensure that a specific piece of functionality is present and functions correctly.
DRY: Don’t Repeat Yourself
Gang Of Four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Authors of the classic book “Design Patterns”.
Green Book: Planning Extreme Programming by Kent Beck and Martin Fowler.
Spike: A quick (typically minutes or hours) exploration by coding of an area the development team lacks confidence in. The spike is concluded when you learn what you needed to learn. So-called because a spike is “end to end, but very thin”, like driving a spike all the way through a log.
Customer: 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: The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.
40-Hour Week: The XP team does not work excessive overtime to ensure that the team remains well-rested, alert and effective.
Iteration: 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.
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.
Sustainable Pace: The team works at the same steady pace through the whole project avoiding the need for massive overtime when the deadline arrives.
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.
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: 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.
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.
Leave a Reply
