1. Extreme Programming Iterative programming Agile programming
Software developed in iterations
Software evolution becomes THE development technique
Agile programming
Iterative programming without excessive overhead (modeling, etc.), short releases

2. Extreme Programming Extreme programming
An example of agile development
is "a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements"

3. EXtreme Programming Everything is carried to extreme
if code reviews are good, review code all the time (pair programming)
if testing is good, test all the time (test-first)
if refactoring is good, refactor all the time
if simplicity is good, design with the simplest design that supports current functionality
if architecture is important, everybody works on defining and refining the architecture all the time
if integration testing is important, integrate and test several times a day
if short iterations are good, make the iterations extremely short (hours, days, weeks)

4. List of 12 specific practices
The planning game
Small releases
Metaphor
Simple design
Test first
Refactoring
Pair programming
Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards

5. The Rules and Practices
Planning: Feedback down to just minutes.
Designing: Simple, distributed across the team, based on oral tradition.
Coding: High quality from start to finish, team level development.
Testing: Two levels of testing, one for the customer and one for the developer.

6. The planning game Business decisions Technical decisions
Scope: which “stories” should be developed
Priority of stories
Technical decisions
Time estimates for features/stories
Elaborate consequences of business decisions
Team organization and process
Scheduling

7. Iteration Planning Customers choose stories to do.
Management determines the project velocity based on Yesterday’s Weather.
Developers break stories into tasks.
Developers estimate tasks.
Management calculates iteration content.
(Customers choose stories not to do.)

8. Simple design The “right” design No code duplication
Fewest possible classes and methods
Fulfills all current business requirements Design for today not the future

9. Small releases Put system into production ASAP
Fast feedback
Deliver valuable features first
Short cycle time
Planning 1-2 weeks is easier than planning 1-2 months
Releases should be
as small as possible
containing the most valuable business requirements
"coherent" (you can't release just for the sake of releasing)

10. Metaphor Metaphor How does the whole system work?
for example, the ATM, the contract
metaphor as shared verbal vision of architecture
architecture is boxes and connection
metaphor is holistic, and can be communicated
How does the whole system work?
What is the overall idea of the system?

11. Pair programming
In XP, programmers work in pairs, sitting together to develop code.
This helps develop common ownership of code and spreads knowledge across the team.
It serves as an informal review process as each line of code is looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from this.
Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

12. This Is Pair Programming

13. This is NOT Pair Programming

14. Does Pair Programming Really Work?
Empirical study by Laurie Williams at the university of Utah
Practice: Summer 1999
20 students (sophomore/junior)
All worked collaboratively
Generated more anecdotal/qualitative evidence
Solo vs. pair: Fall 1999
41 students (junior/senior)
28 worked collaboratively
13 worked individually
Quantitative: time, quality, enjoyment, confidence

15. Findings #1 - Quality

16. Findings #2 - Time

17. Findings #3 and #4 – Enjoyment and Confidence

18. How Does This Work? Pair-Pressure Pair-Think Pair-Relaying
Keep each other on task and focused
Don’t want to let partner down
“Embarrassed” to not follow the prescribed process
Pair-Think
Distributed cognition: “searching through larger spaces of alternatives”
Have shared goals and plans
Bring different prior experiences to the task
Different access to task relevant information
Must negotiate a common shared of action
Pair-Relaying
Each, in turn, contributes to the best of their knowledge and ability
Then, sit back and think while their partner fights on

19. How Does This Work (Part Two)?
Pair-Reviews
Continuous design and code reviews
Ultimate in defect removal efficiency
Removes programmers distaste for reviews
80% of all (solo) programmers don’t do them regularly or at all
Pair-Learning
Continuous reviews  learn from partners techniques, knowledge of language, domain, etc.
“Between the two of us, we knew it or could figure it out”
Apprenticeship
Defect prevention always more efficient than defect removal

20. Issues: Workplace Layout
Bad
Better
Best

21. Issues: Partner Picking Principles
Expert paired with an Expert
Expert paired with a Novice
Novices paired together
Professional Driver Problem
Culture

22. Issues: Pair Rotation Ease staff training and transition
Knowledge management/Reduced product risk
Enhanced team building

23. Pairing Difficulties Inability to schedule enough time together.
Unreliability of a partner.
Friction caused by different experience levels and/or rates of learning.
Unwillingness to raise these issues in a timely fashion.

24. Testing Automatic test drivers Write tests before production code
Unit tests  developer
Feature/acceptance tests  customer
Strong emphasis on regression testing
Unit tests need to execute all the time
Tests for completed features need to execute all the time
Unit tests pass 100%

25. Testing All code must have unit tests.
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.

26. Refactoring
Small changes that do not change the function of the program.
Increase design consistency.
Simplify as you go.
The design you need may not be the one you thought.
Bad smells -> refactoring

27. Refactoring Examples:
Remove duplicate code
Leverage existing code
Remove unused code
Refactoring mercilessly requires good unit tests and functional tests that can easily be executed
Goal: Keep design simple
Change bad design when you find it
Remove dead code
Refactoring:
If you are adding functionality – you are not refactoring! Although you may need to refactor before adding funtionality.
Metaphor example:
Pub/Sub system has
Publishers
Subscribers
Topics
Messages
Does not need to be overly abstracted.

28. Collective Ownership Nobody owns code Nobody owns design
Everybody takes responsibility for the whole of the system
not everyone knows every part equally well, but
everybody knows something about every part
everybody knows who to ask
anybody can change or improve anything at any time
The two are crucially interrelated
you can't know what's broken or can be improved unless you have the big picture in your mind

29. Continuous Integration
Every milestone is an integration milestone
A system of "build the pieces then integrate them at the last minute"
is classic divide and conquer
is doomed to failure
Short development cycle with integration at the end of every cycle

30. Continuous Integration
Integration happens after a few hours of development
Code is released into current baseline on integration machine
All tests are run
In case of errors:
Reverse to old version
Fix problems
Goto (1)

31. On-site customer
Many software projects fail because they do not deliver software that meets business needs
Real customer has to be part of the team
Defines business needs
Answers questions and resolves issues
Prioritizes features

32. Coding standards Team has to adopt a coding standard
Makes it easier to understand other people’s code
Avoids code changes because of syntactic preferences

33. Summary XP is a process based on a set of practices
The practices are based around the bigger ideas of flexibility and involvement, and are all interrelated
"Any one practice doesn't stand on its own. They require the other practices to keep them in balance."
For example, quick simple design can't work unless you
are able to make changes quickly
have a shared vision of the design
have the big picture in mind
Suitable for small teams, volatile requirements