EXtreme Programming By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)
-
date post
20-Dec-2015 -
Category
Documents
-
view
219 -
download
0
Transcript of EXtreme Programming By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)
eXtreme ProgrammingeXtreme Programming
By: Aaron Flocke, Leena Paulose, By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)Geetha Krishna (Team 6)
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
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