eXtreme Programming (XP)

1. eXtreme Programming (XP) CSE301 University of Sunderland Harry R. Erwin, PhD

2. Sources • Stephens and Rosenberg, 2003, Extreme Programming Refactored: The Case Against XP, Apress. • Fowler, 2000, Refactoring: Improving the Design of Existing Code, Addison-Wesley. • Martin, 2003, Agile Software Development: Principles, Patterns, and Practices, Prentice-Hall. • Extensive discussions on comp.object • Ebert 2000, http://www.ics.uci.edu/~ebert/teaching/fall2000/ics121/

3. Where do Agile Methods Fit? • Projects where the risk is high. • Where you or your customer don’t know where you’re going. • Projects where you have to learn and adapt. • Projects where the technology is evolving rapidly.

4. Extreme Programming Defined (Beck, 1998, Cunningham’s wiki) • http://c2.com/cgi/wiki • Is defined by the following: • Values • Practices • Activities • Roles • Intended to flatten the cost of change curve. • Just one of several agile methods.

5. Manifesto for Agile Software Development (Martin 2003) • “We are uncovering better ways of developing software by doing it and by helping others to do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • That is, while there is value in the items on the right, we value the items on the left more.”

6. Principles behind the Agile Manifesto (from Martin 2003) • “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. • Business people and developers must work together daily throughout the project.

7. Principles (II) • “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. Principles (III) • “Continuous attention to technical excellence and good design enhances agility. • Simplicity—the art of maximizing the amount of work not done—is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

9. Problems Targeted by XP • Lack of communication • Requirements volatility • Software development that isn’t used. • Out of date documentation • Obsolescence

10. XP Values • Communication—verbal, with a collocated team. • Simplicity—always do the simplest thing that can possibly work. • Feedback—continuous from the customer. • Courage—willingness to change.

11. Communication—Verbal, with a Collocated Team. • Reduces the chance of misunderstanding. • Creates risks, however: • Details get lost if they’re not written down. • You’re vulnerable to loss of personnel. • YMMV.

12. Simplicity—Always do the Simplest Thing that can Possibly Work. • You Ain’t Gonna Need It (YAGNI). • Absolute simplicity isn’t always the best solution, so be as simple as possible but not too simple. • Nonfunctional requirements will affect simplicity.

13. Feedback—Continuous from the Customer. • Go ask the customer—he’s sitting over there. • Also used in design: • Build a first-order prototype • Test it • Adjust it until it’s right. • A little bit of feedback can replace a lot of analytical work.

14. Courage—Willingness to Change. • Be willing to make design changes when they are right. • It helps a lot to have an automatic test suite to tell you that you’re still OK.

15. XP Activities • Coding • Testing • Listening • Designing

16. XP Roles • Programmer • Tester • Tracker • Coach • Consultant • Big boss

17. Test-driven development User stories The planning game Whole team Short cycles Metaphor Simple design Refactor mercilessly Collective ownership Pair programming Continuous integration Sustainable pace Coding standards Acceptance tests (Emergent design) XP Practices

18. Test-Driven Development • ‘The test-driven development is the method of software development where tests specify interfaces of implementation and all code must have passed the tests.’ (Wikipedia) • Martin (2003): ‘programmers work in very short cycles, adding a failing test, then making it work.’

19. User Stories • One or two sentences summarizing what the user wants. • Describes how the system is supposed to work • Written on a card. • Sufficient detail to support estimation.

20. The Planning Game • Martin (2003): “Planning is continuous and progressive. Every two weeks, for the next two weeks, developers estimate the cost of candidate features, and customers select those features to be implemented based upon cost and business value.”

21. The Planning Game • Planning is an emotional minefield. Of course Development would like to program faster. Of course the project manager would like to be able to say exactly how fast Development can go. Of course Business would like to be able to say exactly what they want. Of course Business would rather not change its mind. When any of the participants in planning begin acting these wishes (or rather in accordance with the fears that lie behind each wish), then planning doesn't work well. (Wikipedia)

22. How to Plan • Maintain velocity. • Merging and splitting stories: User stories should be ‘right-sized’. • Prototyping sessions are called ‘spikes’. These allow the team’s velocity to be estimated.

23. XP Life Cycle • Evolutionary development • Coding is continuous • Iterations of 1-3 weeks • Design -> Code -> Integrate -> Test • Repeated several times a day • Based on ‘user stories’

24. Whole Team • Martin (2003): “All the contributers to an XP project—developers, business analysts, testers, etc.—work together in an open space, members of one team. The walls of this space are littered with big visible charts and other evidences of their progress.”

25. Short Cycles • 1-3 week cycles. Other processes suggest a month, with weekly tracking.

26. Metaphor • Martin (2003): “The team develops a common vision of how the program works.”

27. Simple Design • Martin (2003): “The team keeps the design exactly suited for the current functionality of the system. It passes all the tests, contains no duplication, expresses everything the authors want expressed, and contains as little code as possible.”

28. Simple Design • The simplest design that can meet the current set of user stories. • “You aren’t going to need it.” • Once and only once—no code duplication.

29. Refactor Mercilessly • We’ve discussed this. • Don’t churn the code. • Keep it clean to support extension.

30. Refactoring • Deals with code ‘rot’. • Refactoring is a technique to restructure code in a disciplined way. For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. (Fowler)

31. Collective Ownership • Martin (2003): “Any pair of programmers can improve any code at any time.”

32. Pair Programming • Martin (2003): “All production software is built by two programmers, sitting side by side, at the same machine.” • Boehm (2004) indicates that pair programming is about 10% slower, but the software fault rate of the resulting code is about 60% less. This is a ‘silver bullet’.

33. Pair Programming • Pair Programming (ExtremeProgrammingPractice) requires two engineers to participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example. Studies have shown that, after training for the "PeopleSkills" involved two programmers are more than twice as productive as one for a given task. (Wikipedia)

34. Continuous Integration • Martin (2003): “The team keeps the system fully integrated at all times.”

35. Sustainable Pace • Martin (2003): “The team is in it for the long term. They work hard, at a pace that can be sustained indefinitely. They conserve their energy, treating the project as a marathon rather that a sprint.”

36. Coding Standards • Martin (2003): “All the code in the system looks as if it was written by a single—very competent—individual.”

37. Acceptance Tests • Martin (2003): “As part of selecting each desired feature, the customers define automated acceptance tests to show that the feature is working.”

38. Emergent Design • The initial design and architecture will be wrong. • If you can’t change it, you’ll have to live with it for 10-20 years. • Let it emerge through refactoring so it is right.

39. Interaction Between Practices • XP is believed to work only when all practices are followed. • Then the weaknesses of one practices are covered by the strengths of others. • For example: • Use of emergent design is well-known to be risky. Constant refactoring protects against that risk. • Constant refactoring is a time sink and a source of bugs—extensive unit testing protects against that. • Reliance on unit tests does not validate the design. Pair programming protects against design errors.

40. What Practices are Provably Good? • The following practices should be followed independently of development model: • Test-driven development • Short cycles (early warning) • Metaphor (leadership) • Simple design (KISS) • Refactor mercilessly (isn’t eclipse wonderful?) • Pair programming* (more productive than alone) • Sustainable pace (ever been ‘fried’?) • Coding standards (for yourself if no one else) *except on homework projects…

41. Conclusions • If XP is the answer, what is the question? • Certain kinds of problems, especially those where you don’t know where you’re going, are particularly suitable for XP, so be prepared for it, even if on other projects you have to use a heavy-weight process.