XP and Extreme Hour
Literature
Annika Silvervarg
• Extreme Programming Explained by Kent Beck
• Extreme Programming Pocket Guide by chromatic
What is XP
Values
•
•
•
•
•
eXtreme…
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
Communication
Feedback
Simplicity
Courage
(Respect)
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
Small Releases
Sustainable pace
1
The Planning Game
• Customer presents the desired features to the
programmers
– Each story represents a desired feature
– business value: essential, highly valuable or good idea
• Programmers estimate their difficulty
User story template
• Title (one line describing the story)
• Narrative:
As a [role]
I want/can [feature]
(So that/because [benefit])
– 1, 2 or 3 days estimate in ideal development time
– technical risk: low, medium, high
• Customer lays out a plan for the project
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
Iteration planning
• The Customer presents the features desired for the
next iteration
• The programmers break them down into tasks, and
estimate their cost
• Based on the amount of work accomplished in the
previous iteration, the team signs up for what will be
undertaken in the current iteration
Project velocity
Common vocabulary
• 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 (= 160 ideal hours) worth of work
in the iteration
• 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
2
Testing
Acceptance test
• 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
• 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
Unit Testing
On-Site Customer
• 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
• 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
– Product owner in Scrum
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
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)
3
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
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
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
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
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
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
4
•
•
•
•
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:
–
–
–
–
–
Done
This week
This release
To be estimated
Future
• Portable workspace
–
–
–
–
• Virtual workspace
– Trello, wiki, google docs, excel, homepage …
Decide which aspects of informative workspace that
can be handled and how to compensate for others
• Big visible charts
Roles
•
•
•
•
•
•
•
Customer/User
Developer
Interaction designer
Tracker
Coach
Tester
And some more
User stories
Task cards
Acceptance tests
Charts
Extreme hour
• 60 min to do a project in an XP way,
i.e. developing a product using XP practices:
–
–
–
–
–
–
–
–
–
The Planning Game
On-Site Customer
Short Releases
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
5
Teams
• Teams of about 7-8 people
• 2 customers and they should sit where they can talk
• 1-2 monitors that present the result and process at
end of class
• 4 developers on each team
Resources
• A place for each team to work, though this may just be
a corner of the class room
• 30 cards to each team
• A watch that tracks seconds
(even better, but not necessary, is a stopwatch)
Task
• The idea here is to "build" a coffee maker/mouse trap
to the specification of the customers, where build here
means that the developers will draw a picture of the
desired machine incrementally
• Customers specify functionality, and developers build
them by sketching
• The task will be carried out in three iterations
• While the teams are working the instructor may be
called upon to answer questions about the process.
Practices
• The Planning Game
– Write user stories (customer)
– Estimate time (developers)
– Choose scope for iteration (customer)
• On-Site Customer
– Can write new stories during an iteration to be added to next
iteration
– Answer clarification questions during development
• Simple Design
– Draw only the required feature, not the complete picture
Practices
• Pair Programming
– 2 pairs of developers, where one is driver (has pen) and one
is navigator (switch after each task)
• Continuous Integration
– Integrate after each task
Practices
• Testing
– Customers do acceptance test of features after each
iteration (be critical)
• Short Releases
– Release after 2 iterations
• Collective Ownership
– Everyone can change existing features if necessary to
complete current task
• Refactoring
• Customers can get new ideas midway and change
thei minds!
– Redo the complete design when needed
6
Exercise outline
• Release planning (10 minutes)
– Customers decide what they want and write user stories –
one feature per card
– Developers get the user stories as soon as they are written
• When they get a card, they estimate its time in ideal minutes
(1,2 or 3) and give it back to Customers
• If a user story is unclear they ask the customer for clarification
• If a user story is too big they ask the customer that the user
story is split
Exercise outline
• Iteration planning (5 minutes)
– Developers announce the velocity for the next peroid,
for example out of 10 min, 8 min can be used for
development, velocity = 0.8
– Customers choose the most desirable features up to a time
limit determined and announced by developers.
For example 2 pairs x velocity x 10 min = 16 min
• Iteration developing (10 minutes)
– Developers draw features corresponding to user stories
• Consult with customers as needed
• Draw separate features!
• Continous integration!
Exercise outline
• Testing (5 minutes)
• Discuss your experience of the exercise (15 min)
– Acceptance tests
– Usability tests?
• Iteration planning (5 minutes)
–
–
–
–
Exercise outline
Customer can write new user stories
Developers estimate new cards if any
Developers state a new velocity
Customers choose user stories
• Developing (10 minutes) As above
• Take a 15 min break
– How were XP values followed: communication, feed-back, simplicity,
courage?
– How were XP practices followed: On-site customer, Planning game,
Release regularly, Sustainable pace, Design Simply, Refactor, Common
Vocabulary, Pair programming, Collective ownership, Continuous
integration?
– Have the exercise shown any advantage and disadvantaged of XP?
– What knowledge and experiences can you bring from the exercise to the
real project?
• Draw the result on the whiteboard
• Monitor presents your discussion
Time
•
•
•
•
14.30-15.15 Exercise
15.15-15.30 Break
15.30-15.45 Reflections
15.45- Presentation
7