Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer.

Extreme Programming: Practices and Strategies

Extreme Programming Practices and Strategies

Mohammad Alshayebhttp://www.alshayeb.com

Information and Computer Science DepartmentKing Fahd University of Petroleum and Minerals

March (6,13), 2004

2Extreme Programming: Practices and Strategies

Agenda

What is XP?XP PracticesManagement StrategyFacilities StrategyPlanning StrategyDesign StrategyDevelopment StrategyTesting StrategyWhen to use XP?


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

Kent Beck, Extreme Programming Explained 2000

Open space.

Tables in the middle of the space.

Cubbies around the outside of the space.

A room with a nice view -if possible.

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: User Stories

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

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

Much simpler format than traditional requirements specifications:

3 sentences written by customers.

Non-technical terminology.


Planning -Story Card

Kent Beck, 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.


Story Breakdown

Iterations assigned for the development of each story

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 1


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 3

Integrate into the system

Passed

Test Case 2Test Case 1

Task 3Task 2Task 1

One iteration Development of one user story


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 designOne 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 ownershipEncourages 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.


40 hour weekProjects 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

Individuals (mean)

Teams (mean)

Readability 1.4 2.0

Functionality 4.2 5.6

Score 5.6 7.6

Confidence 3.8 6.5

Enjoy 4.0 6.6

Time 42.6 30.2

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.


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 integrationOne 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 testsUser 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 availabilityOn site customer.

DutiesWrite 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.

Short-term projects.

Input by customers and managers.

Testability.


Companies That Use XP

Thought works.

Acxiom.

Chrysler.

Knowledge management software.

Andrena objects.

EuropeLoan bank.

Evant solutions.

Workshare technology.


References

“Extreme Programming Explained: Embrace Change,” by Kent Beck “Planning Extreme Programming,” by Kent Beck, Martin Fowler“Extreme Programming Installed,” by 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?

Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer.

Documents