Extreme Programming (XP)

Web Applications and Services

Agenda

Software Processes What is XP? XP Practices Management Strategy Facilities Strategy Planning Strategy Design Strategy Development Strategy Testing Strategy When to use XP?

Software Processes

What is a software process? Major models:

• The Waterfall model.

• The Iterative (Incremental) model.

An example of a new iterative software process: Extreme Programming (XP).

Waterfall Model Structure

Analysis

Design

Code

Test

Iterative Model Structure

Analysis

Design

Code

Test

System Complete?

Operation and Maintenance No Deliver Increment Yes Deliver System

What is XP?

“XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software”. -Kent Beck

XP is Different

Early, concrete, and continuous feedback from short-cycles. Incremental planning approach. Flexibility of scheduling the implementation based on

changing business needs. Reliance on tests written by the programmers. Reliance on the collaboration of programmers.

Software Processes

Analysis

Design

Code

Test

Waterfall Iterative XP

Kent Beck 1999

XP Practices

Planning game. Small releases. Simple design. Testing. Refactoring. Coding standards.

Pair programming. Collective ownership. On-site customer. 40-hour week. Open workspace. Continuous integration.

Management Strategy

Be available as a development partner. See long term refactoring goals. Help programmers with individual

technical skills like testing and refactoring.

Explain the process to upper level managers.

Keep track with software metrics.

Management Strategy- Meeting

Daily Stand-up Meeting • Entire team

• Problems.

• Solutions.

• Stand in a circle

• Avoid long discussions.

• No side conversations.

Summary of Management Strategy

Coach: help, plan and manage. Track software metrics. Daily stand-up meeting.

Facilities Strategy

Open space. Tables in the middle of the space. Cubbies around the outside of the space. A room with a nice view -if possible.

Extreme Programming Explained 2000

The DaimlerChrysler C3 work area

Planning Strategy- Guidelines

Only plan -in details- for the next release. Accepted responsibility. The person responsible for implementation gets to

estimate. Planning for priorities vs. planning for development.

Planning: User Stories

User stories are written by the customers – features the system needs to do-

Much simpler format than traditional requirements specifications:

• 3 sentences written by customers.

• Non-technical terminology.

KEY: Stories that are most valuable to the customer are developed first.

Planning -Story Card

Extreme Programming Explained 2000

Planning: Iterations

Developers give each user story an estimate of 1, 2, or 3 weeks.

Stories are then organized in order of importance to the customer.

The development schedule is divided into iterations of 1 to 3 weeks in length based on the user stories.

Planning: Releases

Releases are iterative versions of the system released by the development team to the customers.

• Released at the end of iteration.

• An integrated working system.

• Includes the latest successfully implemented, integrated, and tested story from that iteration.

Customer System

Priority Organization of user stories

Release 1 Release 2 Release 3

Story 1 Story 2 Story 3

Division of system into user stories

Iteration 1 Iteration 2 Iteration 3

Story 2 Story 3 Story 1Iterations assigned for the development of each story

Working, tested system with story 2 integrated

Iteration Breakdown

Each iteration is broken down into programming tasks for developing the user story of that iteration.

Each task is 1-3 days in duration. Each programming pair choose a task (or more). The programming pair then design test cases and

implement them.

Iteration Breakdown

Test Case 1 Test Case 2 Test Case 3

Task 1 Task 2 Task 3

One iterationDevelopment ofone user story

Integrate into the system

Passed

Summary of XP Planning

User Stories

Priorities

Iterations Releases

Tasks

Test Cases

Design Strategy -Rules

Always do the simplest thing that could possibly work. Use CRC cards for design

• One card per object.

Design Strategy -Rules

Never add functionality early.“Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time”

“Concentrate on what is scheduled for today only”

ExtremeProgramming.org Refactor: replace anything complex with something

simpler.• Remove redundancy.

• Eliminate unused functionality.

• Enhance efficiency.

Summary of Design Rules

The goal is simple code on time so:• Keep things simple and clean.

• Refactor.

• Stick to the planned schedule.

Development Strategy -Guidelines

Collective code ownership• Encourages all programmers to contribute to all segments of the

project.

Coding standards • Consistency saves time and money.

• Makes it easier for the entire team to code and refactor.

Development Strategy -Guidelines

Write the test case before the code. Continuous integration. 40 hour week

• Projects requiring overtime will be late anyway.

• Avoid overtime.

Pair programming.

Pair Programming

Two brains are better than one. Pairs consider more possible solutions to a problem. Design alternatives increase.

Pair Programming

7.65.6Score

6.64.0Enjoy

30.242.6Time

6.53.8Confidence

5.64.2Functionality

2.01.4Readability

Teams (mean)Individuals (mean)

John Nosek, “The Case for Collaborative Programming,” Communications of the ACM, March 1998, Vol. 41, No. 3 pp. 105-108.

Summary of Development Strategy

Write the test case before the code. Collective code ownership. Coding standards. Continuous integration. Pair programming. 40 hour week.

Testing Strategy –Unit Testing

Unit testing (test cases)• Programmers write their own unit tests

• Create tests BEFORE the code.

• Programmers implement one unit test at a time.

• After 100% of unit tests are passed, that unit can be integrated.

• During integration, all previous tests are run to verify the overall system still runs.

Testing Strategy -Integration

Code integration• One pair at a time.

• Prevents problems introduced when integrating modules.

• Maintain a latest version.

• Allows for parallel coding.

• Integrate often.

Testing Strategy -Acceptance Test

Acceptance tests• User stories are the basis for acceptance testing.

• Black box testing.

Summary of Testing

Pair

Programming

Continuous

Integration

100% Unit

Tests Passed

Acceptance

Tests Passed

Create Unit Test

Failed

Passed

End of Task

Run all unit tests

ExtremeProgramming.org

Customers

Customer availability• On site customer.

Duties• Write stories.

• Define the priorities of the stories.

• Define the scope or timing of releases.

XP Favorable Conditions

Dynamically changing requirements and functionality. Small groups of programmers 2-12. Input by customers and managers. Testability.

XP is against “BigDesignUpFront”

The Code is the Design “When the original phases of software development were laid down, they were just plain wrong.

Requirements, Design, Implementation, and Test are not what we think they are. Design is not something that you do only before you code. Implementation is not the act of coding. We can see this if we look realistically at what they are in other engineering disciplines.”

"The final goal of any engineering activity is to create some kind of documentation.” “After reviewing the software development lifecycle today, it appears that the only

software documentation that actually seems to satisfy the criteria of an engineering design are the source code listings. “

XP is often accused of not believing in comments. That’s not exactly true.• They do believe heavily in “Self-documenting code”

• But they also believe “The position of the article was not that source code makes all other documentation obsolete, it is simply that the act of programming is designing.”

Ward Cunningham On Comments

We comment methods only after doing everything possible to make the method not need a comment.

We prefer to clarify the code directly over putting in an explanation of what the code could say it if were better done.

• We have written "literate programs", cf DonKnuth, and no one has used them. Too bad, really, they were cool.

Can this really work?

There are several Fortune 500 companies that are now using XP, including Ford, Daimler-Chrysler, and First Union.

But it only works ALL TOGETHER. “AlmostXP is like being AlmostAlive or AlmostSolvent.”

• The emphasis on readable code (even without comments) works because Pair Programming ensures readable code

• The integrating constantly is made possible by the Unit Tests

• The lack of up-front design effort works because the User is on-site, the user stories drive the effort, and there’s a high degree of communication among the team members

XP Path

XP Development

XP Collective Code Ownership

Lessons Learned

Companies That Use XP

Knowledge management software. Chrysler. Thought works. Andrena objects. EuropeLoan bank. Evant solutions. Acxiom. Workshare technology.

References

Extreme Programming Explained: Embrace Changeby Kent Beck

Planning Extreme Programmingby Kent Beck, Martin Fowler

Extreme Programming Installedby Ron Jeffries, Ann Anderson, Chet Hendrickson, Kent Beck, Ronald E. Jeffries

Extreme Programming in Practice, by James W. Newkirk, Robert C. Martin

Extreme Programming Examined by Giancarlo Succi, Michele Marchesi

Websites

www.extremeprogramming.org www.xprogramming.com www.pairprogramming.com www.xp123.com

Questions?