1. Page 1 Copyright © 1999, RoleModel Software, Inc. An Introduction to Extreme Programming Ken Auer kauer@rolemodelsoft.com http://www.rolemodelsoft.com RoleModel Software, Inc. 5004 Rossmore Dr. Fuquay-Varina, NC 27526 919-557-6352

2. Page 2 Copyright © 1999, RoleModel Software, Inc. The Joy of Software  To change Hardware  Soldering Iron  Screwdrivers  Change PCB  To change Software  Just change some symbols

3. Page 3 Copyright © 1999, RoleModel Software, Inc. The Reality? of Software  Changing Software is Hard  Dependencies Cost of Making Changes Time

4. Page 4 Copyright © 1999, RoleModel Software, Inc. The Promise of Specifications  Examples from Traditional Engineering  Do the Drawings first  Design work is done on the drawings  Construction is a separate act (at least in theory)  In Software  Capture Requirements up front  Do design up front  Hand over to coders

5. Page 5 Copyright © 1999, RoleModel Software, Inc. BDUF (Big Design Up Front) Cost of Making Changes Time AnalysisDesignCodingTesting Find errors faster  Almost all method(ologie)s focus on this assumption no matter what they say about the evils of waterfalls!

6. Page 6 Copyright © 1999, RoleModel Software, Inc. The Uncomfortable Reality  The Customers change requirements  Customers believe software is easy to change  Real requirements hard to nail down  They’re learning, conditions change  Hard to get costs of features  Materials keep changing  Productivity of people/teams vary widely  Later development tasks hard to estimate  Developers learn as they program  Too much flexibility costs  Cannot design for unanticipated changes  Often anticipate wrong changes ...

7. Page 7 Copyright © 1999, RoleModel Software, Inc. Design Decisions  In the moment  Consider current needs  Patch code when new needs appear… is this really design???  Up front design  Consider current needs and possible future needs  Design to minimize change with future needs  Patch code if unforeseen need appears  Evolutionary design  Consider current needs and possible future needs  Trade off cost of current flexibility versus cost of later refactoring  Refactor as changes appear

8. Page 8 Copyright © 1999, RoleModel Software, Inc. Object Orientation Object-orientation helps manage the complexity of software and reduce dependencies… Why don’t methods reflect this? Why don’t methods exploit this? Many have tried but failed because they threw out the baby (discipline) when they threw out the bathwaterfall...

9. Page 9 Copyright © 1999, RoleModel Software, Inc. Another Approach Cost of Making Changes Time Reduce cost of later change  The flatter this is, the less...  Benefit of up-front design  Cost of up-front design  Cost of maintaining design artifacts

10. Page 10 Copyright © 1999, RoleModel Software, Inc. Extreme Programming “Recognizing that the cost of changing a program no longer grows exponentially over time, XP relies on the complex interactions between simple development practices to reduce project risk, improve responsiveness to business and technical learning, and make programming more fun” - Kent Beck

11. Page 11 Copyright © 1999, RoleModel Software, Inc. Playing to Win  Don’t just “survive”  Tackle problems aggressively  Tackle only the problems that you KNOW exist in the current context  Communicate to expose and reduce risk  Be confident in what you’ve done and are doing based on feedback

12. Page 12 Copyright © 1999, RoleModel Software, Inc. The Four Values  Simplicity  Communication  Feedback  Aggressiveness

13. Page 13 Copyright © 1999, RoleModel Software, Inc. Simplicity  What is the simplest thing that will possibly work?  No code duplication  Don’t look too far ahead…  Simple things are easier to change  You may not need it

14. Page 14 Copyright © 1999, RoleModel Software, Inc. Communication  People talk to people  People work with people  People are honest when they don’t know  People share what they’ve learned!  Code communicates with people  No documentation for documentation’s sake

15. Page 15 Copyright © 1999, RoleModel Software, Inc. Feedback  Measure things that matter  Look at the measurements  Share the measurements  Believe the measurements tell you something  Change what you can, accept what you can’t

16. Page 16 Copyright © 1999, RoleModel Software, Inc. Aggressiveness  You’ve got to believe that you can do it  Jump into the problem, don’t be frozen by all the things that can go wrong  Believe that when things do go wrong, you can fix them

17. Page 17 Copyright © 1999, RoleModel Software, Inc. XP Practices

18. Page 18 Copyright © 1999, RoleModel Software, Inc. XP Iterations  Limited Up Front Design  Detailed work in iterations  Up front work for estimates and risk assessment  Planning Game  Customers develop stories (use cases)  Development estimates stories  Joint scheduling based on customer value and development risk  Disciplined development  Write tests first  Only focus on story in hand  Short development episodes in pairs  Continuous Integration  Always working, always clean

19. Page 19 Copyright © 1999, RoleModel Software, Inc. Development Practices A Day in the Life...

20. Page 20 Copyright © 1999, RoleModel Software, Inc. A Day In The Life  Stand up meeting  Load latest stuff  Identify tasks  Pair up  Test first, code second  What exists?  Does it support what we need to do?  Gotta test for that?  Do the tests work?  Is the code clean (enough)?  If it’s working, integrate it  Do the tests work?  Next task?

21. Page 21 Copyright © 1999, RoleModel Software, Inc. Development Practices A Little More Detail

22. Page 22 Copyright © 1999, RoleModel Software, Inc. Split Business & Technical  Customer  chooses scope  sets priorities  Developers  estimate time required to implement requirements  schedule within a release...

23. Page 23 Copyright © 1999, RoleModel Software, Inc. Small Releases  Customer  chooses smallest, most valuable set of requirements to put into production next  Developers  keep design simple to get requirements met as fast as possible

24. Page 24 Copyright © 1999, RoleModel Software, Inc. Metaphor  Everyone tells the story of the system consistent with a central metaphor  Validate the metaphor quickly with a concrete design  Often 5-20 CRC level concepts

25. Page 25 Copyright © 1999, RoleModel Software, Inc. Simple Design  At all times the system has  simplest design that runs all test cases  no code duplication  no unnecessary classes or methods  Constantly evolved through refactoring

26. Page 26 Copyright © 1999, RoleModel Software, Inc. Having Tests  Developers  write and satisfy unit tests for all development  write the tests first  Customers/Testers  write functional tests for each requirement  Ensure all tests can be run with one command  Test often… every change to a line of code??  Run all tests with every build  Tests should be about 1/3 of production code

27. Page 27 Copyright © 1999, RoleModel Software, Inc. Pair Programming  All Production Code…  written with two people sitting at one machine  pass the keyboard and mouse back and forth  Refactoring code wherever it needs clean up  Write tests  Everyone knows a little about the whole system

28. Page 28 Copyright © 1999, RoleModel Software, Inc. Refactoring  Pair brings code back to simplicity the instant they see it drifting away  Short episodes...

29. Page 29 Copyright © 1999, RoleModel Software, Inc. Continuous Integration  System is built and successfully tested several times a day  each time a pair gets the test cases for a simple development task running  integration machine

30. Page 30 Copyright © 1999, RoleModel Software, Inc. Collective Code Ownership  Code is fixed wherever it is found to be deficient  Tests verify you haven’t broken anything  New tests verify it doesn’t happen again

31. Page 31 Copyright © 1999, RoleModel Software, Inc. First Steps to Playing to Win

32. Page 32 Copyright © 1999, RoleModel Software, Inc. Playing to Win  Reality of Power, Power of Reality  Cards as Weapons  Planning Game  Exploration Phase  Commitment Phase  Iterations  Having Tests

33. Page 33 Copyright © 1999, RoleModel Software, Inc. Reality of Power; Power of Reality  Four Variables  Scope  Quality (internal, external)  Cost  Time  Technical people can’t run the business  Business people can’t program

34. Page 34 Copyright © 1999, RoleModel Software, Inc. Cards as Weapons  The Planning Game  Business moves  Developer moves  Exploration Phase  Commitment Phase  Iterations

35. Page 35 Copyright © 1999, RoleModel Software, Inc. Exploration Phase  Write a story (Business)  Estimate a story (Developer)  Split a story (Business, often prompted by Developer)

36. Page 36 Copyright © 1999, RoleModel Software, Inc. Commitment Phase  Sort by Value (Business)  Sort by Risk (Developer)  Set Velocity (Developer w/ Business)  Choose Scope (Business)  Choose date, OR  Choose stories  Create the Plan (Developer)

37. Page 37 Copyright © 1999, RoleModel Software, Inc. Iterations  During Iteration Planning  Cards can be shifted  Time cannot  During Iteration  Clarification as we learn  That’s another iteration

38. Page 38 Copyright © 1999, RoleModel Software, Inc. Having Tests  Take the confidence of the moment, and preserve it  When did it break?  Allows  refactoring  collective code ownership  feedback  trust...

39. Page 39 Copyright © 1999, RoleModel Software, Inc. Final Thoughts  Undisciplined coding leads to a steep cost of change curve  BDUF doesn’t change the curve  It attempts to reduce number of times you are bitten by the curve  It adds up front cost that may never be recovered  XP focuses on pushing the “cost of change” curve down  Any of the XP practices might help your project  Adopting all of the practices will allow you to attain a high level of productivity and produce high quality product at a sustained rate over an extended period of time

40. Page 40 Copyright © 1999, RoleModel Software, Inc. To Learn More...  Books from AW-L:  Extreme Programming Explained: Embrace Change Kent Beck  Refactoring: Improving the Design of Existing Code Martin Fowler  Extreme Programming Applied: Playing to Win (not yet available) Auer, Cunningham, Beck, Fowler, Jeffries  http://www.rolemodelsoft.com  http://www.XProgramming.com  http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap