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”
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 Principles
The 5 principles behind Extreme Programming (XP) Development Methodology are:
- Simplicity – Only do what is needed and asked for.
- Communication – Everyone is part of the team and communicate daily
- Feedback – Demonstrate software early and often and listen to any feedback
- Courage – Tell the truth about progress and estimates
- 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 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 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 run 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 the organization.
- Gold Owner: This is the person who pays for the project the sponsor in Scrum terms.
Extreme Programming Practices/Ceremonies
The 12 XP practices are as follows:
- Planning Games: Quickly determine the scope of next iteration by taking into consideration business priorities and estimates.
- Small Releases: Deliver quickly and early by having short iterations, first create a minimum marketable feature and release new versions based on feedback.
- Metaphors: Guide development using a simple shared story to eliminate technical talk.
- Simple Design: Just-enough-design policy ie. exact specifications just for that story. Extra complexity removed once discovered.
- Testing: Develop test cases first, then code to test cases, then automate test cases.
- Pair Programming: 2 developers working on 1 story where 1 drive and the other 1 navigate where they would continuously switch roles.
- Re-factoring: Restructure complex/poor structured code without effecting behaviour, aims to remove duplication, simplify or add flexibility.
- Collective Code Ownership: Anyone works on any code to avoid knowledge silos which result in high-quality code.
- Continuous Integration: Automated builds and tests so the system checked every time a task is completed.
- 40-hour Work Week: No overtime to enable long term productivity and predictable results.
- On-Site Customer/Whole Team: Have a product owner/business/real-life user on the team to answer questions is a member of the team
- Coding Standards: Strict adhere to code standards with rules that emphasize communication through code.
Extreme Programming Artifacts
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>
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.
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 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.
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.
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”
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.
More Information on Extreme Programming
For a quick overview of Extreme Programming (XP) Development Methodology check out the below video: