You are on page 1of 26

e Xtreme

Programming
Angelo Corsaro

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
A Brief Overview…
oftware Development Life Cycle

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 3
– System and Software Maintenance
Generic Waterfall Model
Assume a development process in which the
step 1-6 outlined before are executed one after
the other in sequential order.
SWDLC Models

Requirements

Design

Coding
Unit Testing

Test
Integration

Acceptance Test

Maintenance
4
Generic Waterfall Model

This model in not practical, it fails in capturing


the inherent iterative nature of SW
SWDLC Models

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


5
is a minor variation of the DOD SWDLC.
Risk: The Basic Problem
The basic problem of SW development is risk.
SWDLC Models

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
Is a Risk-Driven approach to SW development.
SWDLC Models

It encompass both the best features of both


classic life cycles and prototyping.
Planning Design Spec. Risk Analysis
Prototyping
Req Analysis

Unit Testing
Coding
Accptance Test Test and Integration.

Client Evaluation Development


And Input Prototyping
7
Spiral Model 2/2

The Spiral Model can be used effectively for


SWDLC Models

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
Other SWDLC Models

Rapid Throwaway Prototype Model.


SWDLC Models

Incremental Development Model.

Evolutionary Prototype Model.

Cleanroom Approach (Based on mathematical


specification of the software requirements).

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
Main XP Concepts

XP is a lightweight development process.


XP Introduction

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

Communication.
XP Values

Simplicity.

Feedback.

Courage.

12
Communication

Often problem that arise in SW project can be


tracked back to lack of communication.
XP Values

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
Simplicity

XP embrace the principle of “Make it Simple”


XP Values

XP is betting that it is better to do a simple


thing today and pay a little more tomorrow to
change it, if it needs to be changed, than
building a more complicate system that has
feature that will never be used.

Simplicity and Communication support each


other mutually.

14
Feedback

Feedback works in XP at different time scales.


XP Values

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
15
developer.
Courage

XP team should have the courage of throwing


code away.
XP Values

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

Rapid Feedback.
XP Principles

Assume Simplicity.

Incremental Change.

Embracing the Change.

Quality Work.

17
More XP Principles

Teach learning. Accepted


XP Principles

Responsibility.
Small Initial
Investment. Local Adaptation.

Play to Win. Travel Light.

Concrete Honest
Experiments. Measurement.

Open, Honest Work with people


Communication. instinct’s not against
them.
18
XP Practices

The Planning Game. Pair Programming.


XP Practices

Small Releases. Collective


Ownership.
Metaphor.
Continuous
Simple Design. Integration.
Testing. 40-Hours a Week.
Refactoring. On-Site Customer.

Coding Standards.
19
Putting it all Together 1/2

Planning Designing
User Stories Simplicity is the Key
Release Planning Choose a System
Release Plan Metaphor
Make Frequent Small CRC Cards
Releases Spike Solution
Project Velocity Never add Functionality
Iterative Development Early
Iteration Planning Refactor Mercilessly
Move People Around
Daily Stand Up Meeting
Fix XP When it Breaks

20
Putting it all Together 2/2

Coding Testing
On Site Customer Unit Tests
Coding Standard When a Bug is Found
Code Unit Then Test Acceptance Test
Pair Programming
Sequential Integration
Integrate Often
Collective Code
Ownership
Optimize Last
40 Hours a Week

21
XP Project

22
XP Project

23
XP Project

24
XP Project

25
References

Extreme Programming Explained, Kent Beck


Addison Wesley 1999

Refactoring: Improving the Design of Existing


Code, Martin Fowler, Addison Wesley 1999

http://www.extremeprogramming.org

http://www.xp2001.org

26

You might also like