Extreme Programming Concepts

Extreme Programming

Extreme Programming (XP), is a softwaare development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Kent Beck developed XP during his work on the Chrysler Comprehensive Compensation System (C3) payroll project in the late 1990s, however similar programming practices have been used since te 1960s.

eXtreme Programming Diagram

There are 3 main sections of Extreme Programming, these are:

Values
Rules
Practices

Values

There are five main values that provide the information on which XP (Extreme Programming) paradigm is built, allowing the people involved in the project to feel confident in the direction the project is taking and to understand their personal feedback and insight is necessary and welcome as anyone else.

These values are:

Simplicity - Do what is asked but not anymore than what's needed. Small steps are key and failures that pop up are taken care of.
Communication - Everyone is part of the team and we communicate face to face daily. Everyone works together on everything from requirements to coding to testing. Everyone pools their ideas and expertise together to produce a solution to any problems that may arise.
Feedback - Every iteration commitment is taken seriously by delivering working software. The software comes out early so we can fix any problems that may arise and to make any changes needed. We will talk about the project and adapt our processes to it, not the other way around.
Respect - Everyone is a valued team member. Everyone contributes, even if its as simple as enthusiasm. We are not rigid, we are flexible.
Courage - We will tell the truth about progress and estimates. We don't document excuses for failure because failure isn't an option. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Rules

These sets of XP Rules below were originally intended to help to counter the claims that XP fails to support some of the prominent disciplines necessary for modern development.

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
The Project Velocity is measured (meaning how fast is the project progressing)
Move people around if needed
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
All production code is fair programmed
Only one pair integrates code at a time
Integrate often
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 ofte and te score is published

Practices

Created using what were considered the best practices of software development at the time, these 12 XP Best Practices detail the specific procedures that should be followed when implementing a project using XP. Below is just a simplification, and to read more on this, please refer to the sources at the end of the article.

Fine-scale Feedback

Pair Programming - Two people working in tandem together whilst coding.
Planning Game - Frequent meetings usually every 1-2 weeks. There are lots of phases which include release planning and iteration planning
Test-driven Development - Tests are generated for each and every requirement of the project, and only the is code developed that will successfully pass those tests.
Whole team - Customers and Clients use their feedback to help shape the project at all times, as well as the rest of the team.

Continuous Process

Continuous Integration - All developed code across the entire team is merged into one common repository many times a day. This ensures that any issues with integration across the entire project are noticed and dealt with as soon as possible.
Code Refactoring - Improve and re-design the structure of already existing code, without modifiying its fundamental behaviour.
Small Releases - The Project will feature iterated, small releases on a frequent basis, allowing the customer as well as all team members to get a sense of how the project is developing.

Shared Understanding

Coding Standards - Code to Best Practices
Collective Code Ownership - Allow any developer across the team to be able to change any part of the code if needed. This can speed up developmet time.
Simple Design - Don't overcomplicate things
System Metaphor - Everyone on the team should be able to look at the high-level code that is developed, and have a clear understanding of what functionality that code is performing.

Programmer Welfare

Sustainable Pace - Nobody should be required to work in excess of the normal scheduled work week. Overtime is frowned upon, as is the concept of "crunch-time", where developers are expected to work extreme hours near the end of a release to get everything completed on time.

Sources: (click on them to see them)

eXtreme Programming Concepts