xp- extreme programming

1

XP- eXtreme Programming

Amit Shabtay

2

Software Development Process SDP is essentially composed of:

•Requirements->  Design-> Implementation->      Testing-> Documentation-> Maintenance

However, this is not descriptive enough.

Different organizations have different requirements for their processes, so there is not one "correct" process

3

Development Methodologies The Software Crisis

•84% of software projects are not on time•31% of software projects never complete•Most software is buggy, unstable and insecure•Lack of repeatability (engineering)

eXtreme Programming•For small projects: up to 12 people, 100 stories

Rational Unified Process•For large projects: a “heavy-weight” process•A commercial product

4

Rational Unified Process By Rational, see

http://www-306.ibm.com/software/awdtools/rup/

Decompose large system to sub-systems•A team and development effort per system•Architects team does overall design, sharing

Five stages of each system’s life cycle•Business modeling, Requirements, Analysis & Design,

Implementation, Test•Many artifacts are not code or tests

Iterative Development Highly managed, highly automated process

5

The RUP platform includes Tools for configuring RUP for a project’s

specific needs. Tools for developing your own internal

knowledge into process components Customizable Web-based deployment

tools Online community for exchanging best

practices.

6

eXtreme Programming By Kent Beck, see XProgramming.com Embrace change Simplicity Customer involvement & rapid

feedback Incremental pay-as-you-go design Test-first programming

7

The 12 XP Principles (I) Planning Game Simple Design On-Site Customer Pair Programming Testing Continuous Integration

8

The 12 XP Principles (II) Small Releases Collective Ownership Coding Standard Metaphor 40-Hour Week Refactoring

9

Planning Game, Simple Design XP planning addresses two key questions

in software development:•Predicting what will be accomplished at due date.•Determining what to do next (picking stories).

This is done every two weeks or so. It provide steering control in the hands of

the customer. Design is kept simple design, knowing that

in the next iterations it may change.

10

On-Site Customer In a team, there exists a “customer”.

He is the business representative.

He provides the requirements, sets priorities and steers the project.

11

Pair Programming I Two Programmers sit at one workstation They take turns “driving” Pairs are short lived Pairing transmits knowledge to the team Pairing train newbies

12

Pair Programming II Laurie Williams,

•http://collaboration.csc.ncsu.edu/laurie/ Findings:

•Pairs use no more manhours than singles.

•Pairs create fewer defects.•Pairs create fewer lines of code.•Pairs enjoy their work more.

13

Testing•Write a test case.•Write the code that passes it.•Repeat until program does what you want.

It shows that the tested framework is functioning properly.

It also gives a working base to continue from.

We move, in tiny steps, from working base, to working base.

14

Continuous Integration Build, end to end, at every check in. Check in frequently. Put resources on speeding build

time. Put resources on speeding test

time.

15

Small Releases First, the team releases running, tested

software, delivering business value chosen by the Customer, every iteration •The customer can use it for evaluation or

even release to end users

Second, XP teams release to their end users frequently as well. XP Web projects release as often as daily

16

Collective Ownership, Coding Standard All the contributors to an XP project sit together,

members of one team, including the customer. There is no exclusive role of just one individual

(except the customer)

On an Extreme Programming project, any pair of programmers can improve any code at any time.

Because of that, it is important to keep identical code standards.

17

Metaphor To keep a common vision of how the program

works, the team can define a “metaphor” for the project.

“This program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system.

The metaphor Extreme Programming (XP) uses to describe software development is of driving a car- always in a need for steering.

18

40-Hour Week Extreme Programming teams are in it

for the long term.

To get a quality work, you need to treat the team as human beings.

19

Refactoring Improving the design of existing code,

without changing its observable behavior

"Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow." Kent Beck

20

Necessity

21

When?

When to refactor•Before adding functionality•Before fixing a bug•During code review

When not to refactor•During adding functionality•During fixing a bug•No good set of unit tests•Small programs (usually)

22

Code Smells “If it stinks, change it”

•Duplicate code•Switch statements•Long method•Data class•Long parameter list•Primitive obsession•Temporary field•…

23

For Conclusion eXtreme programming is all about:

•Fanatic testing•Preparing for unknown changes•Keeping it simple.

It is not always the best development process to choose- it must meet some requirements.