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.
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.
Kint now works in Facebook where he is a Agile coach where he coaches programmers.
The 5 principles behind Extreme Programming (XP) Development Methodology are:
As other Agile development methodologies; XP puts emphasise on delivering quickly and early to gather feedback.
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.
The programmer is the person who actual does the work during the increment.
The coach is responsible for overseeing the work ensuring the project stays on track.
The tester tests codes functionality ensuring it meets the test criteria.
The tracker purpose is to ensure everything is going to plan and if not the rectify it.
The manager reports to the Gold Owner and is responsible for ensuring the project is delivered.
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.
This is the person who pays for the project the sponsor in Scrum terms.
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.
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.
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:
One of the most important skills and competencies a project manager can have is interpersonal… Read More
I originally wrote this article on virtual portfolio planing for the newly published book called… Read More
Before we discuss icebreakers for introverts you need to remember introverts don't like participating in… Read More