2 min read

Extreme Programming in a Nutshell

Communication, Simplicity, Feedback and Courage are the four core values of extreme programming.
"XP is about delivering to deadline," says James Grenning, a business coach with Object Mentor, as he absentmindedly shuffles a pack of blank index cards. "Every two weeks you release something, and every two weeks you check to see if what you've planned is doable. You get really good at getting stuff done."

The only agile methodology that explicitly describes programming practices, XP has engendered a number of neologisms that have become popular in the wider developer world. Just what do these terms mean? Here's a handy glossary:

On-site customer: Ensures communication by working in the same room as the programmers whenever possible.

User story: A concise description of system behavior from the user's point of view.

Acceptance tests: Early feedback on program function from customer-provided testing criteria.

The Planning Game: Developers discuss implementation, estimation and assignment of user stories.

Unit tests: Automated tests of every class, and anything else that could break, that perpetually run at 100%.

Test-first design: Write a small test, then code to express intention, not algorithm.

Refactoring: A formal process to improve code without breaking it.

Simple design: Code that does what's intended, runs all tests, is not repetitive and is economical with classes and methods.

Pair programming: Production code is generated by two people—a driver and a partner—at one machine.

Spike solution: A small experiment to ascertain the difficulty of implementing a given feature.

Collective ownership: Everyone has the right to fix any object.

Coding standard: An agreed-upon style makes code easily understood by all who own it.

Continuous integration: Daily or more frequent building and testing of the entire system.

Metaphor: An overarching concept to guide object naming and communication about the program's operation.

Forty-hour week: Tired minds make mistakes, so avoid overtime wherever possible.--Alexandra Weber Morales, Software Development Magazine