eXtreme Programming

1
eXtreme Programming

• By Aaron Flocke, Leena Paulose, Geetha Krishna
  (Team 6)

2
What is XP?
3
XP is

• A set of rules\principles\practices used to
  rapidly develop high-quality software
• Tools not Rules -Ron Jeffries
• One of the more prominent lightweight
  software-engineering methodologies
• Main Goal Customer Satisfaction
• Highest quality in Lowest time frame.

4
XP emphasizes

• Communication
• Simplicity
• Feedback
• Courage
• Using 12 main principles, including
• Comprehensive unit tests
• Short release cycles
• Adding only whats needed for the current task
• Collective code ownership
• Pair programming

5
Where did XP come from?

• Father of XP Kent Beck
• Wrote Extreme Programming Explained Embracing
  Change
• Had years of experience in OOP such as Small Talk
  (at time of xP creation)
• Ward Cunningham
• Ron Jeffries

6
It all started

• Kent Beck developed XP back in 1996 while working
  at Daimler Chrysler
• Its use in developing the payroll system for D.C.
  is considered one of the great XP success
  stories.

7
Pros/Cons of XP

• Pros
• Handles changing requirements well
• Maximizes quality while minimizing time
• Cons
• Only works well with small groups (around a
  dozen)
• Many people dislike Pair Programming and think of
  it as overkill and a waste of resources

8
A more in depth look -gt

• And now my associates will give you all a more in
  depth look at XP so you can decide for yourself
  how useful or worthless XP is

9
Extreme Roles

• Customer
• writes explains user stories
• sets priorities, specifies tests
• may or may not be an end-user
• Programmer
• estimates stories
• defines tasks from stories
• implements stories and unit tests

• Tracker
• monitors progress
• keeps track of schedule
• Coach
• guides mentors the team
• watches the progress

10
Extreme Roles (contd.)

• Tester
• runs functional tests
• makes sure people know when test results decline.
• Doomsayer
• ensures that everybody knows the risks involved
• ensures that bad news isn't hidden, glossed over,
  or blown out of proportion

• Manager
• schedules meetings, passes results to tracker
• responsible to the Gold Owner.
• Gold Owner
• the person funding the project
• may or may not be the same as the Customer

11
Extreme Practices

• The Planning Process
• Simple Design
• System Metaphor
• Frequent, Small Releases
• On-site Customer
• 40 hr weeks

• Pair Programming
• Refactoring
• Test Driven Development
• Collective Code Ownership
• Continuous Integration
• Coding Standard

The 12 Golden Rules
12
XP Practice Cycle
13
XP Practices

• The Planning Process
• defines desired features briefly
• describes each feature's business value and
  priority
• helps estimate project cost
• Simple Design
• the best design is the easiest one that works
• a correct design must have
• no duplicate code
• fewest possible classes and methods
• meets the business value and expected
  functionality
• System Metaphor
• provide a broad view of the projects goal
• describes how the system should work, its
  functionality
• defines the overall theme to which developers and
  clients can relate

14
XP Practices

• Frequent, Small Releases
• develop and deliver the application in a series
  of frequently updated versions.
• provides frequent feedback
• On-site Customer
• integral part of the development effort.
• must be available at all times to set priorities,
  deliver
• and establish requirements, and answer
  questions.
• Sustainable Pace / 40 hr weeks
• avoid overtime
• re-examine schedule
• rested programmers fewer mistakes

15
Pair Programming

• all code is written in pairs
• programmer and observer
• code is simpler
• less defects found
• continuous code review
• software quality increases
• increases learning
• every programmer knows all aspects

16
Refactoring

• Refactoring is the process of changing a software
  system in such a
• way that it does not alter the external behavior
  of the code yet
• improves its internal structure
• The aim of refactoring is to
• constantly revise
• make the design simpler
• make the code more understandable
• improve the tolerance of code to change
• remove duplication,
• improve communication add flexibility
• Change it even if it is not broken!

17
XP Practices (contd.)

• Collective Code Ownership
• code belongs to the team
• encourages team to work closer
• everybody tries to produce a high-quality system
• Test Driven Development
• plays central role in XP
• each block is tested thoroughly
• 2 kinds - acceptance and unit test
• Continuous Integration
• immediate integration
• new system must pass all tests
• Coding Standard
• common naming formatting schemes
• makes pair progamming and collective code
  ownership easier
• rapid code sharing reduces the learning curve

18
XP Project - Phases
19
Stages of an XP Project

• Initiation
• Use stories
• Spike solutions
• Release Planning
• Release
• Iteration 1
• Development
• Deployment
• Acceptance Testing
• Iteration 2
• Development
• Deployment
• Acceptance Testing
• .
• .
• Iteration n

20
User Stories

• Short Description of the behavior of the system
• Customers point of view
• Customer terminology no technical terms
• One for each major feature of the system
• Create low-risk time estimates for the project
• Similar to Requirements Documents but not the
  same
• Different from Use Cases written by user, not
  programmer
• Average implementation time ( 2-3 weeks)
• 80 /- 20 stories sufficient to create a
  release plan.
• Printed on cards, similar to CRC cards.

21
Spike Solution

• Simple programs
• Explore solutions for tough technical / design
  problems
• Address only the problem under consideration
• Ignore other concerns
• If not good throw away

22
Release Planning

• Create release plan for the whole project ( 1-6
  months )
• Programmer provides estimates of 1,2 or 3 points
  for each story
• Customer decides which stories should be included
  in the release
• Customer decides the priorities of the stories
• Stories chosen for the release are arranged in
  1-3 week iteration
• High risk/high priority stories earlier
  iteration
• Release and iteration dates are fixed.

23
Iteration

• Iteration planning meeting-beginning of each
  iteration
• Each iteration 1-3 weeks
• For each iteration, user stories and failed tests
  are chosen
• Programmers break stories into tasks
• Programmers sign up for tasks and estimate time
  needed
• Programmers have a limitation on the task they
  can sign up for
• Can only sign up for as many points as were
  completed in the last iteration
• If the iteration is too long, Customer chooses
  stories to be put off for later iterations
  called Snow Plowing
• If iteration is too short, extra stories are
  added.

24
Acceptance Tests

• Same as Functional Tests determines if the
  system is acceptable
• Test First Principle Tests are written first
  and then code is written to pass the test
• No code goes into production without an
  associated test
• Tests determine what code to write
• Customers specify the conditions to be tested
• These conditions are taken from user stories
• For each user story, there can be 1 or more tests
• Test scores are published to the customers and
  programmers
• Failed tests become part of the next iteration