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

13
Refactoring Example Extract Method

• String sreader.readLine()
• resultassembleDashedString(s)
• public static String
• assembledDashedString(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())

14
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

15
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

16
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

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

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

19
User Story Form
20
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).

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

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

23
Iterative Planning and Development (contd.)

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

24
XP Timeline
Customer
Write stories
Pick stories
Implement stories
Estimate stories
Developers
25
Testing with JUnit

• The JUnit tool is available from www.junit.org
• The XP programming philosophy is program
  incrementally, test-first, and integrate
  continuously.
• Tests are generally written method-by-method. A
  test should be created whenever the programmer
  perceives a risk in the code.
• Key benefits of automated testing
• You can run the tests over and over again
• Have a framework that facilitates testing
• Better confidence in quality of code
• By testing first, the design becomes more focused
  on implementing behavior (less wasteful code)

26
How to do it (The Test/Code cycle)

• Write one test
• Compile the test it should fail to compile,
  because you havent implemented the code that the
  test calls.
• Implement just enough to compile.
• Run the test and see it fail.
• Implement just enough to make the test pass.
• Run the test and see it pass.
• Refactor for clarity and remove duplication.
• Repeat from top.

27
Installing JUnit

• Download .zip file (latest version is 3.7) and
  unzip.
• Make sure that junit.jar is on your classpath.
• To run JUnit with text-only TestRunner
• In your TestCase, add the following
• public static void main(String args)
• junit.textui.TestRunner.run(suite())
• To run JUnit with a GUI TestRunner
• From command prompt, type
• java -classpath location of junit.jarlocatio
  n of your testcase .class file
  junit.swingui.TestRunner testcase name
• In this case, no need for main() method in the
  testcase.

28
Whats inside a TestCase?
import junit.framework. public class
TutorialTest extends TestCase public
TutorialTest(String name) super(name)
public static void main(String args)
junit.textui.TestRunner.run
(TutorialTest.class) public void
testSayHello() HelloWorld world new
HelloWorld() assertTrue("World is created",
world!null )
assertEquals("Hello World",
world.sayHello() ) public static Test
suite () TestSuite suite new TestSuite()
suite.addTest(new TutorialTest
("testSayHello")) return suite
TestCase
TestCase constructor()
IndividualTest()
IndividualTest()
IndividualTest()
TestSuite
29
Resources

• Extreme Programming Explained, Explored,
  Installed, Kent Beck
• William Wake
• Ron Jeffries, Ann Anderson, Chet Hendrickson
• Extreme Programming in Practice,
• James Newkirk and Robert Martin
• Refactoring, Martin Fowler
• Http//c2.com/cgi/wiki?ExtremeProgramming
• http//extremeprogramming.org
• http//xprogramming.com
• http//www.xp123.com