Extreme Programming, XP
Literature
Annika Silvervarg
• Extreme Programming Explained by Kent Beck
• Extreme Programming Pocket Guide by chromatic
Overview
•
•
•
•
What is XP
Values and principles
Practices
Workspace
Roles
What is XP?
• Values
– Large-scale criteria used to judge what we see, think and do
– Universal
• Principles
– Bridge the gap between values and practices
– Can be used to add practices
– Domain-specific guidelines
Values
•
•
•
•
•
Communication
Feedback
Simplicity
Courage
(Respect)
• Practices
– Things you actually do
– Intensely situated
1
Value – Communication
•
•
•
•
Honest, regular communication allows you to adjust
Customer – what to do, priorities
Developer – how things will be done and when
Communication create a sense of team and
cooperation
Value – Feedback
• Change creates the need for feedback
• Customer – test of prototypes, implemented features
• Developer – test of prototypes, test-driven
programming
• Strive to generate as much feedback as can be
handled as quickly as possible
Value – Simplicity
• Code for today
• Communication and Feedback should help decide
exactly what is needed
Value – Courage
• The courage to speak truths fosters communication
• The courage to discard failing solutions encourage
simplicity
• The courage to seek real, concrete answers creates
feedback
• If you made a mistake, admit it and then fix it
Value – Respect
• The contributions of each person on the team need to
be respected
• Respect your own work, strive for high quality
Principles
•
•
•
•
•
•
•
Humanity
Economics
Mutual benefit
Self-similarity
Improvement
Diversity
Reflection
•
•
•
•
•
•
Flow
Redundancy
Failure
Quality
Baby steps
Accepted responsibility
2
Principle – Humanity
• Developers are humans, with basic human needs:
–
–
–
–
–
Basic safety
Accomplishment
Belonging
Growth
Intimacy
• Balance the needs of individuals with the needs of the
team
Principle – Economics
• Development must have business value, meet
business goals and serve business needs, for
example solving the highest priority business need
first maximize the value of the project
• A dollar today is worth more than a dollar tomorrow,
earn money sooner and spend money later
– Pay-per-use – realize revenue from features as soon as they
are deployed
• Value as options for future (i.e. reuse)
– Enhance option value of team and software without
speculative flexibility
Principle – Mutual benefit
•
•
•
•
Every activity should benefit all concerned
Most important and most difficult
Benefit me now, me later and customer
Win-win practices like
Principle – Self-similarity
• Copy a structure (a solution) that works to another
context, even at different scales
• For example
– User stories and tests
– Test-drive programming
– Refactoring
– Coherent code style
Principle – Improvement
• Perfect is a verb (förbättra) not an adjective (perfekt)
• Get an activity started, do the best you can today, and
refine the solution over time
Principle – Diversity
• Teams need a variety of skills, attitudes and
perspectives
• Diversity often lead to conflict, i.e. many ways to look
at and solve a problem
• Remember respect and communication!
3
Principle – Reflection
• Do the work, think about how you do it, and why its
working (not working)
• Expose mistakes and learn from them
• Both shared in team and individually
Principle – Opportunity
• Problems are opportunities for change
• (Positive attitude/thinking)
Principle – Failure
• To try and fail provides knowledge
• If you don’t know the best way try all (or many)
Principle – Flow
• Continuous flow of activities rather than discrete
phases
• Integrate and deploy often
Principle – Redundancy
• Critical difficult problems should be handled in several
different ways (with many practices)
• For example, defects when coding are prevented
through pair programming, continuous integrations,
real customer involvement, test first programming etc.
Principle – Quality
• If you do not know the best way to do something – do
the best you can
• If you do know the best but it would take to long – do
the best you can in the time you got
4
Principle – Baby steps
Principle – Accepted responsibility
• Don’t do big changes in big steps
• What is the least you can do that is recognizable in the
right direction?
• Responsibility cannot be assigned – you decide if you
take responsibility or not
• With responsibility comes authority
Practices
eXtreme…
• Practices have purpose given values
• Practices are situation dependent
• Practices work well together
– The interaction between practices amplify their effects
Taking proven practices to the extreme:
• If testing is good, let everybody test all the time
• If code reviews are good, review all the time
• If design is good, refactor all the time
• If integration testing is good, integrate all the time
• If simplicity is good, do the simplest thing that could
possibly work
• If short iterations are good, make them really, really
short
The 12 Practices
• The Planning Game
– Release planning
– Iteration planning
• Common vocabulary
• Testing
– Acceptance tests
– Unit tests
• On-site Customer
•
•
•
•
•
•
•
•
Pair Programming
Simple Design
Coding Standards
Refactoring
Collective Ownership
Continuous Integration
Sustainable pace
Small Releases
Practices in workflow
•
•
•
•
•
•
•
•
•
•
•
•
Release planning (Planning game)
Iteration planning (Planning game)
Choose metaphor/vocabulary (Common vocabulary)
Write acceptance tests (Test-driven development)
Pair up (Pair programming)
Write unit test (Test-driven development)
Code (Code and Design Simply, Coding Standards)
Ask user for clarification (On-site customer)
Clean up (Refactoring, Collective code ownership)
Check in test and code (Continuous integration)
Go home after 8 hours (Sustainable pace)
Release (Small releases)
5
The Planning Game
• Goal: schedule the most important tasks
• Customer presents the desired features to the
programmers
• Programmers estimate their difficulty
• Customer lays out a plan for the project
Release planning – Step 1
•
Customers write user stories
– Each story represents a desired feature and all stories
represent the specification of the system
– About three sentences of text in the customers terminology
– Provide enough detail to make a reasonably estimate of
how long the story will take to implement
– Stories should be assigned business value: essential,
highly valuable or good idea
– Developers can suggest stories but the customer has
always final say
– Stories can be added, changed or deleted during the
project
User story template
• Title (one line describing the story)
• Narrative:
As a [role]
I want/can [feature]
(So that/because [benefit])
User story examples
Initial:
• The user can search for a book
After clarification:
• The user can search for a book by Title, and display
the result as a list
Release planning – Step 2
•
Developers estimate how long the stories might take
to implement
– Each story will get a 1, 2 or 3 days estimate in ideal
development time
– Longer than 3 days means that the customer need to break
the story down further and less than 1 day that it is at too
detailed a level, combine some stories
– Stories should be assigned technical risk: low, medium,
high
Release planning – Step 3
•
Together developers and customers move the cards
around on a large table to create a set of stories to
be implemented as the first/next release
– A useable, testable system that makes good business
sense delivered early is desired
– You may plan by time or by scope
•
•
either how many stories can be implemented before a given
date (time), or
how long a set of stories will take to finish (scope)
6
Iteration planning
• A practice whereby the team is given direction every
couple of weeks
• During Iteration Planning, the Customer presents the
features desired for the next iteration
• The programmers break them down into tasks, and
estimate their cost (at a finer level of detail than in
Release Planning)
• Based on the amount of work accomplished in the
previous iteration, the team signs up for what will be
undertaken in the current iteration
The Planning Game –
Advantages
• Reduction in time wasted on useless features
• Greater customer appreciation of the cost of a feature
• Less guesswork in planning
Testing
• Goal: prove that the code works as it should
• Acceptance tests test the functionality of the whole
system (customer)
• Unit tests test the components (developers)
• Once the test runs, the team keeps it running correctly
thereafter. This means that the system only improves,
always notching forward, never backsliding
Project velocity
• With six programmers and two-week iterations, a total
of 60 programmer-days (6 programmers x10 days) are
available
• With an initial velocity set to 1/3, a good start would be
to plan 20 ideal days worth of work in the iteration
The Planning Game –
Disadvantages
• Customer availability
• Is planning this often necessary?
Testing
• Unit Tests and Functional Tests
• Test a little, code a little…
– “Test-first programming”
• Tests become the specification
• Tests give confidence in the system
• Tests give courage to change the system
7
Acceptance test
• Acceptance tests are created from user stories
• During an iteration the user stories selected will be
translated into acceptance tests by the customer
• A story can have one or many acceptance tests, each
acceptance test represents some expected result from
the system
• Customers are responsible for verifying the
correctness of the acceptance tests and decide which
failed tests are of highest priority to fix in the next
iteration
Acceptance test examples
• User story – Search for book by Title
• The user can search for a book by Title, and display
the result as a list
• Acceptance test
Given a book title and a database where books with
this title exist,
When the user searches
Then the books with the title are displayed in a list
Testing – Advantages
• Unit testing promote testing completeness
• Test-first gives developers a goal
• Automation gives a suite of regression test
Acceptance test template
• Scenario 1: Title
• Narrative:
Given [context] (And [some more context]...)
When [event]
Then [outcome] (And [another outcome]...)
Acceptance test examples cont
• Acceptance test
Given a book title and a database where books with
this title are missing,
When the user searches
Then the message “No books that match the query” is
displayed
Testing – Disadvantages
• Automated unit testing isn’t for everything
• Reliance on unit testing isn’t a good idea
• A test result is only as good as the test itself
8
Common vocabulary
• Goal: communicate ideas about code clearly
• A common set of terminology
• Can use a metaphor (doughnut factory for message
delivery)
• Should be changed, simplified, clarified when needed
Metaphor – Disadvantages
• Often the metaphor is the system
• Another opportunity for miscommunication
• The system is often not well understood as a
metaphor
Metaphor – Advantages
• Encourages a common set of terms for the system
• Reduction of buzz words and jargon
• A quick and easy way to explain the system
Pair Programming
• Goal: spread knowledge, experience and ideas
• Pairs work together on (small) tasks
• Two different roles:
– Driver focus on details of the task,
– Navigator focus on project as whole
• Roles should be switched at intervalls
Pair Programming Benefits
• 15% less output than 2 solo programmers
• Continuous code review: better design, fewer
defects
• Confidence to add to or change the system
• Discipline to always test and refactor
• Teach each other how the system works
(reduced staffing risks)
• Learn from partner’s knowledge and experience
(enhances technical skills)
Pair Programming – 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?
9
Pair Programming –
Disadvantages
•
•
•
•
http://www.cenqua.com/pairon/
Many tasks really don’t require two programmers
A hard sell to the customers
Not for everyone
Simple Design – Advantages
•
•
•
•
Time is not wasted adding superfluous functionality
Easier to understand what is going on
Refactoring and collective ownership is made possible
Helps keeps programmers on track
Coding Standards
• Goal: communicate ideas clearly through code
• Start with existing style guides and naming
conventions
• Conventions that evolves with the project
• All code should look the same – ideally it should not
be possible to determine who coded what based on
the code itself
Code and Design Simply
• Goal: code that is easy to change
• Do the Simplest Thing That Could Possibly Work
–
–
–
–
Passes all the tests
No duplicate code (Once and Only Once)
States every intention
Fewest possible classes and methods (You Aren’t Gonna
Need It)
Simple Design – Disadvantages
• What is “simple?”
• Simple isn’t always best
Coding Standards – Advantages
• Reduces the amount of time developers spend
reformatting other peoples’ code
• Reduces the need for internal commenting
• Call for clear, unambiguous code
10
Coding Standards –
Disadvantages
• Degrading the quality of inline documentation
On-Site Customer – 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
Refactoring
• Goal: optimal code design
• Changing how the system does something but not
what is done
• Improves the quality of the system in some way
• Do it regularly
On-Site Customer
• Goal: handle business concerns accurately and
directly
• Customer set project’s goal and schedule
• Gives quick and continuous feedback to the
development team
• If impossible to have a customer on-site, a proxy may
be used instead
On-Site Customer –
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
Refactoring
• Design becomes everybody’s daily business
• Continuously improve quality of the code
• Unit Tests and Pair Programming give courage
Result:
• Fast development speed
• Code becomes easy to change
11
Refactoring – Advantages
• Prompts developers to proactively improve the product
as a whole
• Increases developer knowledge of the system
Collective Ownership
• Goal: spread responsibility to whole team
• The idea that all developers own all of the code
• Any developer can change any code if needed to
complete a task
• Enables refactoring
Collective Ownership Disadvantages
• Loss of accountability
• Limitation to how much of a large system that an
individual can practically “own”
Refactoring – Disadvantages
• Not everyone is capable of refactoring
• Refactoring may not always be appropriate
• Would upfront design eliminate refactoring?
Collective Ownership –
Advantages
• Helps mitigate the loss of a team member leaving
• Promotes developers to take responsibility for the
system as a whole rather then parts of the system
Continuous Integration
• Goal: reduce impact of adding new features
• Merge tasks and tests to whole as soon as they are
completed
• Code is not worked on without being integrated for
more than a day
12
Continuous Integration Advantages
• Reduces to lengthy process
• Enables the Small Releases practice
Sustainable pace
•
•
•
•
Goal: go home tired, but not exhausted
The work week should be limited to 40 hours
Time is fixed, adjust the scope if necessary
Regular overtime is a symptom of a problem and not a
long term solution
40-Hour Week - Disadvantages
• The underlying principle is flawed
• 40-Hours is a magic number
• Some may like to work more than 40-Hours
Continuous Integration –
Disadvantages
• The one day limit is not always practical
• Reduces the importance of a well-thought-out
architecture
40-Hour Week – Advantage
• Most developers lose effectiveness past 40-Hours
• Value is placed on the developers well-being
• Management is forced to find real solutions
Small Releases
• Goal: return customer’s investment often
• Small in terms of functionality
• Less functionality means releases happen more
frequently
• Frequent opportunities for evaluation and feed-back
• Reduce chance of overall project slippage
13
Small Releases – Disadvantages
• Not easy for all projects
• Not needed for all projects
• Versioning issues
•
•
•
•
Done
This week
This release
To be estimated
Future
• Big visible charts
• Supports: planning game
• Requires: simple design, comprehensive testing,
continual integration, planning game
Workspace
Workspace
Workspace
Workspace
Open space for the whole developer team
Small private spaces nearby or limited work hours
Provide overview of projects status and progress
Stories on a wall, sorted spatially in for example:
–
–
–
–
–
Practice – Release Regularly
• Portable workspace
–
–
–
–
User stories
Task cards
Acceptance tests
Charts
• Virtual workspace
– Use wiki, google docs, homepage …
Decide which aspects of informative workspace that
can be handled and how to compensate for others
14
Roles
•
•
•
•
•
•
•
Customer/User
Developer
Interaction designer
Tracker
Coach
Tester
And some more
Customer Bill of Rights
As the customer, you have the right to:
• An overall plan, to know what can be accomplished, when, and
at what cost
• Get the most possible value out of every programming week
• See progress in a running system, proven to work by passing
repeatable tests that you specify
• Change your mind, to substitute functionality, and to change
priorities without paying exorbitant costs
• Be informed of schedule changes, in time to choose how to
reduce scope to restore the original date, even cancel at any
time and be left with a useful working system reflecting
investment to date
Developer Bill of Rights
As the Developer, you have the right to:
• Know what is needed, with clear declarations of priority;
• Produce quality work at all times;
• Ask for and receive help from peers, superiors, and customers;
• Make and update your own estimates;
• Accept your responsibilities instead of having them assigned to
you.
Customer
•
•
•
•
Writes User Stories and specifies Acceptance Tests
Sets priorities, explains stories
May or may not be an end-user
Has authority to decide questions about the stories
Developer
• Estimates stories
• Defines Tasks from stories, and estimates
• Implements Stories and Unit Tests
Interaction designer
• Choose overall metaphors for the system
• Help users write stories, using their tools to
understand the users requirements
• Evaluate usage of the deployed system (to find more
stories)
+
• Lofi prototypes
• Usability
See Nielsen & Nodder report
15
Tracker
• Monitors Programmers’ progress, takes action if things
seem to be going off track
• Keeps track of project velocity, number of passing
tests, overtime
• Actions include setting up a meeting with Customer,
asking Coach or another Programmer to help
Coach
• Watches everything, makes sure the project stays on
course, that practices are followed
• Helps with anything
• Has experience and can guide/teach
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
• Pays for pizza
Tester
• Help customers write automated acceptance tests
• Write more detailed test during development
• 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
Gold owner
• The person funding the project, which may or may not
be the same as the Customer
16
Who benefits from XP?
Programmers
Customers
• get clear requirements &
priorities
• can do a good job
• can make technical
decisions
• don’t work overtime
• get most business value
first
• get accurate feedback
• can make informed
business decisions
• can change their mind
Why XP works
• Light-weight: discipline without bureaucracy
• Under stress, people do what is easiest
– All XP practices have short-term benefits as well as longterm benefits
• Development as a Conversation
• The code is the documentation
• XP is fun
XP – Advantages
•
•
•
•
•
Built-In Quality
Overall Simplicity
Programmer Power
Customer Power
Synergy Between Practices
XP – Disadvantages
•
•
•
•
•
Informal, little, or no documentation
Scalability
Contract Issues
Misconception on the cost of change
Tailoring
17