extreme programming brian shearing british computer society advanced programming sg, 14 th february...

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