270 likes | 433 Vues
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
E N D
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 • Successful because it stresses customer satisfaction
XP 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
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
Rules And Practices of XP • Planning • User Stories • Release Planning • Project Velocity • Iterative Development • Move people around • Designing • Simplicity • CRC Cards • Spike Solutions • Refactoring
Rules And Practices of XP • Coding • Standards • Pair Programming • Integration • Collective code ownership • Optimization • Testing • Unit Tests • Acceptance Tests
User 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
Release 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
Project 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
Iterative development • Adds agility to the development process • Iteration length • Constant through out the project • Makes measuring progress • Makes planning reliable and simple
Move 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
Simplicity • Maintain design as simple as possible • Never add functionality before it is scheduled • Extra functionality • slows us down • squanders our resources
CRC Cards • CRC cards are used to represent objects • The class of the card is written at the top • Responsibilities are listed down the left side • Collaborating 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
Refactoring • 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
Pair 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
Rules 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
Coding Practices • Collective Code Ownership • Encourages everyone to contribute new ideas to all the segments of the project • Increase code quality and reduces defects • Spreads knowledge through out the team • Integration • XP teams keep the system fully integrated at all times • Continuous integration avoids or detects compatibility problems early
Testing • 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
Acceptance 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
Acceptance 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
Applications for XP • The VCAPS project at Ford used the unit test framework for both unit tests and acceptance tests
Conclusion • 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
References • www.extremeprogramming.org • www.xpuniverse.com • www.xprogramming.com • www.acs.org.au/certification/Documents/SDVT/SD1_Ass3.pdf