Xtreme Programming
e
Angelo Corsaro
(modified by G. Blank, with notes from Extreme Programming FAQ
and Mike Rogers, BrainLoaf.com)
corsaro@cs.wustl.edu
http://tao.doc.wustl.edu/~corsaro
Table of Contents
Software Development Life Cycle (SWDLC).
SWDLC Models.
Cost Of Change.
XP Introduction.
XP’s Values.
XP’s Principles.
XP’s Practices.
Putting it all Together.
An XP Project Road-Map.
References.
2
Software Development Life Cycle
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
1.
2.
3.
4.
5.
6.
Requirement Analysis
Design Specification
Coding and Unit Testing
Test and Integration
Acceptance Test
System and Software Maintenance
3
SWDLC Models
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
Design
Coding
Unit Testing
Test
Integration
Acceptance Test
Maintenance
4
SWDLC Models
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 WaterfallModel.
NASA uses a SWDLC development model that is a
minor variation of the DOD SWDLC.
5
Risk: The Basic Problem
SWDLC Models
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.
6
Spiral Model 1/2
It encompass both the best features of both classic
life cycles and prototyping.
Planning
Design Spec.
Req Analysis
Risk Analysis
Prototyping
Coding
Unit Testing
SWDLC Models
Is a Risk-Driven approach to SW development.
Accptance Test
Client Evaluation
And Input
Test and Integration.
Development
Prototyping
7
Spiral Model 2/2
SWDLC Models
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.
8
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.
9
Extreme Programming (XP)
XP Introduction
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
10
Main XP Concepts
XP Introduction
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
11
The Four Core Values of XP
XP Values
Communication.
Simplicity.
Feedback.
Courage.
12
XP Values
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.
13
XP Values
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 ain’t gonna need it'')
Simplicity and Communication support each other
mutually.
14
Feedback
XP Values
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.
15
XP Values
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.
16
Core XP Principles
XP Principles
Rapid Feedback.
Assume Simplicity.
Incremental Change.
Embracing the Change.
Quality Work.
17
XP Practices
Twelve XP Practices
The Planning Game.
Pair Programming.
Small Releases.
Collective Ownership.
Metaphor.
Continuous Integration.
Simple Design.
40-Hours a Week.
Testing.
On-Site Customer.
Refactoring.
Coding Standards.
18
XP Practices (1)
XP Practices
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.
19
XP Practices (2-4)
XP Practices
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).
20
XP Practices (5)
XP Practices
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.
21
XP Practices (6)
XP Practices
Pair programming.
Two programmers work
together at one machine.
Driver enters code, while
navigator critiques it.
Periodically switch roles.
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.
22
XP Practices (7-9)
XP Practices
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.
23
XP Practices (10-12)
XP Practices
40-hour work week.
Programmers go home on time.
In crunch mode, up to one week of overtime is allowed.
More than that and there’s 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.
24
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
25
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
26
XP Project
27
XP Project Iteration
28
XP Project Development
29
XP Project Coding
30
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
31
References
Extreme Programming Explained, Kent Beck Addison
Wesley 1999.
http://www.extremeprogramming.org
http://BrainLoaf.com
http://Wiki.com
http://www.xp2001.org
32