eXtreme Programming

1
eXtreme Programming

• Lightweight software development process for
  small groups
• Extreme Programming Explained by Kent Beck
• http//www.xProgramming.com

2
Goals

• Minimize unnecessary work
• Maximize communication and feedback
• Make sure that developers do most important work
• Make system flexible, ready to meet any change in
  requirements

3
Roles

• Customer
• Developer
• Coach
• Tracker
• Tester
• Boss

4
XP Practices

• On-site customer
• The Planning Game
• Small releases
• Testing
• Simple design
• Refactoring

5
XP Practices

• Metaphor
• Pair programming
• Collective ownership
• Continuous integration
• 40-hour week
• Coding standards

6
Process

• Customer produces sequence of stories.
• Developers break stories into tasks.
• Developers implement tasks one at a time, working
  in pairs.
• Developers implement tasks by
• writing tests for it
• doing simplest thing to make tests work
• refactoring until design is simple again

7
Artifacts

• Stories, sorted into iterations.
• Tasks
• Unit tests
• Functional tests
• Code

8
Tests

• Unit tests
• Test each unit of software.
• Write code only if there is a unit test for it.
• All unit tests must always run.
• Written by developers
• Functional tests
• Test entire package
• Written by customer

9
Continuous Integration

• Integrate your work after each task.
• Start with official release
• Once task is completed, integrate changes with
  current official release.
• All unit tests must run after integration.

10
Design

• Design occurs when developers
• Develop metaphor
• Break story into tasks
• Decide how to implement a task
• Refactor

11
Discipline

• Pair programming
• Test first, 100 unit tests
• Simple design

12
XP Planning Game

• Customer writes stories
• Developers estimate
• effort (in man-weeks)
• risk (high, medium, low)
• Budget for each iteration
• Customer picks enough stories to fill iterations.
  

13
Example

• 20 one-week stories, 25 two-week stories, 10
  three-week stories
• 6 developers, able to implement four weeks of
  stories each iteration
• 100 weeks / 4 (weeks/iteration)
• 25 iterations

14
Planning XP Project

• Write stories until they are complete
• Estimate
• Plan
• Execute and measure
• Revise plan
• Execute and measure
• Revise plan
• ...

15
Estimating

• If you cant estimate a story, work on it until
  you can.
• Group design session
• Prototyping (Spike)
• If story is too long, break it into smaller
  stories

16
Revise plan

• Measure actual number of story-weeks implemented.
  This is project velocity.
• Make sure next iteration is no more than project
  velocity of previous iteration.
• Customer can
• add stories
• revise, remove, reschedule stories
• Only developers can estimate stories

17
Characteristics of XP Planning

• Requires a few iterations to make good estimates
• Next iterations are easier to predict than
  iterations that are far away
• Easy to change schedule by changing stories

18
Next time

• Read chapters 4,5 and 7 of Hamlet and Maybee,
  plus sections 2.3, 2.4, and 2.5.