Extreme Programming

Extreme Programming (XP) is one of several popular Agile processes, developed and then codified by Kent Beck in Extreme Programming Explained (1999). It got its name from the fact that the methodology takes "best practices" like test-first development from NASA's Project Mercury in the 1960s to extreme levels.

Two major influences shaped software development in the 1990s, which XP tried to address:

• Internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some developers.
• Externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company growth as competitive business factors.

Rapidly changing requirements demanded shorter product life-cycles, and often clashed with traditional methods of software development.

XP Values

• Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.
• Conversation: Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.
• Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
• Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.
• Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

XP Rules

Planning

• User stories are written.
• Release planning creates the release schedule.
• Make frequent small releases.
• The project is divided into iterations.
• Iteration planning starts each iteration.

Managing

• Give the team a dedicated open work space.
• Set a sustainable pace.
• A stand up meeting starts each day.
• The Project Velocity is measured.
• Move people around.
• Fix XP when it breaks.

Designing

• Simplicity.
• Choose a system metaphor.
• Use CRC cards for design sessions.
• Create spike solutions to reduce risk.
• No functionality is added early.
• Refactor whenever and wherever possible.

Coding

• The customer is always available.
• Code must be written to agreed standards.
• Code the unit test first (Test Driven Development).
• All production code is pair programmed.
• Only one pair integrates code at a time.
• Integrate often (continuous integration).
• Set up a dedicated integration computer.
• Use collective ownership.

Testing

• All code must have unit tests.
• All code must pass all unit tests before it can be released.
• When a bug is found, tests are created.
• Acceptance tests are run often and the score is published.