extreme programming n.
Skip this Video
Loading SlideShow in 5 Seconds..
Extreme Programming PowerPoint Presentation
Download Presentation
Extreme Programming

Extreme Programming

124 Vues Download Presentation
Télécharger la présentation

Extreme Programming

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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