Xp presentation 2003

19
eXtreme Programming A lightweight development process for small to medium-sized projects (an Agile Process) by Shahid N. Shah

Transcript of Xp presentation 2003

Page 1: Xp presentation 2003

eXtreme Programming

A lightweight development process for small to medium-sized

projects (an Agile Process)

by Shahid N. Shah

Page 2: Xp presentation 2003

Slide 2 of 18

Sampling of Available Methodolgies

Waterfall*

Extreme Programming

Crystal Family (Alistair Cockburn)

Open Source

Adaptive Software Development (Jim Highsmith)

SCRUM

Feature Driven Development (FDD, Jeff De Luca and Peter Coad)

Dynamic System Development Method (DSDM, $$)

Rational Unified Process ($$)*

* Non-agile

Page 3: Xp presentation 2003

Slide 3 of 18

XP Philosophy

Always ask yourself: “what is the simplest thing that could possibly work?” -- Kent Beck, XP Creator

Never do any more coding, more testing, more process, or more documentation than is absolutely necessary to delight the customer.

Main values: Communication, Feedback, Simplicity, and Courage

Formalize and do what has been known by “smart guys” for years

Not a “license to hack”!

Page 4: Xp presentation 2003

Slide 4 of 18

XP Key Practices

Adaptive, not predictiveThe Planning Game -- Quick, up-date as needed, 80/20 rule, push out what doesn’t need to be immediately decidedSmall releases -- Get simple system into production quickly, add features in small releasesSimple design -- Design as simple as possibleRefactoring -- Continuously restructure to simplify, remove duplication40 hour weekOn-site customer -- collective ownershipTravel light -- No more documentation than needed to support deployment of application

Page 5: Xp presentation 2003

Slide 5 of 18

Customer’s bill of rights

To set objectives for the project and have them followed.

To know how long the software project will take and how much it will cost.

To decide which features are in and which are out of the software.

To know the project’s status.

To make reasonable changes to requirements throughout the course of the project and to know the costs of making these changes.

To be apprised regularly of risks that could affect cost, schedule or quality.

To have ready access to project deliverables throughout the project.

Page 6: Xp presentation 2003

Slide 6 of 18

Developer’s Bill of Rights

To know the project objectives and to be able to clarify priorities.

To know in detail what product I’m supposed to build.

To have ready access to the customer, manager, marketer, or other person responsible for the functionality.

To work each phase of the project in a technically responsible way.

To approve effort and schedule estimates for any work that I will be asked to perform.

To have my project’s status reported accurately to customers and upper management.

To work in a productive environment free from frequent interruptions.

Page 7: Xp presentation 2003

Slide 7 of 18

Benefits of XP

Software stays soft

Handles changing requirements with relative ease

Quickly produces something useful, keeps making useful enhancements -- delivery is provided when customer is ready

Average developers can produce great software

Page 8: Xp presentation 2003

Slide 8 of 18

Prerequisites

Flexible Project Management

Goal is to delight customers and not to maintain process (though they are not mutually exclusive)

Groups that can talk to each other

Close contact with users

Page 9: Xp presentation 2003

Slide 9 of 18

Obvious things to do

Staged Deliverycontinuous stream of value feedbackadapt to change

Business people make business decisions and technical people make technical decisions

Regression testing, unit tests

Review designs and code

Page 10: Xp presentation 2003

Slide 10 of 18

Extreme Programming

Analysis

Test

Code

Design

Project Management

Page 11: Xp presentation 2003

Slide 11 of 18

Extreme Analysis

Describe system as a set of user stories (storyboards)

Users write stories explaining one use of the system (explain by example)

Like use cases, but informal (no special tools are needed)

Realize that all artifacts created during design will rarely be updated after implementation

Page 12: Xp presentation 2003

Slide 12 of 18

Extreme Testing

Write tests before code unit tests before each class end-to-end tests before any classes

Convert each user story into a set of tests All unit tests must run 100% all the time

Don’t worry if you can’t test everything GUI real-time I/O complete coverage

Don’t worry if testing is expensive

Page 13: Xp presentation 2003

Slide 13 of 18

Extreme Coding

Eliminate code in favor of configurationWrite code for test cases one at a timeWrite the simplest thing that could possibly work Goal: make the tests work ASAP

write new classes use/change old classes copy code add if statements

Enforce coding standards

Page 14: Xp presentation 2003

Slide 14 of 18

Pair Programming

All code is written in pairs

Pairs talk continually

Pair switches driver frequently

People switch pairs several times a day

Continuous code review

Page 15: Xp presentation 2003

Slide 15 of 18

Refactoring:Extreme Design

Make sure each thing is done in one place - eliminate all duplicate code

Make sure each class/function does one thing

All code must be readable

All tests run

Page 16: Xp presentation 2003

Slide 16 of 18

Extreme Design

Project starts with a few days of design on white-boards/CRC cards

Major problems lead to group design sessions (servers, objects, etc)

Documentation is after the fact, and no more than necessary

Start simple, refactor to keep simple

Page 17: Xp presentation 2003

Slide 17 of 18

Extreme Scheduling

Customer write stories

Developers estimate cost

Customer decides which to do next

Group a few weeks worth of stories into an iteration

Developers implement stories one at a time until iteration is finished

Page 18: Xp presentation 2003

Slide 18 of 18

What is Extreme?

Extreme, but not unusual user stories, schedule negotiation, staged

delivery, testing, simplicity

Extreme and unusual pair programming continuous refactoring

Page 19: Xp presentation 2003

Slide 19 of 18

Conclusion

Produce consistently better applications with fewer people (or less qualified people), in less time, with higher quality and significantly lower overall cost.