Introduction To Extreme Programming


Published on

An overview of Extreme Programming.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction To Extreme Programming

  1. 1. Introduction to Extreme Programming Joe Drumgoole 10-December-2004
  2. 2. What is Extreme Programming? <ul><li>Doing things we know work to the extreme! </li></ul><ul><li>Testing is Good – </li></ul><ul><ul><li>Write tests for everything </li></ul></ul><ul><ul><li>Write tests first </li></ul></ul><ul><ul><li>Write tests that fail and then fix them </li></ul></ul><ul><li>Code Review is Good – </li></ul><ul><ul><li>Review every line of code by ensuring that all code is written by programmers working in pairs (pair-programming) </li></ul></ul><ul><li>Integration is Good – </li></ul><ul><ul><li>Integrate as often as possible (daily, hourly builds) </li></ul></ul><ul><ul><li>Use tests to identify regressions </li></ul></ul>
  3. 3. Manifesto for Agile Software Development <ul><li>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: </li></ul><ul><ul><li>Individuals and interactions over processes and tools </li></ul></ul><ul><ul><li>Working software over comprehensive documentation </li></ul></ul><ul><ul><li>Customer collaboration over contract negotiation </li></ul></ul><ul><ul><li>Responding to change over following a plan </li></ul></ul><ul><li>That is, while there is value in the items on the right,we value the items on the left more </li></ul>
  4. 4. XP – The Players <ul><li>The Customer </li></ul><ul><ul><li>Onsite </li></ul></ul><ul><ul><li>Engaged </li></ul></ul><ul><ul><li>Writes user stories </li></ul></ul><ul><ul><li>Defines Priorities </li></ul></ul><ul><li>The Programmer </li></ul><ul><ul><li>Volunteers to implement specific stories </li></ul></ul><ul><ul><li>Provides estimates </li></ul></ul><ul><ul><li>Splits stories where required </li></ul></ul><ul><ul><li>Identifies risks/difficulties </li></ul></ul><ul><ul><li>Implements </li></ul></ul><ul><li>The Project Manager </li></ul><ul><ul><li>Removes obstacles </li></ul></ul><ul><ul><li>Tracks Progress </li></ul></ul><ul><ul><li>Plots Project Velocity </li></ul></ul>
  5. 5. XP – Planning – User Stories <ul><li>Requirements = User Stories </li></ul><ul><li>User Stories are :- </li></ul><ul><ul><li>Short (Capture on a post-it sized note) </li></ul></ul><ul><ul><li>High level </li></ul></ul><ul><ul><li>Always express end-user functionality and/or features </li></ul></ul><ul><li>User Stories are always written by the Customer </li></ul><ul><li>User Stories lead to the creation of Acceptance Tests </li></ul><ul><li>Acceptance Tests are executable demonstrations of features </li></ul><ul><li>The complete set of stories is then used to create Release Plan </li></ul>
  6. 6. XP – Planning – Release Planning <ul><li>Each programmer gives an estimate as to the time need to complete a given story </li></ul><ul><li>The development cycle is divided into Iterations </li></ul><ul><li>Each iteration should span about 2 to 3 weeks </li></ul><ul><li>Programmers plan each iteration when it starts </li></ul><ul><li>Customer assigns priority at the start of each iteration </li></ul><ul><li>Number of Stories per Iteration = Project Velocity </li></ul><ul><li>Project Velocity for the next iteration is defined by what happened in the last iteration </li></ul>
  7. 7. XP - Coding <ul><li>Customer is always available </li></ul><ul><li>Coding is to agreed standards </li></ul><ul><li>Test driven development </li></ul><ul><li>Code is written in pairs (Pair Programming) </li></ul><ul><li>Code is owned by everybody </li></ul><ul><li>One pair integrates at a time </li></ul><ul><li>Integration is continuous throughout the project </li></ul><ul><li>NO OVERTIME </li></ul>
  8. 8. XP - Design <ul><li>The Simplest Possible Solution </li></ul><ul><li>Spike solutions for thorny situations </li></ul><ul><li>Refactor for simplicity and clarity </li></ul><ul><li>No Design for tomorrow </li></ul>
  9. 9. XP - Testing <ul><li>Test Driven Development </li></ul><ul><ul><li>Inverts your point of view </li></ul></ul><ul><ul><li>Forces you to think about integration </li></ul></ul><ul><ul><li>Leads to cleaner interfaces </li></ul></ul><ul><ul><li>Tests prove existence </li></ul></ul><ul><li>All code must pass unit tests prior to integration </li></ul><ul><li>All bugs lead to unit tests </li></ul><ul><li>GUIs are code free, put the code in the model </li></ul><ul><li>Acceptance Tests are run weekly and the score is a progress measure </li></ul><ul><li>What to test ? Test everything that might break </li></ul>
  10. 10. Test Driven Development <ul><li>Write Tests First </li></ul><ul><li>Tests force user view/integration view/interface view </li></ul><ul><li>Tests demonstrate progress </li></ul><ul><li>Tests prove existence </li></ul><ul><li>Automated test for everything that could break </li></ul>
  11. 11. XP - Problems <ul><li>Many customers </li></ul><ul><li>No Customer </li></ul><ul><li>Reluctant Customer </li></ul><ul><li>Team skill set </li></ul><ul><li>Release Constraints </li></ul><ul><li>User Training </li></ul><ul><li>No time for tests </li></ul><ul><li>Architecture Astronautics </li></ul><ul><li>Waterfall Documentation </li></ul>
  12. 12. Conclusions <ul><li>XP has a proven track record </li></ul><ul><li>Its easy to implement </li></ul><ul><li>Has excellent tool support </li></ul><ul><li>Might be a good fit at Oracle if we can engage our customers! </li></ul>