1. e X treme Programming & Agile Modeling Copyright © 2003 Patrick McDermott UC Berkeley Extension pmcdermott@msn.com

2. The Boehm Curve Cost to Fix Bugs Boehm, Barry, Software Engineering Economics, Upper Saddle River, New Jersey: Prentice Hall PTR (0-13-822122-7), 1981.

3. XP Thesis Under certain circumstances, the exponential rise in the cost of changing software over time can be flattened. If we can flatten the curve, old assumptions about the best way to develop software no longer hold. Beck, Kent, Extreme Programming Explained: Embrace Change, 2000, p. 21-22. …

4. XP Thesis One of the universal assumptions of software engineering is that the cost of changing a program rises exponentially over time. I can remember sitting in a big linoleum-floored classroom as a college junior and seeing the professor draw on the board the curve found in Figure 1. [Figure 1 is A Boehm Curve] “The cost to fix a problem in a piece of software rises exponential over time. A problem that might take a dollar to fix if you found it during requirements analysis might costs thousands to fix once the software is in production.“” I resolved then and there that I would never let a problem get through to production. No sirree, I was going to catch problems soon as possible. I would work out every possible problem in advance. I would review and crosscheck my code. No way was I going to cost employer $100,000. The problem is that this curve is no longer valid. Or rather, with combination of technology and programming practices, it is possible to experience a curve that is really quite the opposite.

5. XP Programmers 1. 40-hour week (“Sustainable Pace”) 2. Pair Programming (Scrum) 3. Collective Ownership 4. Continuous Integration 5. Simple Design (No BDUF) 6. Coding Standards 7. Test-Driven 8. Refactoring Fowler, Martin, Refactoring: Improving the Design of Existing Code, Reading, Massachusetts: Addison-Wesley (0-201-48567-2), 2000.

6. Agile Modeling Favor Left over Right (but both important) Individuals and interactions over Processes and tools. Working software over Comprehensive documentation. Customer collaboration over Contract negotiation. Responding to change over Following a plan. Ambler, Scott W., Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, New York: Wiley Computer Publishing (0-471-20282-7), 2002.

7. AM Principles 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4.Business people and developers work together daily throughout the project. …

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

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