1 / 21

Introduction to Extreme Programming

Introduction to Extreme Programming. William C. Wake William.Wake@acm.org 2-2-2000. XP is. $. $. t. t. Background: Cost of Changes. “Now” (flattened). “Then” (exponential). Background: Cost of Money. “Up-front design”. $. $$. “Pay as you go”. t. XP Principles. Rapid feedback

martena-galloway
Download Presentation

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. Introduction toExtreme Programming William C. Wake William.Wake@acm.org 2-2-2000

  2. XP is...

  3. $ $ t t Background: Cost of Changes “Now” (flattened) “Then” (exponential)

  4. Background: Cost of Money “Up-front design” $ $$ “Pay as you go” t

  5. XP Principles • Rapid feedback • Assume simplicity • Incremental change • Embrace Change • Quality Work

  6. Planning Game Metaphor Tests Refactoring Pair programming Small releases Simple design Collective ownership Continuous integration Open workspace 40-hour week XP Practices

  7. Manager and Customer: You have the right.. to an overall plan, to know what can be accomplished, when, and at what cost. etc. Developer: You have the right.. to know what is needed, via clear requirement stories, with clear declarations of priority. etc. Rights

  8. The XP Cycle (in the small) analysis test code design

  9. Planning Game

  10. Planning Game • Users write stories • Developers estimate them • Users split, merge, & prioritize • Plan overall release (loosely) and the next iteration

  11. Tests • Functional Tests • Unit Tests

  12. Functional Tests • Specified by the user • Implemented by users, developers, and/or test team • Automated • Run at least daily • Part of the specification

  13. Unit Tests • Written by developers • Written before and after coding • Always run at 100% • Support design, coding, refactoring, and quality.

  14. Test Metrics Key: Tests failed Tests passed 1 2 3 4 5 6 7

  15. Design • Pay as you go • Spike when necessary • “You aren’t gonna need it” • “Simplest thing that could possibly work” • “Once And Only Once”

  16. Refactor (Mercilessly) • Refactor = to improve the structure of code without affecting its external behavior • Done in small steps • Supported by unit tests, simple design, and pair programming • Seek “once and only once”

  17. Refactoring Example

  18. Adopting XP • Some practices can be done solo, others by team, others require users to help. • User involvement • Functional tests and unit tests • Simple design & refactoring • Pair programming

  19. Other Approaches • UML: XP uses it on the whiteboard (if at all) • Rational Unified Process: XP has many fewer roles & documents; XP emphasizes team over artifacts • SCRUM: XP compatible

  20. Who, Us? And other questions

  21. More Information • Extreme Programming Explained, by Kent Beck • Refactoring, by Martin Fowler • http://www.xprogramming.com • http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

More Related