Professional Documents
Culture Documents
(XP)
Introduction Extreme Programming?
An agile development methodology XP is “a light-
weight methodology for small to medium-sized
teams developing software in the face of vague or
rapidly changing requirements
It works by bringing the whole team together in the
presence of simple practices, with enough feedback
to enable the team to see where they are and to
tune the practices to their unique situation?
Created by Kent Beck in the mid 1990’s
A set of 12 key practices taken to their “extremes”
A mindset for developers and customers
Extreme Programming
Hence XP is a lightweight (agile) process:
Instead of lots of documentation nailing down what
customer wants up front, XP emphasizes plenty of
feedback
Embrace change: iterate often, design and
redesign, code and test frequently, keep the
customer involved
Deliver software to the customer in short (2 week)
iterations
Eliminate defects early, thus reducing costs
XP MODEL
(from www.extremeprogramming.org)
XP emphasizes iteration
XP emphasizes communication
Test-driven development
Four Core Values of XP
Communication
Simplicity
Feedback
Courage
XP Practices
The Planning Game
Small Releases
Metaphor
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-Hour Workweek
On-site Customer
Coding Standards
The Planning Game
Planning for the upcoming iteration
Uses stories provided by the customer
Technical persons determine schedules, estimates, costs, etc
A result of collaboration between the customer and the
developers
Advantages
Reduction in time wasted on useless features
Greater customer appreciation of the cost of a feature
Less guesswork in planning
Disadvantages
Customer availability
Is planning this often necessary?
Small Releases
Small in terms of functionality
Less functionality means releases happen more frequently
Support the planning game
Advantages
Frequent feedback
Tracking
Reduce chance of overall project slippage
Disadvantages
Not easy for all projects
Not needed for all projects
Versioning issues
Metaphor
Advantages
Prompts developers to proactively improve the product as a whole
Increases developer knowledge of the system
Disadvantages
Not everyone is capable of refactoring
Refactoring may not always be appropriate
Would upfront design eliminate refactoring?
Pair Programming
Two Developers, One monitor, One Keyboard
One “drives” and the other thinks
Switch roles as needed
Advantages
Two heads are better than one
Focus
Two people are more likely to answer the following questions:
Is this whole approach going to work?
What are some test cases that may not work yet?
Is there a way to simplify this?
Disadvantages
Many tasks really don’t require two programmers
A hard sell to the customers
Collective Ownership
Disadvantages
The one day limit is not always practical
Reduces the importance of a well-thought-out architecture
40-Hour Week
The work week should be limited to 40 hours
Regular overtime is a symptom of a problem and not a long
term solution
Advantages
Most developers lose effectiveness past 40-Hours
Value is placed on the developers well-being
Management is forced to find real solutions
Disadvantages
The underlying principle is flawed
40-Hours is a magic number
Some may like to work more than 40-Hours
On-Site Customer
Acts to “steer” the project
Gives quick and continuous feedback to the development team
Advantages
Can give quick and knowledgeable answers to real development
questions
Makes sure that what is developed is what is needed
Functionality is prioritized correctly
Disadvantages
Difficult to get an On-Site Customer
The On-Site customer that is given may not be fully knowledgeable about what
the company
May not have authority to make many decisions
Loss of work to the customer’s company
Coding Standards
All code should look the same
It should not possible to determine who coded what
based on the code itself
Advantages
Reduces the amount of time developers spend reformatting
other peoples’ code
Reduces the need for internal commenting
Call for clear, unambiguous code
Disadvantages
Degrading the quality of inline documentation
Extreme Programming Roles
Customer
Writes User Stories and specifies Functional Tests
Sets priorities, explains stories
May or may not be an end-user
Has authority to decide questions about the stories
Programmer
Estimates stories
Defines Tasks from stories, and estimates
Implements Stories and Unit Tests
Coach
Watches everything, sends obscure signals, makes sure
the project stays on course
Helps with anything
XP Roles continued
Tracker
Monitors Programmers’ progress, takes action if things seem to be
going off track.
Actions include setting up a meeting with Customer,
Coach or another Programmer to help
Tester
Implements and runs Functional Tests (not Unit Tests!)
Graphs results, and 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
XP Roles continued
Manager
Schedules meetings (e.g. Iteration Plan, Release Plan), makes
sure the meeting process is followed, records results of meeting
for future reporting, and passes to the Tracker
Possibly responsible to the Gold Owner.
Goes to meetings, brings back useful information
Gold Owner
The person funding the project, which may or may not be the
same as the Customer
Extreme Programming
Activities
Coding: You code because if you don't code, at the end of the day
you haven't done anything.
Testing: You test because if you don't test, you don't know when
you are done coding
Listening: You listen because if you don't listen you don't know
what to code or what to test
Designing: And you design so you can keep coding and testing and
listening indefinitely (good design allows extension of the system
with changes in only one place)
Release Planning Phases
Exploration Phase: In this phase the customer will provide a
shortlist of high-value requirements for the system. These will be
written down on user story cards.
Commitment Phase: Within the commitment phase customer and
developers will commit themselves to the functionality that will be
included and the date of the next release.
Steering Phase: In the steering phase the plan can be adjusted,
new requirements can be added and/or existing requirements can
be changed or removed
Exploration Phase
Iterative process of gathering requirements and estimating the work
impact of each of those requirements.
Write a Story:
Customer has come with a problem; during a meeting, Developer
will try to define this problem and get requirements. Based on the
business problem, a story (user story) has to be written. This is
done by Customer, where they point out what they want a part of
the system to do. It is important that developer has no influence on
this story. The story is written on a user story card.
Roles : Customer , Developer
Artifact : User Stories
Exploration Phase
Estimate a Story: Developer estimates how long it will
take to implement the work implied by the story card.
Developer can analyze or solve the problem. These
solutions are used for estimation and discarded once
everyone gets clear visualization of the problem. Again,
this may not influence the business requirements.
Split a Story: Design critical complexity has to be
addressed before starting the iteration planning. If
developer isn't able to estimate the story, it needs to be
split up and written again.
Commitment phase
This phase involves the determination of costs, benefits,
and schedule impact. It has four components:
Sort by Value: Customer sorts the user stories by business
value
Sort by Risk: Developer sorts the stories by risk.
Set Velocity: Developer determines at what speed they can
perform the project.
Choose scope: The user stories that will be finished in the next
release will be picked. Based on the user stories the release
date is determined.
Steering phase
Within the steering phase the developer
and customer can "steer" the process.
That is to say, they can make changes.
Individual user stories, or relative priorities
of different user stories, might change;
estimates might prove wrong. This is the
chance to adjust the plan accordingly.
Iteration Planning
Plans the activities and tasks of the
developers. In this process the customer
is not involved..
Role : Developers
3 Phases of Iteration Planning
Iteration Planning Phases
Exploration Phase: requirement will be translated to different tasks.
The tasks are recorded on task cards.
Steering Phase: The tasks are performed and the end result is
matched with the original user story
Exploration phase
It is about creating tasks and estimating their
implementation time.
Translate the requirement to tasks: Place on task cards.
Combine/Split task: If the programmer cannot estimate
the task because it is too small or too big, the
programmer will need to combine or split the task.
Estimate task: Estimate the time it will take to implement
the task
Commitment phase
Within the commitment phase of the iteration planning
programmers are assigned tasks that reference the different
user stories.
Set load factor: The load factor represents the ideal amount of
hands-on development time per programmer within one
iteration. For example, in a 40-hour week, with 5 hours
dedicated to meetings, this would be no more than 35 hours.