1 / 51

Extreme Programming

Extreme Programming. C Sc 335 November, 28 2005. Overview. Essence of Extreme Programming (XP) Variables Values Principles Practices. Waterfall Model. Waterfall was described by 1970 by W. W. Royce Understood as finish each phase don’t proceed till done Royce criticized this

tamma
Download Presentation

Extreme Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Extreme Programming C Sc 335 November, 28 2005

  2. Overview • Essence of Extreme Programming (XP) • Variables • Values • Principles • Practices

  3. Waterfall Model • Waterfall was described by 1970 by W. W. Royce • Understood as • finish each phase • don’t proceed till done • Royce criticized this • proposed an iterative approach

  4. Became Popular • Management liked phases to easily set deadlines • Customers provide all requirements • Analysts translate requirements into specification • Coders implement the specification • Reviews ensure the specification is met • Testing is performed by others (QA) • Maintenance means modifying as little as possible • old code is good code • Change is hard (and costly)

  5. Cost of change Waterfall Cost of change XP time

  6. Sprial • Dr Barry Boehm proposed a spiral approach

  7. Waterfall • It became popular • This process is still is used a lot • Craig Larman's book [1] provides proof that waterfall has proved to be a terrible way to develop software. • In his study, 87% of all projects failed. • The waterfall process was the "single largest contributing factor for failure, being cited in 82% of the projects as the number one problem." [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

  8. Extreme Programming (XP) • Almost ten years of growth • Set of SE practices that produce high-quality software with limited effort • Many books, first by Kent Beck: Extreme Programming–Embrace Change, Addison-Wesley, 2000, ISBN 0-201-61641-6 • http://www.extremeprogramming.org/

  9. Extreme Programming • XP is • a disciplined approach to software development • code centric: no reckless coding, test-first • successful because it emphasizes customer involvement and promotes team work • not a solution looking for a problem • One of several "agile" (can adapt to change) software development processes http://www.agilealliance.org/

  10. Fundamentals of XP • Distinguishes between decisions made by business stakeholders and developers • Both are good at their own thing things • Simplistic – keep design as simple as possible “design for today not for tomorrow” • Write automated test code before writing production code and keep all tests running (continually integrate) • Pair programming • Short iterations with fast delivery

  11. Management summary • Light-weight software development process • Replaces documentation with communication • Focuses on source code and testing Controversial – “Hacking”? • 30-70% productivity improvement • Developed by industry practitioners • “..proven at cost conscious companies like Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.” XP Web Site

  12. Essence of XP • Four variables in software development: • Cost, Time, Quality, Scope (# features) • Four Values • Communication, Simplicity, Feedback, and Courage • Five Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • 12 Practices (or fewer) • Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

  13. Overview • Essence of Extreme Programming (XP) • Variables • Values • Principles • Practices

  14. Managing Variables • Managers: "You are going to get all of these requirements done by THE DATE" • When this is the only consideration • "… quality goes out the window … Also likely to go out of control is time. You get crappy software late.", from Extreme Programming Explained, Kent Beck

  15. Four Variables: Cost • Increase cost and you can do a bit more • Pouring money into a project won't solve the problem • "I've been on two infinitely funded projects and both were utter disasters. Money does corrupt." • Reduce the budget for the project • won't be able to solve the customer's problem

  16. Four Variables: Time • Increase time and you improve quality and scope (more features) • Too much time can hurt • With too little time, quality suffers • and scope, time, and cost not far behind

  17. Four Variables: Quality • Quality is a terrible control variable • Can make progress by sacrificing quality (write code solo or without tests) • But to cost--human, business, and technical-- can be enormous

  18. Four Variables: Scope • Scope is the primary control • If you reduce scope (fewer features), you can increase quality, reduce time and cost • You can deliver the most important features sooner and cheaper

  19. The Values • Essence of Extreme Programming (XP) • Variables • Values • Principles • Practices

  20. Four Values: Communication • Communication • Customer centric • Write "Stories", always available • Pair programming • Task estimation • Iteration planning • Design sessions The Agile Manifesto

  21. Four Values: Simplicity • Simplicity • Choose the simplest thing that will work • Choose the simplest design, technology, algorithm, technique

  22. Four Values: Feedback • Feedback very important • Small Iterations • Frequent deliveries • Pair programming • Constant code review • Continuous integration (add often to the build) • automated unit tests (JUnit, for example)

  23. The Principles • Essence of Extreme Programming (XP) • Variables • Values • Principles • Practices

  24. Five Principles: Rapid Feedback • Rapid Feedback • (From psychology) The time between an action and its feedback is critical to learning • In an XP project, developers provide and get feedback as soon as possible, interpret it, and put what is learned into the system

  25. Feedback • Compiler feedback: seconds • Pair programming feedback: half minutes • Unit test feedback: few minutes • Acceptance testing: half hours • Customer write these system level tests • The developers need adapters (test fixtures) to make these pass • Customer feedback: daily • Iteration feedback: weekly • Feedback: Priceless

  26. Four Values: Courage • Courage • Courage to refactor • Estimate: On a scale of 1 to 5, we can do that in 2 • Throw away bad code • Iteration planning • Automated testing breeds courage to change code

  27. Five Principles: Assume Simplicity • Assume Simplicity • Only design for current iteration • this is not the same as skipping design • this is counterintuitive to most developers • Can save time on 98% of the problem and devote that time to the really difficult 2%, Beck • Plan for changes and design the system to handle change • Do a quality job (tests, refactoring, communication) and trust you can add complexity later

  28. Five Principles: Incremental Change • Incremental Change • Problems are solved with a series of the smallest changes that make a difference • In XP, design changes a little at a time, the plan changes a little at a time, the team changes a little at a time • and adoption of XP must be taken in little steps

  29. Five Principles: Embracing Change • Embracing Change • Preserve the most options while solving the most pressing problems

  30. Five Principles: Quality Work • Quality work • People like to do a good job • Quality should be either excellent or extremely excellent (lives at stake) • Without quality • you don't enjoy work • you don't work well • the project goes down the drain

  31. 12 Practices: On-site customer • Many software projects fail because they do not deliver software that meets business needs • Real customer has to be part of the team • Defines business needs • Answers questions and resolves issues • Prioritizes features

  32. The Practices • Essence of Extreme Programming (XP) • Variables • Values • Principles • Practices

  33. 12 Practices: Planning Game • The planning game involves story cards, which are short descriptions of a feature • Provide value to customer • Independent of each other • Testable • Customer writes story cards and prioritizes them • Developers estimate how long a story takes

  34. 12 Practices: The planning game • Business decisions (customer) • Scope: which “stories” should be developed • Priority of stories (features) • Release dates • Technical decisions (developers) • Time estimates for features/stories • Elaborate consequences of business decisions • Team organization and process • Scheduling

  35. 12 Practices: Estimation • Based on similar stories from the past (“yesterday’s weather”) • Team effort • Get good at estimation simply by doing it • Ideal Engineering Time (IET) • could be points • Velocity = IET/Calendar Time • we can do 20 points each week • "Customer, which 20 points do you want next week?"

  36. 12 Practices: Small Releases • Releases should be as small as possible • Should make sense as a whole • Put system into production ASAP • Fast feedback • Deliver valuable features first • Short cycle time • Planning 1-2 months rather than 6-12 months

  37. 12 Practices: Simple design • The “right” design • Runs all tests • No code duplication, No code duplication • Fewest possible classes • Short methods • Fulfills all current business requirements • Design for today not the future • But design so the system can change

  38. 12 Practices: Metaphor • How does the whole system work? • What is the overall idea of the system? • This is the least favorite or least misunderstood practice

  39. 12 Practices: Testing • Software should be tested, but it is often spotty or overlooked • Automatic testing (JUnit, for example) help us know that a feature works and it will work after refactoring, additional code, and other changes • Provides confidence in the program

  40. Testing • Write tests at the same time as production code • Unit tests  developer • Feature/acceptance tests  customer • Don't need a test for every method • Testing can be used to drive development and design of code • Allows for regression testing • Do changes break previously working code

  41. SIM/SQS http://www.simgroup.com/Consultancy/regression.html • Regression Testing • re-testing of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of changes. • Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test. • Regression testing can be carried out on all applications, includinge-Commerce and web-based systems .

  42. Testing • Strong emphasis on regression testing • Unit tests need to execute all the time • Tests for completed features need to execute all the time • Unit tests pass 100% • Acceptance tests (we haven't seen these) show progress on which user stories are working • Other testing frameworks include • JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit

  43. 12 Practices: Refactoring • Restructure code without changing the functionality • Goal: Keep design simple • Change bad design when you find it • Remove dead code • Examples at Martin Fowler's Web site: http://www.refactoring.com/see online catalog

  44. 12 Practices: Pair programming • Write production code with 2 people on one machine • Person 1: Implements the method • Person 2: Thinks strategically about potential improvements, test cases, issues • Pairs change all the time. Has advantages such as • No single expert on any part of the system • Continuous code reviews, fewer defects • Cheaper in the long run, and more fun • Problems: • Not all people like it • Pairs need to be able to work together

  45. 12 Practices: Collective ownership • All code can be changed by anybody on the team • Everybody is required to improve any portion of bad code s/he sees • Everyone has responsibility for the system • Individual code ownership tends to create experts

  46. 12 Practices: Continuous integrationformerly known as the 40 hour work week • Integration happens after a few hours of development • Checkout build with your changes, • Make sure all tests pass (green bar) • In case of errors: • Do not put changes into the build • Fix problems • Checkin the system to the integration machine • Go to 1

  47. Continuous Integration • Find problems early • Can see if a change breaks the system more quickly -- while you remember the details • Small increments

  48. Continuous Integration • Developing full speed only works with fresh people • Working overtime for two weeks in a row indicates problem • Working overtime can help the first week, and hurt the next week • An XP day can be more exhausting, but you can get more done in 40 hours than 60

  49. 12 Practices: Coding standards • Coding Standard • Naming conventions and style • Least amount of work possible: Code should exist once and only once • Team has to adopt a coding standard • Makes it easier to understand other people’s code • Avoids code changes because of syntactic preferences

  50. Project Size • XP was designed for small teams: 2-20 • Case studies show it can scale • Practical advice and modifications are presented in Jutta Eckstein's new book • Agile Software Development in the Large http://jeckstein.com/agilebook/index.html

More Related