Extreme Programming

25
Extreme Programming Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi

description

Extreme Programming. Team Members Gowri Devi Yalamanchi Sandhya Ravi. Introduction. A deliberate and disciplined approach to software development Proven at cost conscious companies like Credit Swiss Life, Daimler Chrysler, First Union National Bank, Ford Motor Company and UBS - PowerPoint PPT Presentation

Transcript of Extreme Programming

Page 1: Extreme Programming

Extreme ProgrammingExtreme Programming

Team Members

Gowri Devi Yalamanchi

Sandhya Ravi

Page 2: Extreme Programming

IntroductionIntroduction

• A deliberate and disciplined approach to software development

• Proven at cost conscious companies like Credit Swiss Life, Daimler Chrysler, First Union National Bank, Ford Motor Company and UBS

• Successful because it stresses customer satisfaction

Page 3: Extreme Programming

XP MethodologyXP Methodology

• Designed to deliver the software your customer needs when it is needed

• Empowers your developers to confidently respond to changing customer requirements, even late in the life cycle

• Emphasizes team work• Improves a software project in four essential ways:

Communication Simplicity Feedback Courage

Page 4: Extreme Programming

When should XP be Used?When should XP be Used?

• In software environments where requirements change dynamically

• In projects with high risk• In projects with a small team of programmers• In situations where system design allows for

automated unit and functional tests

Page 5: Extreme Programming

Rules And Practices of XPRules And Practices of XP

• Planning User Stories Release Planning Project Velocity Iterative Development Move people around

• Designing Simplicity CRC Cards Spike Solutions Refactoring

Page 6: Extreme Programming

Rules And Practices of XPRules And Practices of XP

• Coding Standards Pair Programming Integration Collective code ownership Optimization

• Testing Unit Tests Acceptance Tests

Page 7: Extreme Programming

User StoriesUser Stories

• Written by customers as things that the system needs to do for them

• Similar to usage scenarios• Used to create time estimates for release planning

meeting• Used instead of a large requirements document• Lead to creation of acceptance tests

Page 8: Extreme Programming

Release PlanningRelease Planning

• Follows a set of rules that allows everyone involved with the project to make their own decisions

• Technical people make technical decisions and business people make the business decisions

• Negotiates a schedule everyone can commit to• Quantified by the four variables:

Scope Resources Time Quality

Page 9: Extreme Programming

Project velocityProject velocity

• Measure of how much work is getting done on your project

• Determined by simply adding up the estimates of the user stories as well as the tasks that were finished during the iteration

• Increased by allowing developers to ask the customers for another story when their work is completed

Page 10: Extreme Programming

Iterative developmentIterative development

• Adds agility to the development process• Iteration length

Constant through out the project Makes measuring progressMakes planning reliable and simple

Page 11: Extreme Programming

Move people aroundMove people around

• Cross training is often an important consideration in companies trying to avoid islands of knowledge, which are so susceptible to loss

• Avoids serious knowledge loss and coding bottle necks

• Achieved by moving people around the code base in combination with pair programming

Page 12: Extreme Programming

XP MAPXP MAP

Page 13: Extreme Programming

SimplicitySimplicity

• Maintain design as simple as possible • Never add functionality before it is scheduled• Extra functionality

slows us down squanders our resources

 

Page 14: Extreme Programming

CCRC CardsRC Cards

• CRC cards are used to represent objectsThe class of the card is written at the topResponsibilities are listed down the left sideCollaborating classes are listed to the right of each

responsibility• Allows people to break away from the procedural

mode of thought and more fully appreciate object technology

• Allows entire project teams to contribute to the design

Page 15: Extreme Programming

RefactoringRefactoring

• Removes redundancy• Eliminates unused functionality• Rejuvenates obsolete designs• Saves time and increases quality• Can be achieved by

Keeping the design simple Keeping your code clean and concise so it is

easier to understand, modify and extend

Page 16: Extreme Programming

Pair programmingPair programming

• All code to be included in a production release is created by two people working together at a single computer

• Increases software quality without impacting time to deliver

• Add as much functionality as two working separately except that it will be much higher in quality

• With increased quality comes big savings later in the project

Page 17: Extreme Programming

Rules Of ThumbRules Of Thumb

• Never pair two people together who are brand new to programming in pairs (always one old-timer with a newcomer)

• When a pair takes the option of working separately (but with joint responsibility), they are not really pair programming

• If both people can not see what is happening on the monitor, they are not really pair programming

• Everyone works in a pair (no lone rangers allowed) • People have to trust each other, and it may take time

to build trust among everyone on the team

Page 18: Extreme Programming

Coding PracticesCoding Practices

• Collective Code OwnershipEncourages everyone to contribute new ideas to

all the segments of the project Increase code quality and reduces defectsSpreads knowledge through out the team

• IntegrationXP teams keep the system fully integrated at all

timesContinuous integration avoids or detects

compatibility problems early

Page 19: Extreme Programming

XP Flow ChartXP Flow Chart

Page 20: Extreme Programming

TestingTesting

• All code must have unit tests• All code must pass all unit tests before it can be

released• When a bug is found tests are created

Page 21: Extreme Programming

Acceptance TestingAcceptance Testing

• Acceptance tests are created from user stories• A story can have one or many acceptance tests, what

ever it takes to ensure the functionality works• These are black box system tests• Represents some expected result from the system• Used as regression tests prior to a production release

Page 22: Extreme Programming

AcceptanceAcceptance Testing Testing

• Quality assurance (QA) is an essential part of the XP process

• XP requires development to have much closer relationship with QA

• Acceptance tests should be automated so they can be run often

• The acceptance test score is published to the team• The goal of acceptance tests is to guarantee that a

customers requirements have been met and the system is acceptable

Page 23: Extreme Programming

Applications for XPApplications for XP

• The VCAPS project at Ford used the unit test framework for both unit tests and acceptance tests

Page 24: Extreme Programming

ConclusionConclusion

• Extreme Programming tries to make things happen in ways that people find natural and pleasant

• Focuses on effective forms of communication• Works by bringing the whole team together with

enough feedback to tune the practices of the team to their unique situation

Page 25: Extreme Programming

ReferencesReferences

• www.extremeprogramming.org• www.xpuniverse.com• www.xprogramming.com• www.acs.org.au/certification/Documents/SDVT/

SD1_Ass3.pdf