1 / 40

An Introduction to Extreme Programming

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. The Joy of Software. To change Hardware Soldering Iron Screwdrivers Change PCB To change Software

starr
Download Presentation

An Introduction to Extreme Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. The Joy of Software • To change Hardware • Soldering Iron • Screwdrivers • Change PCB • To change Software • Just change some symbols

  3. The Reality? of Software Cost of MakingChanges • Changing Software is Hard • Dependencies Time

  4. 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. BDUF (Big Design Up Front) Cost of Making Changes Find errors faster • Almost all method(ologie)s focus on this assumption no matter what they say about the evils of waterfalls! Time Analysis Design Coding Testing

  6. 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. 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. 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. Another Approach Reduce cost of later change Cost of Making Changes • The flatter this is, the less... • Benefit of up-front design • Cost of up-front design • Cost of maintaining design artifacts Time

  10. 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. 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. The Four Values • Simplicity • Communication • Feedback • Aggressiveness

  13. 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. 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. 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. 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. XP Practices

  18. 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. Development Practices A Day in the Life...

  20. 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. Development Practices A Little More Detail

  22. Split Business & Technical • Customer • chooses scope • sets priorities • Developers • estimate time required to implement requirements • schedule within a release...

  23. 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. 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. 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. 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. 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. Refactoring • Pair brings code back to simplicity the instant they see it drifting away • Short episodes...

  29. 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. 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. First Steps to Playing to Win

  32. Playing to Win • Reality of Power, Power of Reality • Cards as Weapons • Planning Game • Exploration Phase • Commitment Phase • Iterations • Having Tests

  33. 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. Cards as Weapons • The Planning Game • Business moves • Developer moves • Exploration Phase • Commitment Phase • Iterations

  35. Exploration Phase • Write a story (Business) • Estimate a story (Developer) • Split a story (Business, often prompted by Developer)

  36. 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. Iterations • During Iteration Planning • Cards can be shifted • Time cannot • During Iteration • Clarification as we learn • That’s another iteration

  38. Having Tests • Take the confidence of the moment, and preserve it • When did it break? • Allows • refactoring • collective code ownership • feedback • trust...

  39. 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. To Learn More... • Books from AW-L: • Extreme Programming Explained: Embrace ChangeKent 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

More Related