XP methodology

1. ITEC XP Object Mentor, Inc. www.objectmentor.com Erik Meade www.geekfarm.com/emeade Copyright  1998-1999 by Object Mentor, Inc All Rights Reserved Portions of this material are Copyright © 1998, by Addison Wesley Longman,Inc. and have been reproduced here with permission.

2. The Paradox of Process Improvement A good process will tell you to do what a good manager and staff would do anyway. -- Tom DeMarco

3. The Extreme Premise The flattening of the cost of change curve Copyright  1998-1999 by Object Mentor, Inc All Rights Reserved Portions of this material are Copyright © 1998, by Addison Wesley Longman,Inc. and have been reproduced here with permission.

4. Boehm said… $10,000 Test $1,000 Implementation $100 Design $10 Analysis $1 Requirements Cost of change grows exponentially with time

5. When costs increase exponentially • We need to do lots of up-front planning! • Every bug that can be caught early saves us lots of money. • Because models are cheaper to modify than code.

6. When costs increase exponentially • We are willing to make a very large investment in up-front analysis and design models. • Because the cost of late error discovery is horrendous. • Ergo, waterfall mentality and big design up front (BDUF) are the conventional wisdom.

7. But a few things have changed in three decades. • We don’t have to walk down the hall and submit a deck of cards to the operator and then wait a day for our compile to finish. • Computers are 1000X faster and 1000X cheaper. •  1,000,000 X power/$ !! • Compile/test cycle has gone from days to seconds. • We have relational DBMSs, CM tools, CASE tools, object databases, modular programming, information hiding, etc. • Finally, OO languages and principles make software much easier to change.

8. So, perhaps the cost of change can be flat ...for much of the life of the system. If tools, practices, and principles are properly employed.

9. When costs don’t dramatically increase with time. • Up front work becomes a liability. • We pay for up front speculative work, some of which will certainly be wrong. • Ambiguity or volatility is reason to delay. • So we don’t plan for something that never happens. • It is cost effective to delay all decisions until the last possible moment. • We only pay for what we use.

10. The value of waiting. • If you implement a feature today, but it turns out not to be valuable, you lose money and opportunity. • If you are uncertain and you can wait, then the risk goes away over time. • Time answers questions and removes uncertainty.

11. Dealing with low cost changes. • We need a process that creates and then exploits a flat change-cost curve. • XP is such a process.

12. What is XP? A Quick Summary Copyright  1998-1999 by Object Mentor, Inc All Rights Reserved Portions of this material are Copyright © 1998, by Addison Wesley Longman,Inc. and have been reproduced here with permission.

13. What is XP? • XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. -- Kent Beck. • XP is: • Humane. • Honest. • Productive. • Professional. • Fun.

14. What is XP? • XP is a discipline of software development. • There are certain things you must do. • You must write tests before code. • You must program in pairs. • You must integrate frequently. • You must be rested. • You must communicate with the customer daily. • You must follow the customer’s priorities. • You must leave the software clean and simple by the end of the day. • You must adapt the process and practices to your environment.

15. XP Motives • Adaptability: • In the business. • In technology. • In the team. • Predictability. • Overall plans and schedule. • Feedback and tuning. • Options. • Change direction or priority at any time. • Humanity. • A mentality of sufficiency.

16. Developer Bill of Rights • You have the right to know what is needed, with clear declarations of priority. • You have the right to produce quality work at all times. • You have the right to ask for and receive help from peers, superiors, and customers. • You have the right to make, and update your own estimates. • You have the right to accept your responsibilities instead of having them assigned to you.

17. The Customer Bill of Rights. • You have the right to an overall plan, to know what can be accomplished, when, and at what cost. • You have the right to get the most possible value out of every programming week. • You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. • You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs. • You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can cancel at any time and be left with a useful working system reflecting investment to date.

18. Why is it Extreme? • Because we take good practices to extreme levels (turning the knobs up to 10!): • 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 its current functionality. (The simplest thing that could possibly work.

19. Turning the Knobs to 10 (Continued). • If architecture is important, everybody will work defining and refining the architecture all the time (Metaphor). • If integration testing is important, then we’ll integrate and test several time a day (continuous integration). • If feedback is good, we’ll get feedback quickly -- seconds and minutes and hours, not weeks and months and years (the Planning Game).

20. What makes XP different? • Its early, concrete, and continuing feedback from short cycles. • Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project. • Its ability to flexibly schedule the implementation of functionality, responding to changing business needs. • Its reliance on automated tests to demonstrate the presence of features. • Its reliance on oral communications, tests, and source code to communicate system structure and intent.

21. What makes XP different?(Continued) • Its reliance on an evolutionary design process that lasts as long as the system lasts. • Its reliance on the close collaboration of programmers. • Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.

22. What makes XP familiar? • XP matches the behavior of successful programmers in the wild. • Tests. • Refactoring. • Evolutionary delivery. • Incremental planning. • Low overhead.

23. Waterfall Three Processes Iterative XP Time Scope

24. Iteration Weeks Implementation Days XP Time Scales Years Release Months

25. Values • XP team members value: • Communication. • Simplicity. • Feedback. • Courage.

26. XP Communication • XP teams: • Use a common system metaphor. • Work in an open workspace. • Continuously integrate the code. • Have a customer teammate. • Program in pairs. • Collectively own the code. • Frequently plan with and report status to the customer.

27. XP Simplicity • XP teams: • Do the simplest thing that could possibly work. • Continuously simplify and improve the design through refactoring.

28. XP Feedback • Write test cases before production code. • Develop in small releases, • And even smaller iterations. • And even smaller tasks. • And even smaller tests.

29. XP Courage • XP team members are not afraid to: • Stop when they are tired. • Let every business decision be made by the customer. • Ask customers to reduce the scope of a release. • Ask their peers, or customers, for help. • Design and implement only what is needed for today, trusting that we can add, tomorrow, what will be needed tomorrow. • Make changes that improve the function or structure of code. • Fix the design and retrofit existing code when the design is shown to be inadequate. • Throw code away. • Change the process when it’s not working.

30. Basic Principles • Rapid feedback • Assume simplicity • Incremental change • Embracing change • Quality work

31. Rapid Feedback • The best learning occurs when the time between action and feedback is short. • So, get feedback, interpret it, and put it back into the system as quickly as possible. • Get feedback for: • Schedule. • Quality. • Process. • Morale.

32. Assume Simplicity • Treat every problem as if it can be solved with ridiculous simplicity. • The time you save on 98% of problems for which this is true, will give you ridiculous resources to apply to the other 2% -- Paul B. MacCready Gossamer Condor. • Do a good job on today’s problems. • Sufficient for the day are the troubles therein. • Let tomorrow worry about tomorrow.

33. Incremental Change • Big changes made all at once just don’t work. • Any problem is solved with a series of the smallest changes that make a difference. • In XP • The design changes a little at a time. • The plan changes a little at a time. • The team changes a little at a time.

34. Embracing Change • The best strategy is the one that preserves the most options while actually solving your most pressing problem. • We see the volatility of requirements as an opportunity, not as a problem.

35. Quality work • Nobody likes working sloppy. • Everybody likes doing a good job. • The only acceptable quality levels are: • Excellent. • Insanely excellent... • If lives are at stake. • Otherwise: • You don’t enjoy your work. • You don’t work well. • The project goes down the drain.