Upload
conrad-owen
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Extreme Programming
Brian Shearing
British Computer SocietyAdvanced Programming SG, 14th February 2002
Edinburgh Branch, 13th March 2002
Extreme ProgrammingBrian Shearing
British Computer Society
Advanced Programming SG, 14th February 2002
Edinburgh Branch, 13th March 2002
4
Shape of talk
Background to XP XP practices How to start doing XP Experiences with XP Recent work, and references
Part I
Background to Extreme Programming
6
Kent Beck
7
Cost of software change
8
Cost of software change
9
Cost of software change
10
The promise of XP
11
The software development rice pudding
Cost Time
Quality
Scope
12
sotto voce: delivery who-knows-when
XP and contracts
fixed pricefixed scope
Non-XP contract
fixed pricefixed date
roughly fixed scope
XP contract
13
XP. It worked for them.
• Bayerische Landesbank
• Credit Swiss Life
• DaimlerChrysler
• First Union National Bank
• Ford Motor Company
• UBS
Part II
XP practices
15
On-site customer
developer
developer
developer
developercustomer
developer
developer
developer
16
On-site customerCustomer’s company pleads that cost of placing
member of staff at permanent disposal of the development team cannot be justified.
?yes
Abandon project. Customer is not serious about quality, applicability and timeliness of final product. It doesn’t matter to their business.
no
Customer designates junior member of staff.
?yes no
Organ-grinder turns up
17
User stories• XP replacement for requirements document
• Like usage scenarios, but not limited to GUI.
• Written by the resident team customer.
• Each story is a few sentences.
• Customer is in team, so details can wait.
• Each story is the basis for acceptance tests.
• Developers help customer write stories, so that estimated development time is 1-3 weeks.
• Typical project might have a hundred stories.
18
Project structure
Product
Release (1-3 months)
Iteration (1-3 weeks)
Task (1-3 days)
19
Planning game
Product
Release (1-3 months)
Stories
Planning game
Release plan
The customer writes the stories.
The developers estimate the time for each.
Together they derive the release plan.
20
Iteration meetingProduct
Release (1-3 months)
Iteration (1-3 weeks)
Task (1-3 days)
Stories in release
plan
Iteration meeting
Iteration plan
Customer and developers choose stories to develop in this iteration, based on…
developers’ estimates.
Together they derive the iteration plan...including break-down into tasks.
Never plan beyond the next iteration.
XP planning
is JIT planning
21
Project velocityOnce per iteration: timesheets
JoeTask Mo Tu We Th Fr Sa Su TotalDB 4 2 3 9Compiler 2 4 6RegExp 2 6 8 4 20
spreadsheet
Task Hours Est. H/E % Done?DB 150 120 125 yesCompiler 46 29 159 noRegExp 25 27 93 yes
22
Project velocityOnce per iteration:
Task EstimateDone this iteration? Velocity
DB 120 yes 120Compiler 29 noRegExp 27 yes 27
147
project velocity =sum of estimatesfor stories and tasks completed during this iteration
self-correcting for bad
estimators
no timesheets!
Use velocity to decide which tasks to do in next iteration
23
Project velocityAlso use velocity to decide which
stories to implement in next release
or by scope:
number of iterations in next release = required stories * estimated time per story / velocity
Plan by time:
number of stories available in next release = iterations * velocity / estimated time per story
24
Spike solutionsSometimes you simply
cannot make an estimate for a story or task. So write a ‘spike’
program to learn enough to make an estimate.Include the spike
program as a task in the iteration; the real task must wait an iteration.
Don’t forget to put the program on the spike when its job is done.
25
Frequent acceptance tests• acceptance tests built from user stories
• one story may lead to many acceptance tests
• building acceptance tests are tasks in the iteration chosen for the user story
• on-site customer checks functionality of tests
• running of acceptance tests is automated
• results are published (“publish” = “put on wall ”)
• next iteration includes tasks to fix failed tests
26
Daily stand-up meetingSince
yesterday’s meeting, I’ve
been ...
I don’t know how to ...
I don’t know how to ...
Lasts as long as it needs to,
usually between 10 and 30 mins
Eliminates the need for
almost all other meetings
Since yesterday’s
meeting, I’ve been ...
Since yesterday’s
meeting, I’ve been ...
Since yesterday’s
meeting, I’ve been ...
I don’t know how to ...
Since yesterday’s
meeting, I’ve been ...
27
CRC cardsClass, Responsibilities and Collaborations
•simplest design method that actually works
•promotes object-oriented thinking
•great for team design
28
Pair programmingOne computer:
two programmers…sitting side-by-side
…one doing the typing, and thinking about the
detail of the code …while the other thinks about the bigger picture,
and what comes next.A pair produces as much as two working
separately, but the quality is higher
29
Move people• Swap developers between kinds of task.
• Interchange pairs.
• Put a newcomer as pair to an old hand.
30
Optimisation
First rule of optimisation: Don’t
Second rule of optimisation: Don’t yet
That’s the XP way. Make it work, make it right,
then make it fast.
31
No early functionality
Write only what is in the iteration plan.
Only 10% of the extra stuff will ever get used.
Programmers have a natural inclination to write extra stuff,
believing that it might turn out to be useful, one day.
The more experienced the programmer the more likely they
are to succumb to this syndrome. Don’t!
Even if it did get used, writing it delays delivery of the iteration.
32
SimplicityWrite the simplest possible code that
achieves the required functionality.
Think of the people who will be looking after your
code in the future.
Think of your fellow team members.
This may be the most difficult practice of XP to achieve.
33
No overtime• If overtime is necessary, something is wrong.• If you really must, do at most one week of
overtime before reverting to regular hours.
Nobody makes good decisions when they are tired, however
good they are when they are not tired.
Who wants software
written by people
making bad decisions?
34
Refactor, all the time• A refactored program does each thing exactly
once.• Every time a change is made, refactor to eliminate
redundancy.• … especially if you are a cut-and-paste
programmer• … which we are all forced to be by the lack of
proper descriptions of must utility components.
35
Refactoring
“A change made to the internal structure of software to make it easier to understand and to modify, without changing its observable behaviour.”
36
Refactoring; Step 1 of 3:
• duplicated code• long method• long parameter list• shotgun surgery• divergent change• primitive obsession• feature envy
• switch statements• temporary field• data class• message chains• parallel inheritance
hierarchies• comments
… (22 in total)
Name that smellName that smell
37
Refactoring; Step 2 of 3: Refer to smell dictionaryRefer to smell dictionary
Entry in smell dictionary under long method suggests four refactorings to consider, to remove smell:
extract method;
replace temp with query;
replace method with method object;
decompose conditional.
73 refactorings in total
38
Refactoring; Step 3.1 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp with query” in this method (twice):
int basePrice;int discount;
int price() {basePrice = quantity * itemPrice;if (basePrice > 1000) discount = 95;else discount = 98;return basePrice * discount / 100;
}
39
Refactoring; Step 3.2 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp basePrice with query”
int basePrice() { return quantity * itemPrice; }int discount;
int price() {basePrice = quantity * itemPrice;if (basePrice > 1000) discount = 95;else discount = 98;return basePrice * discount / 100;
}
40
Refactoring; Step 3.3 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp basePrice with query”
int basePrice() { return quantity * itemPrice; }int discount;
int price() {
if (basePrice() > 1000) discount = 95;else discount = 98;return basePrice() * discount / 100;
}
41
Refactoring; Step 3.4 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp discount with query”
int basePrice() { return quantity * itemPrice; }int discount() { return basePrice() > 1000 ? 95 : 98; }
int price() {
if (basePrice() > 1000) discount = 95;else discount = 98;return basePrice() * discount / 100;
}
42
Refactoring; Step 3.5 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp discount with query”
int basePrice() { return quantity * itemPrice; }int discount() { return basePrice() > 1000 ? 95 : 98; }
int price() {
return basePrice() * discount() / 100;}
43
Refactoring; Step 3.5 of 3.6: Do some refactoringsDo some refactorings
e.g. “Replace temp with query”
int basePrice() { return quantity * itemPrice; }int discount() { return basePrice() > 1000 ? 95 : 98; }
int price() { return basePrice() * discount() / 100; }
44
Refactoring: some XP advice • To add a feature…first refactor the program to
make it easy to add the feature, then add it.
• Refactoring changes programs in small steps. If you make a mistake, it is easy to find the bug.
• When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
• Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
45
Unit-tests for everything
edit compile
saveunit-test
XP coding cycle
functional-test
edit compile
save
unit-test
Traditional coding cycle
functional-test
click!Write the unit-test before you
write the code it tests.
46
public class LexisTest extends TestCase {
A unit-test
private void check(String s, int[] r) { }
package tsf.geddi;import junit.framework.TestCase;
public LexisTest(String s) { super(s); }… individual tests ...
Lexis x = Lexis.over(s); for (int t = 0; t != r.length; x.scan(), ++t) assert(x.token() == r[t]);
47
Individual tests
public void testEndOfLineSource() { check(" \n ", new int[] {Lexis.START, Lexis.END_LINE, Lexis.END}); }
public void testEmptySource() { check("", new int[] {Lexis.START, Lexis.END}); }
public void testOnceEndAlwaysEnd() { check("", new int[] {Lexis.START, Lexis.END, Lexis.END}); }
48
Collective ownership
Anyone on the team can change any item of code.
This is:
safe all code is protected by unit-tests
efficient removes dependencies on individuals
good practice all members of team become familiar with the whole product
49
Coding standardsTo make pair programming and collective code-ownership practical, there must be agreed standards for the layout of code.
If you find a developer who cannot accept this discipline, your
duty is clear.
50
New test for new bugWhen you get a bug report, the last thing you do is fix it.
BUG!BUG!Unit-test suite......new test
add new test run tests failure!failure!
fix bugrun testssuccess!success!Test stays
in suite forever
51
Testing: some XP advice • Before you start refactoring, check that you
have a solid suite of tests.
• Make sure that all tests are fully automatic and that they check their own result.
• Run unit-tests frequently—every unit-test and every acceptance test at least once a day.
• Don’t let your fear that you can’t catch all bugs stop you from writing tests that will catch most bugs.
52
Fix XP when brokenXP practices are not sacred.
Try them
but if they don’t fit with your development culture, don’t hesitate to adapt them.
You don’t need to use them all if some make you uncomfortable.
For example, unit-testing and refactoring should be the way that every programmer works.
Part III
Starting to use XP
54
XP is best at ...
…building systems whose requirements are in continual flux [stories, iterations]
…minimising risk [frequent small releases]
…maximising programmer-productivity [pair-programming, unit tests, continuous refactoring]
…minimising customer-disappointment [customer is member of team]
55
First XP project
• Start with a new project.
• Look for a customer who is willing to commit.
• Try-out user-stories in place of specifications.
• Experiment with spike solutions.
• Start planning some iterations.
56
Think hard about using XP if ...…the manager (or customer) insists on ‘signed-off’
specification covering every detail;
…the culture of the company judges your worth by how late you work;
…you need more than about ten programmers;
…you can’t keep simplifying because new software must replicate complexities of old;
…you can’t rebuild and test the software several times every day;
57
… or if you cannot set up an environment like this
acceptance tests needing
attention
planned CRC sessions
iteration plan table for CRC cards and food
chair of photographer
no carpet: chairs easy to move
Forget about geographically separated teams, and
home working
Part IV
Experiences with XP
59
?
planning game
user stories
small releases
iterations
iteration meeting
daily stand-up meeting
simplicity
spike solutions
no early function
available customer
move people
coding standards
unit test first
pair programming
integrate often
collective ownership
lazy optimisation
no overtime
refactor
unit tests for everything
pass tests before release
new tests for new bugs
frequent acceptance testsfix broken XP
project velocity
CRC cards
60
?
planning game
user stories
small releases
iterations
iteration meeting
daily stand-up meeting
simplicity
CRC cards
spike solutions
no early function
available customer
move people
coding standards
unit test first
pair programming
integrate often
collective ownership
lazy optimisation
no overtime
refactor
unit tests for everything
pass tests before release
new tests for new bugs
frequent acceptance testsfix broken XP
project velocity
?
61
?
planning game
user stories
small releases
iterations
iteration meeting
daily stand-up meeting
simplicity
CRC cards
spike solutions
no early function
available customer
move people
coding standards
unit test first
pair programming
integrate often
collective ownership
lazy optimisation
no overtime
refactor
unit tests for everything
pass tests before release
new tests for new bugs
frequent acceptance testsfix broken XP
project velocity
12 48 24 16
Part V
Recent work, and references
63
SoftwareUnit testing, Java: www.junit.orgIntegration testing, J2EE (Cactus): jakarta.apache.orgSystem testing, Java:
jakarta.apache.org/ant/index.htmlFunctional testing, JSP:
sourceforge.net/projects/httpunitPerformance testing:
jakarta/apache.org/builds/jakarta-jmeter/releaseLoad testing:
www.clarkware.com/software/JUnitPerf.htmlUnit testing, Delphi: dunit.sourceforge.netUnit testing, .NET: nunit.sourceforge.net
64
ReferenceseXtreme Programming explained, by Kent Beck;
Addison-Wesley, ISBN 0-201-61641-6Refactoring; Improving the Design of Existing
Code, by Martin Fowler; Addison-Wesley, ISBN 0-201-48567-2
Java Tools for eXtreme Programming, by Richard Hightower and Nicholas Lesiecki; Wiley, ISBN 0-471-20708-X
Agile Modeling, by Scott W. Ambler; Wiley, ISBN 0-471-20282-7
XP: www.xprogramming.com