Extreme Programming (XP) Development Methodology 1


xp practices

Extreme Programming – Complete List of XP Practices

Extreme Programming (XP) Development Methodology is intended to improve software quality and responsiveness to changing customer requirements. Extreme Programming (XP) Development Methodology has frequent “releases” in short development cycles which is intended to improve productivity and introduce checkpoints so new customer requirements can be adopted. XP uses users stories but associates acceptance tests with them that need to be passed for the story to be considered done. The acceptance tests are usually automated but can also be a series of repeatable steps. The programmer is also expected to write tests for individual tasks contributing to a story. XP purposes write tests first and code second. Each piece of code should have an associated test or should not be integrated.

“XP is  a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements”

Kent Beck 

Practices for Extreme Programming (XP) Development Methodology include Pair Programming, Extensive Code Review, Unit Testing, Flat Management Structure. Best way to describe Extreme Programming (XP) Development Methodology would be lightweight, discipline, humanistic and software development.

Extreme Programming (xp practices) Development Methodology

Extreme Programming (XP) Development Methodology History

There is very little companies who have adapted strict XP but there a lot of adoptions using some of the XP practices.

1996 The Creation of XP

Kint Beck while he was working on the Chrysler Comprehensive Compensation System. Kint took practices like unit testing from other methodologies such as Test Driven Development to define how the team worked.

1999 Extreme Programming Explained

While living in Switzerland Kint wrote the “Extreme Programming Explained” based on his experience in Chrysler.

2001 Agile Manifesto

Kint BeckOne of 17 agile practitioners that signed Agile Manifesto.  The Agile manifesto can be found here.

2005 Second Edition

New version wasn’t programmer specific but took into consideration other stakeholders.

2011 Facebook

Kint now works in Facebook where he is a Agile coach where he coaches programmers.

 

Extreme Programming (XP Practices) Development Methodology FrameworkExtreme Programming xp practices Development Methodology

The 5 principles behind Extreme Programming (XP) Development Methodology are:

  1. Simplicity – Only do what is needed and asked for.
  2. Communication – Everyone is part of the team and communicate daily
  3. Feedback – Demonstrate software early and often and listen to any feedback
  4. Courage – Tell the truth about progress and estimates
  5. Respect – Everyone contributes  value even if it is just enthusiasm

As other Agile development methodologies; XP puts emphasise on delivering quickly and early to gather feedback.

Extreme Programming (XP) Development Methodology Roles

Customer/Business/Product Owner

The customer is the actual business or some people might know this person as the product owner. They may or not be the actual end user but represents them.

Responsibilities Include:

  • Writing user stories
  • Sets priorities
  • Provide insights into stories for programmers

XP Programmer

The programmer is the person who actual does the work during the increment.

Responsibilities Include:

  • Estimate stories
  • Define tasks from stories
  • Implement stories and unit tests

XP Coach

The coach is responsible for overseeing the work ensuring the project stays on track.

Responsibilities Include:

  • Improving process
  • Training team members

XP Tester

The tester tests codes functionality ensuring it meets the test criteria.

Responsibilities Include:

  • Implements and runs functional tests (Not unit tests)
  • Graphs results

XP Tracker

The tracker purpose is to ensure everything is going to plan and if not the rectify it.

Responsibilities Include:

  • Monitors programmers focus
  • Setup meeting with customer and programmer when required

XP Manager

The manager reports to the Gold Owner and is responsible for ensuring the project is delivered.

Responsibilities Include:

  • Schedule meetings for iteration/release planning
  • Could cover Tracker and Doomsday responsibilities

Doomsayer

This is the person that ensures that everyone is aware of the risks. They also ensure bad results are not ignored. The Manager can also fulfil this role depending on organization.

Gold Owner

This is the person who pays for the project the sponsor in Scrum terms.

 

Extreme Programming – XP Practices/Ceremonies

The 12 XP practices are as follows:

#1 Planning Games: Quickly determine scope of next iteration by taking into consideration business priorities and estimates.

#2 Small Releases: Deliver quickly and early by have short iterations, first create a minimum marketable feature and release new versions based on feedback.

#3 Metaphors: Guide development using simple shared story to eliminate technical talk.

#4 Simple Design: Just-enough-design policy ie. exact specifications just for that story. Extra complexity removed once discovered.

#5 Testing: Develop test cases first, then code to test cases, then automate test cases.

#6 Pair Programming: 2 developers working on 1 story where 1 drives and the other 1 navigates where they would continuously switch roles.

#7 Re-factoring: Restructure complex/poor structured code without effecting behaviour, aims to remove duplication, simplify or add flexibility.

#8 Collective Code Ownership: Anyone works on any code to avoid knowledge silos which results in high quality code.

#9 Continuous Integration: Automated builds and tests so the system checked every time a task is completed.

#10 40-hour Work Week: No overtime to enable long term productivity and predictable results.

#11 On-Site Customer/Whole Team: Have a product owner/business/real life user on the team to answer questionss is a member of the team

#12 Coding Standards: Strict adhere to code standards with rules that emphasize communication through code.

Extreme Programming (XP) Development Methodology Artifacts

User Story

User stories are how the business/product owner write out requirements for a product. A user story is written in the viewpoint of the end user and follows the following format…

As a <role>, I want <feature> so that <reason>

Examples…

As a user, I want to download videos so that I can store videos on my .

As an systems administrator, I want to monitor photos uploaded so that I can confirm they are appropriate.

Acceptance Tests

An acceptance tests is a test to determine if a user story has been completed correctly. It is expected to have at least one acceptance test per user story. Acceptance tests usually have a binary result, pass or fail. The acceptance tests would be automated but may be simply be a series of repeatable steps.

Release Planning

Release planning is the process of determining when features will be released in respect to value and risk. The customer would define a business value to each user story. Programmers would then estimate the user stories of 1, 2 or 3, stories larger than 3 must be spilt into smaller stories. Customer determines which stories are added to which release based on them fitting into an iteration. The first iteration defines the basic skeleton of the application and infrastructure. Release dates are fixed and stories are to fit into these release dates.

Iteration Planning

Stories assigned to an iteration are then broken down into tasks by the programmers. The tasks are then estimated by all programmers as a group. Programmers then “sign-up” for tasks but are only allowed to “sign-up” to the same amount of story points they completed in last iteration.

Programmer Tests

XP uses test first mentality where the programmer writes the test first and then the code. The tests are used to determine what code needs to be written, no code goes into production unless it has an associated test. This is done to encourage COURAGE for re-factoring. There are testing frameworks such as JUNIT for Java, CPPUnit for C++, NUnit for all .Net languages to assit in writing tests for coding.

“Never write a line of code without a failing test”

Ken Beck

Burndown Charts

The burn down chart is a quick way of determining if a sprint is going to plan or not. The diagonal line running from top to bottom represents ideal burn down and is compared to the jotted lines of actual work done. The burn down chart is widely used by teams following the Scrum development methodology.

XP development methodology Burndown Chart

More Information on Extreme Programming & XP Practices

For a quick overview of Extreme Programming (XP) Development Methodology check out the below video:

For more detailed and very informative video by the founder of XP Ken Beck check out the below video:

Recommended Websites:

http://www.extremeprogramming.org/

http://agilemodeling.com/essays/agileModelingXP.htm

http://www.jamesshore.com/Agile-Book/the_xp_team.html

Comments

comments


Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “Extreme Programming (XP) Development Methodology