eXtreme Programming

1
eXtreme Programming

• Angelo Corsaro
• (modified by G. Blank, with notes from Extreme
  Programming FAQ and Mike Rogers, BrainLoaf.com)
• corsaro_at_cs.wustl.edu
• http//tao.doc.wustl.edu/corsaro

2
Table of Contents

• Software Development Life Cycle (SWDLC).
• SWDLC Models.
• Cost Of Change.
• XP Introduction.
• XPs Values.
• XPs Principles.
• XPs Practices.
• Putting it all Together.
• An XP Project Road-Map.
• References.

3
A Brief Overview

• A Software Development Life Cycle (SWDLC) is an
  abstract representation of how software is
  developed.
• A SWDLC process can consist of
• Sequential Phases/Steps
• Parallel Phases/Steps
• The Phases of a SWDLC process are typically
• Requirement Analysis
• Design Specification
• Coding and Unit Testing
• Test and Integration
• Acceptance Test
• System and Software Maintenance

Software Development Life Cycle
4
Generic Waterfall Model

• Assume a development process in which the step
  1-6 outlined before are executed one after the
  other in sequential order.

Requirements
SWDLC Models
Design
Coding Unit Testing
Test Integration
Acceptance Test
Maintenance
5
Generic Waterfall Model

• This model in not practical, it fails in
  capturing the inherent iterative nature of SW
  development.
• SW development has concurrent and iterative
  aspects that this model fail to capture.
• Does not encourage prototyping and software
  reuse.
• The DOD SWDLC uses a variation of the
  Waterfall-Model.
• NASA uses a SWDLC development model that is a
  minor variation of the DOD SWDLC.

SWDLC Models
6
Risk The Basic Problem

• The basic problem of SW development is risk.
• Sample of risks are
• Schedule slips
• Project Cancelled
• System Goes Sour
• Defect Rate
• Business Misunderstood
• False Feature-Rich
• Staff Turnover
• Commonly used SWDLC fall short in coping with the
  previously cited risks.

SWDLC Models
7
Spiral Model 1/2

• Is a Risk-Driven approach to SW development.
• It encompass both the best features of both
  classic life cycles and prototyping.

Risk Analysis Prototyping
Design Spec.
Planning
SWDLC Models
Req Analysis
Coding Unit Testing
Accptance Test
Test and Integration.
Client Evaluation And Input
Development Prototyping
8
Spiral Model 2/2

• The Spiral Model can be used effectively for both
• System Enhancement
• System Development
• Most SWDLC can be considered as a special case of
  the Spiral Model.
• The embedded Risk-Analysis built into the model
  avoids many of the difficulties that arise in
  other models.

SWDLC Models
9
Cost of Change

• One Universal Assumption of SW Engineering is
  that the cost of changing a program rises
  exponentially over time
• One of the key assumption of XP is that the cost
  of changing a program, can be kept mostly
  constant over time.
• This assumption is based on real-world
  experience, and on the use of both better
• Programming Practice
• Programming Environments
• This assumption about the cost of change gives
  the opportunity of taking a totally different
  approach to SW development.

10
Extreme Programming (XP)

• XP does not involve bungee cords! And it predates
  Windows XP.
• Developed by Kent Beck (also developed CRC cards)
• A light-weight methodology for small to
  medium-sized teams developing software in the
  face of vague or rapidly changing requirements
  -- Kent Beck
• "Extreme Programming turns the conventional
  software process sideways. Rather than planning,
  analyzing, and designing for the far-flung
  future, XP programmers do all of these activities
  a little at a time throughout development.IEEE
  Computer October 1999

XP Introduction
11
Main XP Concepts

• XP is a lightweight development process
• Instead of lots of documentation nailing down
  what the customer wants up front, emphasize
  continuous communication and feedback between
  developers and programmers
• Embrace change iterate often, design and
  redesign, code and test frequently, keep the
  customer involved.
• Deliver software to the customer in short (2
  week) iterations
• Seeks to eliminate defects early, thus reducing
  costs
• XP is made of a collection of
• Values
• Rules/Principles
• Practices
• In XP values, principles and practices are often
  set to the extreme level, from here the name
  eXtreme Programming

XP Introduction
12
The Four Core Values of XP

• Communication.
• Simplicity.
• Feedback.
• Courage.

XP Values
13
Communication

• Often problem that arise in SW project can be
  tracked back to lack of communication.
• XP enforces the Communication Value by employing
  many practice that could not be carried without
  communicating (e.g. pair programming, unit
  testing etc.).
• XP employs a Coach whose job is that of noticing
  when people are not communicating and reintroduce
  them.

XP Values
14
Simplicity

• ''Do the simplest thing that could possibly
  work'' (DTSTTCPW) principle (elsewhere known as
  KISS).
• An XP coach may say DTSTTCPW when he sees an XP
  developer doing something that is needlessly
  complicated.
• YAGNI principle (''You aint gonna need it'')
• Simplicity and Communication support each other
  mutually.

XP Values
15
Feedback

• Feedback works in XP at different time scales.
• Programmers have feedback on a minutes time scale
  on the status of the system thanks to unit tests.
• When customers write new stories the programmers
  estimate those immediately to give prompt
  feedback to the customer about the quality of the
  stories.
• The customer review the scheduler every 2-3 weeks
  and provide prompt feedback to the developer.

XP Values
16
Courage

• XP team should have the courage of throwing code
  away.
• XP team should have the courage of mainly
  refactor the architecture of the system, if
  architectural flaw are detected.
• Courage has in XP the same role that mutation has
  in genetic algorithms. Takes you out of local
  maximum/minimum.

XP Values
17
Core XP Principles

• Rapid Feedback.
• Assume Simplicity.
• Incremental Change.
• Embracing the Change.
• Quality Work.

XP Principles
18
Twelve XP Practices

• The Planning Game.
• Small Releases.
• Metaphor.
• Simple Design.
• Testing.
• Refactoring.

• Pair Programming.
• Collective Ownership.
• Continuous Integration.
• 40-Hours a Week.
• On-Site Customer.
• Coding Standards.

XP Practices
19
XP Practices (1)

• The Planning Game.
• Customer and developers cooperate to produce the
  maximum business value as rapidly as possible.
• Customer comes up with a list of desired features
  for the system.
• Each feature is written out as a User Story,
  giving each feature a name and describes in broad
  strokes what is required. User stories are
  typically written in 2-3 sentences on 4x6 story
  cards.
• Developers estimate how much effort each story
  will take, and how much effort the team can
  produce in a given time interval (iteration).
• Project velocity how many days can be committed
  to project per week.
• Customer decides which stories to implement in
  what order, and when and how often to produce a
  production releases of the system.

XP Practices
20
XP Practices (2-4)

• Small releases.
• Start with the smallest useful feature set.
• Release early and often, adding a few features
  each time.
• Releases can be date driven or user story driven.
• System metaphor.
• Each project has an organizing metaphor, which
  provides an easy to remember naming convention.
• Simple design.
• Always use the simplest possible design that gets
  the job done.
• The requirements will change tomorrow, so only do
  what's needed to meet today's requirements
  (remember, YAGNI).

XP Practices
21
XP Practices (5)

• Continuous Testing
• Before programmers add a feature, they write a
  test for it.
• When the suite runs, the job is done.
• Tests in XP come in two basic flavors.
• Unit Tests automate testing of functionality as
  developers write it.
• Each unit test typically tests only a single
  class, or a small cluster of classes.
• Unit tests typically use a unit testing
  framework, such as JUnit.
• Acceptance Tests (or Functional Tests) are
  specified by the customer to test that the
  overall system is functioning as specified.
• When all the acceptance tests pass for a given
  user story, that story is considered complete.
• Could consist of a script of user interface
  actions and expected results that a human can
  run.
• Ideally acceptance tests should be automated,
  either using the unit testing framework, or a
  separate acceptance testing framework.

XP Practices
22
XP Practices (6)

• Pair programming.
• Two programmers work together at one machine.
• Driver enters code, while navigator critiques it.
• Periodically switch roles.

XP Practices

• Research results
• Pair programming increases productivity.
• Higher quality code in about half the time.
• Increased satisfaction/decreased frustration).
• Williams, L., Kessler, R., Cunningham, W.,
  Jeffries, R. Strengthening the case for pair
  programming. IEEE Software, 17(3), July/August
  2000.
• Requires proximity in lab or work environment.

23
XP Practices (7-9)

• Refactoring.
• Refactor out any duplicate code generated in a
  coding session.
• You can do this with confidence that you didn't
  break anything because you have the tests.
• Collective code ownership.
• No single person "owns" a module.
• Any developer can work on any part of the code
  base at any time.
• Continuous integration.
• All changes are integrated into the codebase at
  least daily.
• Tests have to run 100 both before and after
  integration.

XP Practices
24
XP Practices (10-12)

• 40-hour work week.
• Programmers go home on time.
• In crunch mode, up to one week of overtime is
  allowed.
• More than that and theres something wrong with
  the process.
• On-site customer.
• Development team has continuous access to a real
  live customer, that is, someone who will actually
  be using the system, or a proxy.
• Coding standards.
• Everyone codes to the same standards.
• Ideally, you shouldn't be able to tell by looking
  at it who on the team has touched a specific
  piece of code.

XP Practices
25
Putting it all Together

• Planning
• User Stories
• Release Planning
• Release Plan
• Make Frequent Small Releases
• Project Velocity
• Iterative Development
• Iteration Planning
• Move People Around
• Daily Stand Up Meeting
• Fix XP When it Breaks

• Designing
• Simplicity is the Key
• Choose a System Metaphor
• CRC Cards
• Spike Solution
• Never add Functionality Early
• Refactor Mercilessly

26
Daily Standup Meeting

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

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

27
XP Project
28
XP Project Iteration
29
XP Project Development
30
XP Project Coding
31
XP vs. Rational Unified Process
XP RUP
Primary Communication Medium Short Daily Face to Face meetings, Pair Programming Client Status Meetings, Design Meetings
Development Methodology Code, Refine, Test Design, Document, Code, Test
Focuses on Delivering software quickly Following the process to develop good software
Quality Focus Eliminate Defects as early as possible in the process using whole team Eliminate defects on a scheduled basis with a separate team
32
References

• Extreme Programming Explained, Kent Beck Addison
  Wesley 1999.
• http//www.extremeprogramming.org
• http//BrainLoaf.com
• http//Wiki.com
• http//www.xp2001.org