eXtreme Programming

1
eXtreme Programming

• Lightweight software development process for
  small groups (lt12)
• 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
• Tester
• Developer
• Coach
• Tracker
• Boss

4
Artifacts

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

5
Activities

• Writing stories
• The planning game
• Standup meeting
• Writing tests
• Making tests work
• Refactoring
• Integrating
• Standup meeting

6
XP Practices

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

7
XP Practices

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

8
Pair programming
9
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

10
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

11
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.

12
Design

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

13
Simple design

• Do the simplest thing that could work
• For each design problem
• What are some solutions?
• Will it work? (yes, no, maybe)
• Pick the simplest one that might work

14
XP Planning Game
15
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.
  

16
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

17
Planning XP Project

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

18
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

19
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

20
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

21
Next time

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