Your SlideShare is downloading. ×
Introduction To Extreme Programming
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction To Extreme Programming


Published on

An overview of Extreme Programming.

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Introduction to Extreme Programming Joe Drumgoole 10-December-2004
  • 2. What is Extreme Programming?
    • 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 Agile Software 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 – The Players
    • 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 - Coding
    • Customer 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
  • 8. XP - Design
    • The Simplest Possible Solution
    • Spike solutions for thorny situations
    • Refactor for simplicity and clarity
    • No Design for tomorrow
  • 9. XP - Testing
    • Test 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 Development
    • Write 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 - Problems
    • Many customers
    • No Customer
    • Reluctant Customer
    • Team skill set
    • Release Constraints
    • User Training
    • No time for tests
    • Architecture Astronautics
    • Waterfall Documentation
  • 12. Conclusions
    • XP has a proven track record
    • Its easy to implement
    • Has excellent tool support
    • Might be a good fit at Oracle if we can engage our customers!