Applicable

Don Wells defines XP as appropriate for use when

• Working with dynamically changing software

• There are risks with new technology

• Working with small, co-located development teams

• Technology being used supports automated unit and functional tests

XP Framework

The XP Framework has

• Values

• Practices

• Roles

• Lifecycle

Values

5 Values of XP

• Communication - between one team member to everyone else, face to face discussions with the aid of a whiteboard

• Simplicity - whats the simplest thing that will work to avoid waste

• Feedback - Constant feedback helps identify areas for improvements, revise practices and helps with simple design

• Courage - Courage to raise organisational issues, stop doing something that doesn't work and try something new, accept and act on feedback even if difficult to accept. Also applies to the XP practice of pair programming

• Respect - required to communicate with each other, accept feedback and work together to identify simple design and solutions

Practices

The following are the original practices of XP

• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40-hour week

• On-site Customer

• Coding Standard

Second Edition Practices

Sit Together

Face to face communication, team sit together, remove barriers, osmotic communication

Whole Team

Functional group with all the skills for a product in a single team

Informative Workspace

Support face to face communication and allow people to have privacy

Energised Work

Knowledge work requires focus and no distractions. Physically and mentally able to focus.

Pair Programming

Software development when two people sitting at the same machine. Two brains and four eyes are better than one brain and two eyes and there is a continuous code review which reduces the feedback time.

Proven to

• improve quality

• Solve problems quicker

• Creates less code to acomplish the same solution

• Doesn't take twice as long

Stories

Describe what the product should do in terms meaningful for customers and users.

Weekly Cycle

A week-long software interation. The team meet on the first day and reflect on what has been done and plan for what to do for the next week with the goal of running tested features that realise the stories selected.

Quarterly Cycle

Similar to release planning. The customer provides the plan for the features desired in a quarter to provide the team with “a view of the forest whilst they are in the trees”

Slack

Adding of low priority tasks and stories into weekly and quarterly cycles that can be dropped if a team falls behind on more important tasks.

10 Minute Build

Automatically build the whole system and run all of the tests in less than 10 minutes. Encourages teams to automate the build process to run all tests. This is supported by continuous integration and test first development.

Continuous Integration

Code changes are immediately tested when added to a larger code base with the benefit of catching any integration issues sooner.

Most teams take the approach “If it hurts, avoid it as long as possible”. Practitioners of XP suggest “if it hurts, do it more often”.

Test-First Programming

Normal Path: develop code -> write tests -> run tests

Test-First Programming Path: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat

Incremental Design

Do a little bit of work upfront to understand the wider breadth and go into specifics of the design when you deliver specific features. Refactoring has been integrated into the principle.

Roles

Customer

• What should the system do - features

• How do we know when the system is done - acceptance criteria

• How much do we have to spend - funding and business case

• What to do next - order to deliver features

Assumed to be a single person, however, in reality, this is often a group of individuals that are required to give the team all the business related information they require.

Developer

Everyone on the team except other defined roles is classed as a developer. A developer is responsible for realising the stories identified by the customer.

The Tracker

Some teams may have a tracker or it is a developer who fills this role. The role is to keep track of relevant metrics defined by the team as important to identify areas of improvement e.g velocity and changes to velocity

The Coach

Help apply, coach and mentor teams on XP.

Lifecycle

XP has a weekly and quarterly cycle.

First - the desired results of the project are described by having customers define a set of stories and for each story that's created, the team estimates the size of each story.

This size estimate, along with relative benefit as estimated by the customer can provide an indication of relative value which the customer can use to determine priority of the stories.

If the team identifies some stories that they are unable to estimate because they don’t understand all of the technical considerations involved, they can introduce a spike to do some focused research on that particular story or a common aspect of multiple stories. Spikes are short, time-boxed time frames set aside for the purposes of doing research on a particular aspect of the project. Spikes can occur before regular iterations start or alongside ongoing iterations.

Next, the entire team gets together to create a release plan that everyone feels is reasonable. This release plan is a first pass at what stories will be delivered in a particular quarter, or release. The stories delivered should be based on what value they provide and considerations about how various stories support each other.

Then the team launches into a series of weekly cycles. At the beginning of each weekly cycle, the team (including the customer) gets together to decide which stories will be realized during that week. The team then breaks those stories into tasks to be completed within that week.

At the end of the week, the team and customer review progress to date and the customer can decide whether the project should continue, or if sufficient value has been delivered.