Extreme Programming

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