Extreme Programming (XP)

XP originated in mid 1990s by Kent Beck in collaboration with Ward Cunningham. It was first used in project Daimler Chrysler in 1996. XP practice is not new but how they interact is.

Extreme comes from taking the principles and practices to extreme lengths.

In a survey, it was found that 40% of the projects were late by 67% and 30% were over budget by an average of 127%. It is because of false assumptions about development process:

  • all requirements can be captured at start
  • requirements will not change significantly
  • complete architectural design can be specified start
  • developers will not take shortcuts in the process
  • developers must be rigidly controlled
XP improves a software project by addressing:
  • communication
  • simplicity
  • feedback
  • courageness
XP - New Terms
  • User Stories - functional requirements
  • Spikes - throwaway prototype
  • Velocity - measure of how much work is being done
  • CRC - Class, Responsibility, Collaboration cards
  • Re-factoring - evolving software architecture
  • Metaphor - picture of the system
  • Test Driven Development
XP Core Practices
  1. small and frequent releases
  2. continual planning of software release
  3. use of metaphor
  4. simple design
  5. continual testing (Test Driven Development)
  6. pair programming
  7. constant refactoring
  8. collective ownership
  9. continuous integration
  10. sustainable pace - max 40 hours/week
  11. use of coding standards
  12. collective coding

XP Roles
  • Manager - Overall Project Manager
  • Tracker - Monitor estimates and iteration progress
  • Consultant - external technical expert
  • Coach - expert in XP Process
  • Customer - writes stories, tests, and decides priorities
  • Programmer - design, write and test code
  • Tester - assist customer to write functional tests, run tests, maintain testing tools
XP Evaluation
  • Bottom-Up - design evolves through refactoring
  • designed for projects where requirements are initially unknown and/or continually changing
  • only suitable for small, co-located teams (2-10 developers)
  • testing is paramount - Test Driven Development
  • collective code ownership
  • minimal documentation e.g. no requirement specs
  • relies on the user knowing what they want
  • constant small software releases
  • emphasis on people and realistic timelines