Understanding Agile Development: The XP Approach, Slides of Computers and Information technologies

Download Understanding Agile Development: The XP Approach and more Slides Computers and Information technologies in PDF only on Docsity!

Agile Software Development

Ian Holyer

Ian Holyer

Agile Development

In recent years, some specific methodologies such as

In recent years, some specific methodologies such as

Extreme Programming (XP) have become popular

Extreme Programming (XP) have become popular

However, many people have also realised that you

However, many people have also realised that you

can pick and choose between methodologies

can pick and choose between methodologies

The important thing is to develop the right attitudes,

The important thing is to develop the right attitudes,

and to pick really good modern techniques and tools

and to pick really good modern techniques and tools

With these, a company can build an agile

With these, a company can build an agile

development methodology of its own

development methodology of its own

We are going to look at some of these techniques and

We are going to look at some of these techniques and

tools, and we are going to choose the XP viewpoint,

tools, and we are going to choose the XP viewpoint,

but without over-selling it

but without over-selling it

Conventional Wisdom

Conventional wisdom is collected together into the

Conventional wisdom is collected together into the

"big books" of Software Engineering:

"big books" of Software Engineering:

"Software Engineering" by Pressman & Ince

"Software Engineering" by Sommerville

These tell you what to do, including what design

These tell you what to do, including what design

methodologies to use, for successful development

methodologies to use, for successful development

They are very good reference books, and are full of

They are very good reference books, and are full of

useful information and pointers to other material, but

useful information and pointers to other material, but

they are just too indigestible

they are just too indigestible

So what is different about Extreme Programming?

So what is different about Extreme Programming?

What is Extreme Programming?

Extreme programming (XP) is about development in

Extreme programming (XP) is about development in

an extreme environment (usually in a business setting)

an extreme environment (usually in a business setting)

It is "yet another" methodology for development

It is "yet another" methodology for development

It requires people who are good at programming and

It requires people who are good at programming and

developing, and who are well trained, but they don't

developing, and who are well trained, but they don't

have to be superhuman

have to be superhuman

The best way to find out about XP is to read the

The best way to find out about XP is to read the

overview book (in a weekend, or an evening):

overview book (in a weekend, or an evening):

"Extreme Programming Explained", by Kent Beck

Failing that, google "Extreme Programming"

Failing that, google "Extreme Programming"

Does XP go against conventional wisdom?

Does XP go against conventional wisdom?

Should Everyone Use XP?

The Kent Beck book says that although XP

The Kent Beck book says that although XP

techniques are simple and not original ...

techniques are simple and not original ...

... it is difficult to make effective use of them without

... it is difficult to make effective use of them without

combining them into XP, because of the interactions

combining them into XP, because of the interactions

BUT it is about extreme conditions, and most

BUT it is about extreme conditions, and most

development is not extreme

development is not extreme

AND anyway, there are other ways of handling

AND anyway, there are other ways of handling

extreme conditions (though they are all "agile")

extreme conditions (though they are all "agile")

SO no, XP is not for everyone, and not all the time

SO no, XP is not for everyone, and not all the time

So, why are we studying XP?

So, why are we studying XP?

Picking from XP

XP has collected some of the very best, simplest and

XP has collected some of the very best, simplest and

most effective techniques in each development area

most effective techniques in each development area

It has adopted, or prompted new development of,

It has adopted, or prompted new development of,

some of the very best tools in each development area

some of the very best tools in each development area

It continues to be a kind of testbed where techniques

It continues to be a kind of testbed where techniques

and tools are put under extreme stress to see whether

and tools are put under extreme stress to see whether

they

they really

really work or not in practice

work or not in practice

So, it is one of the first places to look when picking

So, it is one of the first places to look when picking

and choosing general techniques and tools

and choosing general techniques and tools

ALSO, even if you don't use XP, its overall agile

ALSO, even if you don't use XP, its overall agile

philosophy helps in avoiding mistakes & pitfalls

philosophy helps in avoiding mistakes & pitfalls

What drives XP?

What drives XP?

The Result of the Fear

That means that old methodologies (waterfall-based)

That means that old methodologies (waterfall-based)

concentrate on fixing problems during analysis/design

concentrate on fixing problems during analysis/design

Newer methodologies (e.g. spiral) still pay too much

Newer methodologies (e.g. spiral) still pay too much

attention to the things that surround programming

attention to the things that surround programming

The result is that too little effort is spent programming

The result is that too little effort is spent programming

and too much is spent on peripheral things

and too much is spent on peripheral things

The worst thing is that the fear is

The worst thing is that the fear is self-fulfilling,

self-fulfilling,

systems genuinely do get more rigid with time

systems genuinely do get more rigid with time

Nevertheless, the big books contain the experience on

Nevertheless, the big books contain the experience on

which extreme programming is based

which extreme programming is based

It is also based on recent advances in hardware,

It is also based on recent advances in hardware,

software, languages, tools, design and so on

software, languages, tools, design and so on

Avoiding the Fear

In extreme environments, change is not rare

In extreme environments, change is not rare

(waterfall) or infrequent (spiral) but continuous

(waterfall) or infrequent (spiral) but continuous

Extreme programming means achieving a flat cost-of-

Extreme programming means achieving a flat cost-of-

change graph:

change graph:

time

cost of change

The trick is to make it

The trick is to make it

self-fulfilling

self-fulfilling

by choosing the

by choosing the

right combination of techniques

right combination of techniques

XP Practices

The claim of XP is that if you put together some

The claim of XP is that if you put together some

simple practices in the right way, they feed off each

simple practices in the right way, they feed off each

other and produce a system where change is cheap

other and produce a system where change is cheap

You really need to read around to get a good feel for

You really need to read around to get a good feel for

these practices (and the set is not really fixed)

these practices (and the set is not really fixed)

For these notes, we will describe twelve practices, and

For these notes, we will describe twelve practices, and

divide them artificially into three groups

divide them artificially into three groups

programming practices (good for one programmer)

teamwork practices (just pair techniques in this unit)

business practices (not practised in this unit)

What are the XP programming practices?

What are the XP programming practices?

Programming Practices

Testing

Testing

write unit tests before and while you develop

to form the specification, and the proof of completion

Refactoring

Refactoring

change the organisation of the code whenever necessary

to simplify or to make it easy to add the next feature

Simple design

Simple design

what is the simplest thing that could possibly work?

to avoid risking effort on features that never get used

Continuous integration

Continuous integration

build and test the whole project about twice a day

to ensure that the team is all pulling in the same direction

The old way and the new way

The old way (with hand testing)

The old way (with hand testing)

write five lines of code

java Triangle 4 4 4

write five lines of code

java Triangle 5 5 3

write five lines of code

java Triangle 4 4 4

write five lines of code

java Triangle 5 5 3

...main(String[] args) {

test("4 4 4","Equilateral");

test("5 5 3","Isosceles");

run(args[0],args[1],args[2]);

}

...main(String[] args) {

test("4 4 4","Equilateral");

test("5 5 3","Isosceles");

run(args[0],args[1],args[2]);

}

The new way (with auto re-testing)

The new way (with auto re-testing)

JUnit

The JUnit program installed in the department (written

The JUnit program installed in the department (written

by Kent Beck) is tiny, and is based on these ideas

by Kent Beck) is tiny, and is based on these ideas

Each test has to be isolated, so that you don't keep

Each test has to be isolated, so that you don't keep

getting a flurry of false errors

getting a flurry of false errors

Tests must be automatic, so they can be repeated any

Tests must be automatic, so they can be repeated any

time to make sure everything is still working

time to make sure everything is still working

Although tests should be isolated, they are often

Although tests should be isolated, they are often

related, working with the same collection of objects

related, working with the same collection of objects

JUnit allows common setup code to be re-used, but it

JUnit allows common setup code to be re-used, but it

re-creates the common environment afresh for each

re-creates the common environment afresh for each

test to make sure that the tests don't affect each other

test to make sure that the tests don't affect each other

• http://www.cs.bris.ac.uk/Teaching/Resources/General/junit/

http://www.cs.bris.ac.uk/Teaching/Resources/General/junit/

If you don't use it, make sure you use its philosophy

If you don't use it, make sure you use its philosophy

What do you test?

The big books contain lots of good advice; XP says:

The big books contain lots of good advice; XP says:

"Impossible to test everything, suicidal to test nothing"

"Impossible to test everything, suicidal to test nothing"

Tests communicate, so add tests to illustrate things

Tests communicate, so add tests to illustrate things

Test things that you think might break

Test things that you think might break

unusual things that the user might do (black box)

things that might make the code go wrong (white box)

things which isolate bugs (keep the tests after fixing)

Don't test every method, just the ones that are

Don't test every method, just the ones that are

important to users (roughly, don't test private methods

important to users (roughly, don't test private methods

or ones that automatically get tested by calling others)

or ones that automatically get tested by calling others)

Tests must pay off, experience tells you which tests are

Tests must pay off, experience tells you which tests are

more likely to work unexpectedly, or fail unexpectedly

more likely to work unexpectedly, or fail unexpectedly

Refactoring

Programmers are really good at changing their minds

Programmers are really good at changing their minds

and rewriting their programs

and rewriting their programs

The big books frown on it, but XP says it is OK

The big books frown on it, but XP says it is OK

It is called refactoring, which means rewriting or

It is called refactoring, which means rewriting or

rearranging or reorganising or transforming code

rearranging or reorganising or transforming code

The trick is to wait, and do it only when it pays off,

The trick is to wait, and do it only when it pays off,

and do it in small stages, keeping the program working

and do it in small stages, keeping the program working

So you live with what you have until the next stage of

So you live with what you have until the next stage of

development, then decide whether the change is worth

development, then decide whether the change is worth

it to make the next stage easier

it to make the next stage easier

This depends vitally on unit testing, so you know that

This depends vitally on unit testing, so you know that

the changes haven't broken anything

the changes haven't broken anything