Extreme Programming

1. Extreme Programming Sylvain Giroux October 3rd, 2000

2. Plan • The Problem to Solve • XP: What? Why? When? • “X” ? • Software Methodolgy • Variables • Values • Rules • Practices • References

3. Risk: The Basic Problem • Software development • fails to deliver, • and fails to deliver value. • Schedule slips • Project canceled • System goes sour • Defect rate • Business misunderstood / changes • False feature rich • Staff turnover

4. Software methodology • A software methodology is the set of rules and practices used to create computer programs. • A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly. • Rational Unified Process (1491 files in 159 folders) • A lightweight methodology has only a few rules and practices or ones which are easy to follow.

5. Extreme Programming • a lightweight discipline of software development • for small size teams (2-10 people) • to develop software • quickly • in an environment of rapidly-changing requirements.

6. Goal of XP • to deliver the software • that is needed • when it is needed.

7. When to use XP? • problem domains whose requirements change • may not have a firm idea of what the system should do • a system whose functionality is expected to change every few months. • to address the problems of project risk. • If your customers need a new system by a specific date the risk is high. • If that system is a new challenge for your software group the risk is even greater. • If that system is a new challenge to the entire software industry the risk is greater even still.

8. When to use XP? • XP requires an extended development team. • the developers • the managers • the customers • Why? • asking questions, • negotiating scope and schedules, • creating functional tests • require more than just the developers be involved in producing the software.

9. When to use XP? • Testability • Productivity • XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment.

10. Why Extreme ? -- I • If code reviews are good, we’ll review code all the time (pair programming). • If testing is good, everybody will test all the time (unit testing), even the customers (functional testing) • If design is good, we’ll make it part of everybody’s daily business (refactoring) • If simplicity is good, we’ll always leave the system with the simplest design that supports current functionality (the simplest thing that could possibly work).

11. Why Extreme ? -- II • If architecture is important, everybody will work defining and refining the architecture all the time (metaphor) • If integration testing is important, we’ll integrate and test several times a day (continuous integration). • If short iterations are good, we’ll make the iterations really, really short –seconds and minutes and hours, not weeks and months and years (the Planning Game).

12. Four Variables • We will control four variables in our projects • Cost • Time • Quality • Scope • External forces (customers and managers) get to pick the values of 3 of the variables. • The development team gets to pick the resultant value of the 4th variable.

13. Values • XP is based on • Communication • Simplicity • Feedback • Courage.

14. Value : communication • Problems with projects can invariably be traced back to somebody not talking to somebody else about something important • A programmer doesn’t tell someone else about a critical change in the design • A programmer doesn’t ask the customer the right question, so a critical domain decision is blown • A manager doesn’t ask a programmer the right question, and project progress is misreported

15. Value : communication and XP Practices • XP practices that can’t be done without communication • Unit testing • Pair programming • Task estimation

16. Value : simplicity • What is the simplest thing that could possibly work? • Not to look toward the things you’ll need tomorrow and next week and next month • XP stance: • It is better to do a simple thing today and pay a little more tomorrow to change if it needs it, • than to do a more complicated thing today that may never be used anyway

17. Value : simplicity and XP Practices • The more you communicate, the clearer you can see exactly what needs to be done and the more you have confidence about what really doesn’t need to be done • The simpler your system is, the less you have to communicate about • Practices • Simple design • Refactoring

18. Value : Feedback at scale of minutes and days • Concrete feedback about the current state of the system • Don’t ask me, ask the system • Feedback for customers • When customers write new stories (description of features), the programmers immediately estimate them • Feedback on project progress • Watching the completion of tasks to give the whole team feedback about whether they are likely to finish everything they set out to do in a span of time

19. Value : Feedback at scale of weeks and months • The customers and testers write functional tests for all the stories (simplified use cases) implemented by the system. • The customers review the schedule every two or three weeks • to see if the team’s overall velocity matches the plan, • to adjust the plan • The system is put into production as soon as it makes sense, so the business can • begin to “feel” what the system is in action and • discover how it can best be exploited.

20. Value : Feedback and XP practices • The more feedback you have, the easier it is to communicate • Simple systems are easier to test • XP practices • The planning game • Small releases • Testing • Pair programming • Continuous integration • On-site customer

21. Value : Courage • Courage to take decisions • Radical surgery on code • Throwing code away • Starting over from scratch • Prototyping multiple design alternatives, and keep only one for “real” development

22. Last but not least Respect

23. Principles From the 4 values, a dozen or so of principles (rules) are derived to guide the development style

24. Central Principles • Main principles • Rapid feedback • time between action and feedback is critical • Assume simplicity • Incremental Change • Big change made all at once just don’t work • Embracing change • Preserves the most options while solving the most pressing problem • Quality work • Nobody likes working sloppy

25. Less central principles • Teach learning • No doctrine • Small initial investment • Too many resources too early in a project is a recipe for disaster • Play to win • Playing to win vs playing not to lose • For sure we need to write reports, … but getting a working system is more important… • Concrete experiments • Every time you made a decision and you don’t test it, there is some probability that the decision is wrong.

26. Less central principles • Open, honest communication • Able to tell each other where there are problems in the code • Able to express fears and get support • Free to deliver bad news to customers and management, to deliver it early, and without being punished • Work with people’s instincts, not against them • XP is a process where following short-term self-interest (win, learn, be in control, good work…) also serves long-term team interest • Accepted responsibility • Not telling people what to do • Does not mean that you always do exactly what you feel like doing

27. Less central principles • Local adaptation • Adapt XP principles and practices to local conditions • Travel light • You can’t expect to carry a lot of baggage and move fast • Be prepared to change direction • Artifacts • Few • Simple • Valuable • Honest measurement • This will take 14.176 hours (???)

28. Back to basics • There are 4 activities to support • Coding • Testing • Listening • Designing

29. XP Practices • What is a practice? the usual way of doing something • Aim of practices in XP: • Structure the 4 activities • Coding, testing, listening, designing • In XP, there are 12 practices

30. 12 Practices • The Planning Game • Small Releases. • Metaphor. • Simple Design. • Testing. • Refactoring. • Pair Programming. • Collective Ownership. • Continuous Integration. • 40-hour Week. • On-site Customer. • Coding Standard.

31. Practice: The Planning Game • The XP "customer“ • define the business value of desired features • The programmer • provides cost estimates • The XP "customer“ • choose • what needs to be done • what needs to be deferred

32. Practice: Small releases XP teams • put a simple system into production early, • update it frequently on a very short cycle

33. Practice: Metaphor XP teams use • common "system of names" and a • common system description • that guide development and communication • We don’t literally mean “the system is…” • Give everyone a coherent story within which to work • Help everyone on the project understand the basic elements and their relationships

34. Practice: Simple design • A program built with XP should be the SIMPLEST program that meets the current requirements. • There is not much building "for the future".

35. Practice: Testing • XP teams focus on validation of the software at all times. • Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. • Customers provide acceptance tests that enable them to be certain that the features they need are provided.

36. Practice: Refactoring • XP teams improve the design of the system throughout the entire development • This is done by keeping the software clean • without duplication • with high communication • simple • Yet complete

37. Practice: Pair Programming • XP programmers write all production code in pairs, • two programmers working together at one machine

38. Practice: Collective ownership • All the code belongs to all the programmers • This lets the team go at full speed, because when something needs changing, it can be changed without delay

39. Practice: Continuous integration • XP teams integrate and build the software system multiple times per day • This keeps all the programmers on the same page, and enables very rapid progress • integrating more frequently tends to eliminate integration problems that plague teams who integrate less often

40. Practice: 40-hour week • Tired programmers make more mistakes. • XP teams do not work excessive overtime, • keeping themselves fresh, healthy, and effective

41. Practice: On-site customer • An XP project is steered by a dedicated individual who is empowered to • determine requirements, • set priorities, • answer questions as the programmers have them

42. Practice: Coding standards • to work effectively in pairs, • to share ownership of all the code, • all the programmers need to write the code in the same way • with rules that make sure the code communicates clearly Software, naming, language, {}…

43. XP map A spike solution is a very simple program to explore potential solutions

44. References • Kent beck, Extreme Programming Explained: Embrace Change, Addison Wesley, 2000 • Martin Fowler, Refactoring : Improving the Design of Existing Code, Addison-Wesley, 1999 • http://www.xprogramming.com • http://www.xprogramming.com/xpmag/index.htm • http://www.xprogramming.com/Practices/xpractices.htm • http://www.extremeprogramming.org/