1. Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi

2. 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

3. 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

4. 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

5. Rules And Practices of XP Planning  User Stories  Release Planning  Project Velocity  Iterative Development  Move people around Designing  Simplicity  CRC Cards  Spike Solutions  Refactoring

6. Rules And Practices of XP Coding  Standards  Pair Programming  Integration  Collective code ownership  Optimization Testing  Unit Tests  Acceptance Tests

7. 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

8. 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

9. 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

10. Iterative development Adds agility to the development process Iteration length  Constant through out the project  Makes measuring progress  Makes planning reliable and simple

11. 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

12. XP MAP

13. Simplicity Maintain design as simple as possible Never add functionality before it is scheduled Extra functionality  slows us down  squanders our resources

14. 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

15. 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

16. 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

17. 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

18. 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

19. XP Flow Chart

20. 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

21. 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

22. Acceptance Testing 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

23. Applications for XP The VCAPS project at Ford used the unit test framework for both unit tests and acceptance tests

24. 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

25. References www.extremeprogramming.org www.xpuniverse.com www.xprogramming.com www.acs.org.au/certification/Documents/SDVT/SD1_ Ass3.pdf