Introduction To Extreme Programming

Introduction To Extreme Programming

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