eXtreme ProgrammingeXtreme Programming

By: Aaron Flocke, Leena Paulose, By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)Geetha Krishna (Team 6)

What is XP?What is XP?

XP is…XP is…

A set of rules\principles\practices used to A set of rules\principles\practices used to rapidly develop high-quality softwarerapidly develop high-quality software Tools not Rules -Ron JeffriesTools not Rules -Ron Jeffries

One of the more prominent lightweight One of the more prominent lightweight software-engineering methodologiessoftware-engineering methodologies

Main Goal: Customer SatisfactionMain Goal: Customer Satisfaction Highest quality in Lowest time frame.Highest quality in Lowest time frame.

XP emphasizes:XP emphasizes:

CommunicationCommunication SimplicitySimplicity FeedbackFeedback CourageCourage

……Using 12 main principles, including:Using 12 main principles, including:Comprehensive unit testsComprehensive unit testsShort release cyclesShort release cyclesAdding only what’s needed for the current taskAdding only what’s needed for the current taskCollective code ownershipCollective code ownershipPair programmingPair programming

Where did XP come from?Where did XP come from?

““Father of XP”: Kent BeckFather of XP”: Kent Beck Wrote “Extreme Programming Explained: Wrote “Extreme Programming Explained:

Embracing Change”Embracing Change” Had years of experience in OOP such as Had years of experience in OOP such as

Small Talk (at time of xP creation)Small Talk (at time of xP creation)

Ward CunninghamWard Cunningham

Ron Jeffries…Ron Jeffries…

It all started…It all started…

Kent Beck developed XP back in 1996 while Kent Beck developed XP back in 1996 while working at Daimler Chryslerworking at Daimler ChryslerIts use in developing the payroll system for D.C. Its use in developing the payroll system for D.C. is considered one of the great XP success is considered one of the great XP success stories. stories.

Pros/Cons of XPPros/Cons of XP

Pros:Pros: Handles changing requirements wellHandles changing requirements well Maximizes quality while minimizing timeMaximizes quality while minimizing time

ConsCons Only works well with small groups (around a Only works well with small groups (around a

dozen)dozen) Many people dislike Pair Programming and Many people dislike Pair Programming and

think of it as overkill and a waste of resourcesthink of it as overkill and a waste of resources

A more in depth look ->A more in depth look ->

And now my associates will give you all a more And now my associates will give you all a more in depth look at XP so you can decide for in depth look at XP so you can decide for yourself how useful or worthless XP is…yourself how useful or worthless XP is…

Extreme RolesExtreme Roles

CustomerCustomer writes & explains user storieswrites & explains user stories sets priorities, specifies testssets priorities, specifies tests may or may not be an end-usermay or may not be an end-user

ProgrammerProgrammer estimates storiesestimates stories defines tasks from storiesdefines tasks from stories implements stories and unit implements stories and unit

teststests

TrackerTracker monitors progressmonitors progress keeps track of schedulekeeps track of schedule

CoachCoach guides & mentors the teamguides & mentors the team watches the progresswatches the progress

Extreme Roles Extreme Roles (contd.)(contd.)

TesterTester runs functional tests runs functional tests makes sure people know when makes sure people know when

test results decline.test results decline.

DoomsayerDoomsayer ensures that everybody knows ensures that everybody knows

the risks involvedthe risks involved ensures that bad news isn't ensures that bad news isn't

hidden, glossed over, or blown hidden, glossed over, or blown out of proportionout of proportion

ManagerManager schedules meetings, passes schedules meetings, passes

results to trackerresults to tracker responsible to the Gold Owner.responsible to the Gold Owner.

Gold OwnerGold Owner the person funding the projectthe person funding the project may or may not be the same as may or may not be the same as

the Customerthe Customer

Extreme PracticesExtreme Practices

The Planning ProcessThe Planning Process

Simple DesignSimple Design

System MetaphorSystem Metaphor

Frequent, Small ReleasesFrequent, Small Releases

On-site CustomerOn-site Customer

40 hr weeks40 hr weeks

Pair ProgrammingPair Programming

RefactoringRefactoring

Test Driven Development Test Driven Development

Collective Code Collective Code OwnershipOwnership

Continuous IntegrationContinuous Integration

Coding StandardCoding Standard

The 12 Golden Rules

XP Practice CycleXP Practice Cycle

The Planning ProcessThe Planning Process defines desired features brieflydefines desired features briefly describes each feature's business value and prioritydescribes each feature's business value and priority helps estimate project costhelps estimate project cost

Simple DesignSimple Design the best design is the easiest one that worksthe best design is the easiest one that works a correct design must have: a correct design must have:

no duplicate codeno duplicate code fewest possible classes and methodsfewest possible classes and methods

meets the business value and expected functionalitymeets the business value and expected functionality

System MetaphorSystem Metaphor provide a broad view of the project’s goalprovide a broad view of the project’s goal describes how the describes how the system should work, its functionalitysystem should work, its functionality defines the overall theme to which developers and clients can relatedefines the overall theme to which developers and clients can relate

XP PracticesXP Practices

XP PracticesXP Practices

Frequent, Small ReleasesFrequent, Small Releases develop and deliver the application in a series of frequently updated versions. develop and deliver the application in a series of frequently updated versions. provides frequent feedbackprovides frequent feedback

On-site CustomerOn-site Customer integral part of the development effort. integral part of the development effort. must be available at all times to set priorities, deliver must be available at all times to set priorities, deliver and establish requirements, and answer questions.and establish requirements, and answer questions.

Sustainable Pace / 40 hr weeksSustainable Pace / 40 hr weeks avoid overtimeavoid overtime re-examine schedulere-examine schedule rested programmers = fewer mistakesrested programmers = fewer mistakes

Pair ProgrammingPair Programming all code is written in pairsall code is written in pairs

programmer and observerprogrammer and observer

code is simplercode is simpler

less defects foundless defects found

continuous code reviewcontinuous code review

software quality increasessoftware quality increases

increases learningincreases learning

every programmer knows all every programmer knows all aspectsaspects

RefactoringRefactoring

Refactoring is the process of changing a software system in such aRefactoring is the process of changing a software system in such away that it does not alter the external behavior of the code yet way that it does not alter the external behavior of the code yet improves its internal structureimproves its internal structure

The aim of refactoring is toThe aim of refactoring is to :: constantly reviseconstantly revise make the design simplermake the design simpler make the code more understandablemake the code more understandable improve the tolerance of code to changeimprove the tolerance of code to change remove duplication,remove duplication, improve communication & add flexibilityimprove communication & add flexibility

Change it even if it is not broken!Change it even if it is not broken!

XP Practices XP Practices (contd.)(contd.)

Collective Code OwnershipCollective Code Ownership code belongs to the teamcode belongs to the team encourages team to work closerencourages team to work closer everybody tries to produce a high-quality systemeverybody tries to produce a high-quality system

Test Driven DevelopmentTest Driven Development plays central role in XPplays central role in XP each block is tested thoroughlyeach block is tested thoroughly 2 kinds - acceptance and unit test2 kinds - acceptance and unit test

Continuous IntegrationContinuous Integration immediate integrationimmediate integration new system must pass all testsnew system must pass all tests

Coding StandardCoding Standard ccommon namommon naminging && formatting formatting schemes schemes makemakess pair progamming and collective code ownership easier pair progamming and collective code ownership easier rapid code sharing & reduces the learning curverapid code sharing & reduces the learning curve

XP Project - PhasesXP Project - Phases

User Stories

Spike

Release Planning

Requirements

Iteration Acceptance Tests

Small Releases

Release Plan

Latest Version

Customer Approval

Bugs Next Iteration

Test Scenarios

Exploration Phase

Planning Phase

Iteration Phase

Production Phase

Stages of an XP ProjectStages of an XP Project

InitiationInitiation

Use storiesUse stories

Spike solutionsSpike solutions

Release PlanningRelease Planning

ReleaseRelease Iteration 1Iteration 1

DevelopmentDevelopmentDeploymentDeploymentAcceptance TestingAcceptance Testing

Iteration 2Iteration 2DevelopmentDevelopmentDeploymentDeploymentAcceptance TestingAcceptance Testing

..

.. Iteration nIteration n

User StoriesUser Stories

Short Description of the behavior of the systemShort Description of the behavior of the system

Customer’s point of viewCustomer’s point of view

Customer terminology – no technical termsCustomer terminology – no technical terms

One for each major feature of the systemOne for each major feature of the system

Create low-risk time estimates for the projectCreate low-risk time estimates for the project

Similar to Requirements Documents but not the sameSimilar to Requirements Documents but not the same

Different from Use Cases – written by user, not programmerDifferent from Use Cases – written by user, not programmer

Average implementation time ( 2-3 weeks)Average implementation time ( 2-3 weeks)

80 +/- 20 stories – sufficient to create a release plan.80 +/- 20 stories – sufficient to create a release plan.

Printed on cards, similar to CRC cards.Printed on cards, similar to CRC cards.

Spike SolutionSpike Solution

Simple programsSimple programs

Explore solutions for tough technical / design problemsExplore solutions for tough technical / design problems

Address only the problem under considerationAddress only the problem under consideration

Ignore other concernsIgnore other concerns

If not good – throw awayIf not good – throw away

Release PlanningRelease Planning

Create release plan for the whole project ( 1-6 months )Create release plan for the whole project ( 1-6 months )

Programmer provides estimates of 1,2 or 3 points for each storyProgrammer provides estimates of 1,2 or 3 points for each story

Customer decides which stories should be included in the releaseCustomer decides which stories should be included in the release

Customer decides the priorities of the storiesCustomer decides the priorities of the stories

Stories chosen for the release are arranged in 1-3 week iterationStories chosen for the release are arranged in 1-3 week iteration

High risk/high priority stories – earlier iterationHigh risk/high priority stories – earlier iteration

Release and iteration dates are fixed.Release and iteration dates are fixed.

IterationIteration

Iteration planning meeting-beginning of each iterationIteration planning meeting-beginning of each iteration

Each iteration – 1-3 weeksEach iteration – 1-3 weeks

For each iteration, user stories and failed tests are chosenFor each iteration, user stories and failed tests are chosen

Programmers break stories into tasksProgrammers break stories into tasks

Programmers sign up for tasks and estimate time neededProgrammers sign up for tasks and estimate time needed

Programmers have a limitation on the task they can sign up forProgrammers have a limitation on the task they can sign up for

Can only sign up for as many points as were completed in the last Can only sign up for as many points as were completed in the last iterationiteration

If the iteration is too long, Customer chooses stories to be put off for If the iteration is too long, Customer chooses stories to be put off for later iterations – called ‘Snow Plowing’later iterations – called ‘Snow Plowing’

If iteration is too short, extra stories are added.If iteration is too short, extra stories are added.

Acceptance TestsAcceptance Tests

Same as Functional Tests – determines if the system is acceptableSame as Functional Tests – determines if the system is acceptable

‘‘Test First’ Principle – Tests are written first and then code is written Test First’ Principle – Tests are written first and then code is written to pass the testto pass the test

No code goes into production without an associated testNo code goes into production without an associated test

Tests determine what code to writeTests determine what code to write

Customers specify the conditions to be testedCustomers specify the conditions to be tested

These conditions are taken from user storiesThese conditions are taken from user stories

For each user story, there can be 1 or more testsFor each user story, there can be 1 or more tests

Test scores are published to the customers and programmersTest scores are published to the customers and programmers

Failed tests become part of the next iterationFailed tests become part of the next iteration