• Kap 13 ur SCRUM and XP from the trenches
• Extreme Programming Explained by Kent Beck
• Extreme Programming Pocket Guide by chromatic
• Communication
• Feedback
• Simplicity
• Courage
• (Respect)
• 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
1

• 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
• XP planning addresses two key questions:
– predicting what will be accomplished by the due date
– determining what to do next
• The emphasis is on steering the project rather than on exact prediction of what will be needed and how long it will take
• There are two key planning steps in XP, addressing these two questions:
– Release planning
– Iteration planning
• 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
– 1, 2 or 3 days estimate in ideal development time
– technical risk: low, medium, high
• Customer lays out a plan for the project
• The Customer presents the features desired for the next iteration
• The programmers break them down into tasks, and estimate their cost
– 1, 2 or 3 hours estimate in ideal development time
• Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration
– Velocity = completed stories/tasks divided by actual hours
– Scope = velocity * time * pairs
• 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

• 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 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
• 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
• 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

• 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
• 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
• 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
• 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
• 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
• 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
4

• Write/Update, prioritise and choose a selection of user stories
(Planning game)
• Write acceptance tests (Test-driven development)
• Choose task (Planning game)
• 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 (Refactor Mercilessly, Collective code ownership)
• Check in code (Continuous integration, Collective code ownership)
• Go home after 8 hours (Sustainable pace)
• Release after a short time period (Small releases)
www.extremeprogramming.org
• 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 of about 6-10 people
• 2 customers and they should sit where they can talk
• 1-2 monitors that present the result and process at end of class
• 3-6 developers on each team
• 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)
• 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 two iterations
• While the teams are working the instructor may be called upon to answer questions about the process
• 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
• 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
• Collective Ownership
– Everyone can change existing features if necessary to complete current task
• Refactoring
– Redo the complete design when needed
• Testing
– Customers do acceptance test of features after each iteration (be critical)
• Short Releases
– Release after 2 iterations
• Customers can (should) get new ideas midway and change their minds!
6

• 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
• 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!
• Testing (5 minutes)
– Acceptance tests
– Usability tests?
• Iteration planning (5 minutes)
– 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
• Discuss your experience of the exercise (15 min)
– 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
• The monitor presents your discussion
7