1 / 14

Extreme Programming

Extreme Programming. David Stotts Dept. of Computer Science Univ. of North Carolina at Chapel Hill. In Reaction to…. “Big Process” SEI Capability Maturity Model ( CMM ) “Heavy” development practices Hard to steer, unresponsive Can we do better for smaller efforts?. Extreme Programming.

alpha
Download Presentation

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. Extreme Programming David Stotts Dept. of Computer Science Univ. of North Carolina at Chapel Hill

  2. In Reaction to… • “Big Process” • SEI Capability Maturity Model (CMM) • “Heavy” development practices • Hard to steer, unresponsive • Can we do better for smaller efforts?

  3. Extreme Programming • Kent Beck, late 90’s • One of several “Agile” processes • Small teams (2 to 8 people) • Modest projects • Emphasis on customer as project driver

  4. “Change Happens” • Embrace change as normal • Not an aberration whose cause needs to be found • Process must be lightweight and agile to respond to change • “Steer”able

  5. XP Core Values • Communication • Simplicity • Feedback • Courage (fearlessness)

  6. XP Practices • Pair programming • Test-first development • Simple design: Add no function before its time • Re-factoring • The planning game • User/client on-site

  7. XP Practices • Small releases • Continuous integration • Collective code ownership • Coding standards (and self-documenting code) • No overtime • System metaphor

  8. Why Agile Methods? • Why is change inevitable? • People… • People are noisy and unpredictable • Process involving people needs small steps, constant measurement to be steerable

  9. eXtreme Programming Try it … Further reading: “XP” by J. Highsmith

  10. Test-first development • If a class does not have automatic tests, you must assume it does not work • Regression testing … tests retain value • JUnit (Beck & Gamma): industrial-strength regression testing for the common man

  11. JUnit • Small, easy to learn, easy to use, effective • Java classes • TestCase, Suite, runners • 15 other language implementations • http://www.junit.org • http://www.xprogramming.com/software.htm

  12. JUnit Test Class • One test method per target method • “test anything that can break” … “don’t test anything that can’t” • Can we give better guidance? • Can we systematically produce consistent and complete test classes?

  13. The Planning Game • Informal brainstorming… few hours to a few days • Customer talks about what he/she wants • Engineers listen, ask questions, make “user stories” • Each story is a card, a few sentences, describes some function of the system

  14. The Planning Game • Engineers “cost” each story • Customer “values” each story • Rank order of cards • Customer selects top 4 or 5 items… • Engineers produce Release One

More Related