Download Introduction to Extreme Programming

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Design Patterns wikipedia , lookup

Object-oriented programming wikipedia , lookup

Functional programming wikipedia , lookup

C Sharp (programming language) wikipedia , lookup

Structured programming wikipedia , lookup

Transcript
Introduction to
Extreme Programming
William C. Wake
[email protected]
2-2-2000
XP is...
A lightweight development
methodology that emphasizes:
 ongoing user involvement
 testing
 pay-as-you-go design
Background: Cost of
Changes
$
$
t
“Then” (exponential)
t
“Now” (flattened)
Background: Cost of
Money
$
“Up-front design”
$$
“Pay as you go”
t
XP Principles
Rapid feedback
Assume simplicity
Incremental change
Embrace Change
Quality Work
XP Practices
Planning Game
Metaphor
Tests
Refactoring
 Pair programming
Small releases
Simple design
Collective ownership
Continuous
integration
Open workspace
40-hour week
Rights
 Manager and Customer:
 You have the right.. to an
overall plan, to know
what can be
accomplished, when, and
at what cost.
 etc.
 Developer:
 You have the right.. to
know what is needed, via
clear requirement stories,
with clear declarations of
priority.
 etc.
The XP Cycle
(in the small)
analysis
test
code
design
Planning Game
User stories = lightweight use cases
2-3 sentences on a file card that:
 The customer cares about
 Can be reasonably tested
 Can be estimated & prioritized
Planning Game
Users write stories
Developers estimate them
Users split, merge, & prioritize
Plan overall release (loosely) and the next
iteration
Tests
Functional Tests
Unit Tests
Functional Tests
Specified by the user
Implemented by users, developers,
and/or test team
Automated
Run at least daily
Part of the specification
Unit Tests
Written by developers
Written before and after coding
Always run at 100%
Support design, coding, refactoring, and
quality.
Test Metrics
Key:
Tests failed
Tests passed
1
2
3
4
5
6
7
Design
Pay as you go
Spike when necessary
“You aren’t gonna need it”
“Simplest thing that could possibly work”
“Once And Only Once”
Refactor (Mercilessly)
Refactor = to improve the structure of
code without affecting its external
behavior
Done in small steps
Supported by unit tests, simple design,
and pair programming
Seek “once and only once”
Refactoring Example
Replace Magic # w/
Symbolic Constant:
Separate Query
from Modifier:
return 32.5 *
miles_traveled;
Stack:
Object getTopAndPop();
static final double
MILEAGE_RATE = 32.5;
…
return MILEAGE_RATE *
miles_traveled;
Object getTop();
void pop();
Adopting XP
Some practices can be done solo, others
by team, others require users to help.
User involvement
Functional tests and unit tests
Simple design & refactoring
Pair programming
Other Approaches
UML: XP uses it on the whiteboard (if at
all)
Rational Unified Process: XP has many
fewer roles & documents; XP emphasizes
team over artifacts
SCRUM: XP compatible
Who, Us?
And other questions
More Information
Extreme Programming Explained, by Kent
Beck
Refactoring, by Martin Fowler
http://www.xprogramming.com
http://c2.com/cgi/wiki?Extreme
ProgrammingRoadmap