Introduction to Extreme Programming

1
Introduction toExtreme Programming

• References
• William Wake, Capital One
• Steve Metsker, Capital One
• Kent Beck
• Robert Martin, Object Mentor
• Ron Jeffries,et.al.

2
Extreme Programming is...

• An Agile software development method used for
  small to medium-sized development projects
• Philosophy about how to develop code rather than
  rules for design
• Emphasizes
• ongoing user involvement
• pay-as-you-go design
• incremental, test-first programming

3
Why is it Extreme?

• Because it takes good practices to extreme levels
  (turning the knobs up to 10!)
• If code reviews are good, well review code all
  the time (pair programming).
• If testing is good, everybody will test all the
  time (unit testing), even the customers
  (Acceptance Testing).
• If design is good, well make it part of
  everybodys daily business (Refactoring).
• If simplicity is good, well always leave the
  system with the simplest design that supports its
  current functionality. (The simplest thing that
  could possibly work. --Bob Martin

4
Turning the Knobs to 10 (Cont).

• If architecture is important, everybody will work
  defining and refining the architecture all the
  time (Metaphor).
• If integration testing is important, then well
  integrate and test several times a day
  (continuous integration).
• If feedback is good, well get feedback quickly
  -- seconds and minutes and hours, not weeks and
  months and years (the Planning Game). --Bob
  Martin

5
XP Requirements

• There are certain things you must do.
• You must write tests before code.
• You must program in pairs.
• You must integrate frequently.
• You must be rested.
• You must communicate with the customer daily.
• You must follow the customers priorities.
• You must leave the software clean and simple by
  the end of the day.
• You must adapt the process and practices to your
  environment.

6
XP Principles

• Rapid feedback
• Assume simplicity
• Incremental change
• Embrace Change
• Quality Work

• Small releases
• Establish metaphor
• Tests
• On-site customer
• 40-hour week
• Open workspace

7
XP Practices - Development

• Planning game
• Pair programming
• Simple design
• Refactoring
• Collective ownership
• Continuous integration
• Coding standards

8
XP Process

• The Planning Game
• Release Planning
• Iteration Planning
• The Programming Game

9
Release Planning

• Large scale planning for the overall project
• Story is one thing that the customer wants the
  system to do
• Tasks
• Create stories
• Prioritize stories

10
Iteration Planning

• Developers determine what stories can be done
  within schedule
• Developer Tasks
• Read customer stories
• Brainstorm tasks
• Estimate task completion time
• Negotiate with customer to accept tasks

11
Programming Game

• Incremental, test-first programming
• Tasks
• listen
• build unit test
• Test everything that could possibly break
• code
• design (refactor)
• Track time for task completion

12
Tests

• Functional Tests
• Unit Tests

13
Functional Tests

• Specified by the user(i.e. customer)
• Implemented by users, developers, and/or test
  team
• Automated
• Run at least daily
• Part of the specification

14
Unit Tests

• Written by developers
• Written before and after coding
• Support design, coding, refactoring, and quality.

15
Code Approach

• Write a small test
• Run compiler error
• Write enough code to compile
• Run test fails
• Write enough code to pass the test
• Run test succeeds
• Repeat from top

16
Game Play

• Write code test-first
• Use JUnit for tests
• Track time for task completion

17
Design - part of coding

• Pay as you go
• Spike when necessary
• You arent gonna need it
• Simplest thing that could possibly work
• Once And Only Once rule

18
Refactoring Game

• Refactor code until it
• Works (passes tests)
• Communicates what it needs to
• Has no duplication
• Has as few methods and classes as possible
• Eliminate code smells
• Classes too large
• Methods too long
• struct classes
• Useless comments
• Almost (but not quite) duplicated code

19
Refactoring Example Extract Method (Wake)

• String sreader.readLine()
• resultassembleDashedString(s)
• public static String
• assembleDashedString(String s)
• int p1 s.indexOf()
• int p2 s.lastIndexOf()
• String dashed s.substring(0,p1) -
• s.substring(p2, s.length() )
• return dashed

• String sreader.readLine()
• //assemble dashed string
• int p1 s.indexOf()
• int p2 s.lastIndexOf()
• result s.substring(0,p1)
• -
• s.substring(p2, s.length())

20
Refactoring Example (Wake)
21
Other Development Approaches

• UML XP uses it on the whiteboard, if at all
• CRC XP uses them for discovering objects in the
  system
• Rational Unified Process XP has many fewer roles
  documents XP emphasizes team over artifacts
• --Bob Martin

22
User Story

• User Story defined
• Unit of functionality in an XP project
• Written in the language of business
• Focus development team on solving key business
  problems, not specification conversion
• Promise for conversation
• User Story example
• Terry the Traveler finds the lowest fare
• Terry the Traveler books a flight

23
User Story Gathering Session

• User Stories are recorded in a Master List
• User Stories are assigned risk-level
• User Stories are estimated
• Team assumption is made
• Plan is created based on 3-5 week iterations

24
Writing Stories

• The process of writing stories is iterative and
  requires lot of feedback.
• Customers will propose a story to the
  programmers.
• The programmers will ask themselves if the story
  can be tested and estimated, and if it is of
  appropriate size.

25
Writing Stories (contd.)

• The customer will have to specify acceptance
  tests whose execution will determine whether the
  user stories have been successfully implemented.
  Thus all the user stories must be testable
• Splitting of user stories possible.

26
User Story Form
27
Estimating Stories

• 3 keys to effective estimation
• Keep it simple
• Use what happened in the past
• Learn from experience
• Estimation is a team effort
• Estimates are not commitments
• If we dont know enough about solving some
  problem to be able to estimate it, write some
  sample code to help us learn to estimate (Spike
  Estimation).

28
Project Velocity

• This is a measure of how fast work is getting
  done on the project.
• Count up the number of stories or tasks completed
  during the last iteration.
• Then total up the estimates, each task received.
  This is the velocity.
• We may need to re-negotiate the release plan if
  our velocity changes dramatically for more than
  one iteration.

29
Iterative Planning and Development

• Divide the development schedule into about a
  dozen iterations of 1 to 3 weeks in length.
• Create an iteration plan at the start of each
  iteration.
• User stories are chosen from the release plan in
  priority order to be implemented.
• These stories are translated into tasks, broken
  down so each task is 1 to 3 days in length.
• Developers sign up for the tasks and then
  estimate how long their own tasks will take to
  complete.

30
Iterative Planning and Development (cont.)

• Total up the time estimate in ideal programming
  days of the tasks, this must not exceed the
  project velocity from the previous iteration.
• If the iteration has too much, then some stories
  must be postponed until the next iteration.
• The release plan and the iteration plan are not
  the same thing. The former focuses on
  deliverables to the customer while the latter
  concentrates on implementation. The iteration
  plan is for the near-term and is more detailed.

31
XP Timeline
Customer
Write stories
Pick stories
Implement stories
Estimate stories
Developers
32
Class Exercise

• Draw a Coffee Pot

33
Draw a Coffee PotPlanning Phase

• 2 customers
• write stories that describe major functionality
  of coffee pot
• 4 developers
• estimate time to completion(drawing the coffee
  pot)
• 2 moderators
• observe process and enforce rules of process

34
Rules

• Every story has to have a time to completion
• All functionality desired by client must be found
  in one of the stories
• Always ask for help. If not involved in helping
  someone, then you must help if asked

35
Draw a Coffee Pot Iteration Phase

• If not enough time or too much to do, ask client
  to pick smallest subset of functions that are
  acceptable
• Deliver the drawing with the simplest set of
  features that are acceptable and which can be
  done within estimated time