Extreme Programming (XP)

December 7, 2009

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. The methodology takes best practices to extreme levels. Extreme Programming was created by Kent Beck in 1996 to refine the project that he is working on (in Chrysler).Although Extreme Programming itself is relatively new, many of its practices have been around for some time. For example, the “practice of test-first development, planning and writing tests before each micro-increment” was used as early as NASA’s Project Mercury, in the early 1960s. Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984. (1)

As a type of agile software development, it advocates frequent “releases” in short development cycles (time boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

One of the main features of Extreme programming is pair programming. Pair programming is a software development technique in which two programmers work together at one work station. One types in code, called the driver, and the other reviews each line of code as it is typed in, called observer or navigator. The two programmers switch roles frequently, possible every 30 minutes or less.

Extreme Programming is based on 5 values.

Simplicity: Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The focus is on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the “you’re not gonna need it” approach.
Communication: Constantly communicate with customers and fellow teammates. The goal is to give all developers a shared view of the system which matches the view held by the users of the system.
Feedback:
o Feedback from the system: by writing unit tests.
o Feedback from the customer: The acceptance tests by the customer and the testers.
o Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Developers respect the expertise of the customers and vice versa. Management respects developer’s right to accept responsibility and receive authority over their own work.
• Courage: Courageously respond to changing requirements and technology. Courage enables developers to feel comfortable with refactoring their code when necessary. Another example of courage is, knowing when to throw code away. Also, courage means persistence.

Rules of Extreme Programming: (2)
Planning:
o User stories are written.
o Release planning creates the release schedule.
o Make frequent small releases.
o The project is divided into iterations.
o Iteration planning starts each iteration.
Managing:
o Give the team a dedicated open work space.
o Set a sustainable pace.
o A stand up meeting starts each day.
o The project velocity is measured.
o Move people around.
o Fix XP when it breaks.
Designing:
o Simplicity.
o Choose a system metaphor.
o Use CRC (Class, Responsibility and Collaboration) cards for design sessions.
o Create spike solutions to reduce risk.
o Refactor whenever and wherever possible.
Coding:
o The customer is always available.
o Code must be written to agreed standards.
o Code the unit test first.
o All production code is pair programmed.
o Integrate often.
o Use collective ownership.
Testing:
o All code must have unit tests.
o All code must pass all unit tests before it can be released.
o When a bug is found, tests are created.
o Acceptance tests are run often and the scores are published.

Extreme Programming is successful because it stresses customer satisfaction and empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme Programming created quite a buzz in 1990s and early 2000. The practices in XP were largely debated with strong opinions for and against using XP. But XP is still evolving, assimilating more lessons from experience in the field.

By: Subbu

References:
1. http://en.wikipedia.org/wiki/Extreme_Programming
2. http://www.extremeprogramming.org/

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.