An Introduction to Extreme Programming

1
An Introduction to Extreme Programming

• Mike Rogers

2
An Extreme Introduction

• What is Extreme Programming (XP)?
• Goals of XP
• Values of XP
• Elements of XP
• The XP Process
• How XP compares to other methodologies
• Resources

3
What is XP?

• Developed by Kent Beck at Chrysler
• A light-weight methodology for small to
  medium-sized teams developing software in the
  face of vague or rapidly changing requirements
  -- Kent Beck
• XP values communication, simplicity, feedback
  and courage
• Replaces heavy documentation with continuous
  communication and feedback
• Delivers software to the customer in short (2
  week iterations)
• Seeks to eliminate defects early, thus reducing
  costs

4
Goals of XP

• Deliver business value as quickly as possible
• Deliver ultra high quality software
• C.A.N.I. - Constant And Never-ending Improvement
• Deliver working software at the end of each
  iteration

5
Elements of XP

• Exploration
• Development
• Testing
• Release

6
Exploration

• Planning Game
• Project Velocity
• Iteration Planning
• Release Planning
• Daily stand up meetings

7
Development

• Pair Programming
• Test First programming
• Frequent Delivery of functionality
• Delivery ? Release
• Continuous Refactoring Improvement
• Y.A.G.N.I.
• Collective Code Ownership

8
Testing

• Customer Acceptance Tests
• Unit Tests

9
Release

• Putting code into production
• The point at which users can realize the business
  value of the newly added stories

10
The Planning Game

• Goal The goal of the game is to put the greatest
  possible value of stories into production over
  the life of the game
• Players Customer and Development

11
Moves in the Planning Game

• Write Story
• Estimate Story
• Value Risk First Assessment
• Release Commitment
• Iteration Planning
• Release Planning

12
Write Story

• A story is a short (3 sentence) description of a
  capability of a system its business value
• The Customer writes stories

13
Estimate Story

• After stories are written, they are given an
  estimate
• Developers estimate a story
• Stories are written on Story Cards
• A Story card is a 4x6 inch index card

14
Story Title
Description
Estimate
15
Estimating Rules

• Estimates are provided in ideal hours, days, or
  weeks
• An estimate may not be longer than the current
  Project Velocity
• If the story requires a longer time frame, it
  MUST be split into multiple stories

16
Project Velocity

• Project Velocity is calculated initially by a
  guess at how many ideal days can be commited to
  the project a week
• Velocity is used as the basis for the next
  iteration of planning by adding up the actual
  times for all stories in a current iteration
• The estimates for the next iteration may not
  exceed the current velocity

17
Value Risk

• The developers organize the cards into three
  piles, in order of priority
• Immediate
• Short Term
• Long Term
• Those cards with the highest business value are
  placed, by the customer, in the immediate pile,
  and so on.
• Developers may only move stories from the Long
  Term to Short Term to Immediate piles
• They may not move in the opposite direction.

18
Iteration Planning

• At the start of each iteration, an Iteration
  Planning meeting is held
• Cards have been written, estimated and
  prioritized based on value risk
• Based on the Velocity, the Customer and
  Developers commit to the stories for the next two
  week iteration
• An iteration can be 1 week, but should never be
  shorter to allow for testing and release if
  necessary

19
Release Planning

• A release consists of one or more iterations
• Releases are purely driven by business need
• Releases can be Date driven or Story Driven

20
Daily Standup Meeting

• Goal Identify items to be accomplished for the
  day and raise issues

• Everyone attends, including the customer
• Not a discussion forum, discussions are taken
  offline
• Everyone gets to speak
• 15 minutes

21
Testing

• Client writes Acceptance Tests for each story
• Developers write Unit Tests for all code
• Developers AUTOMATE all tests
• Tests are run after any change, no matter how
  small
• When a bug is found, a new test is written
• Test scores are published to the client

22
Releases

• Software is only released if
• All Unit Tests have passed
• All customer Acceptance Tests have passed
• It makes business sense

23
XP Compared
24
Bibliography Resources

• Websites
• BrainLoaf.com
• ExtremeProgramming.org
• XProgramming.com
• ObjectMentor.com
• Wiki.com
• Books
• The XP Series from Addison Wesley
• Extreme Programming Explained
• Extreme Programming in Practice
• Planning Extreme Programming