Introduction to Introduction to eXtreme ProgrammingeXtreme Programming
www.talkwiseconsulting.com
ContentsContents
� The problem
◦ Problems in software development
� eXtreme Programming (XP)
◦ Values◦ Values
◦ Practices
◦ Why XP works
◦ Benefits of XP
� Conclusions
� Resources
Problems in Problems in software developmentsoftware development
Risks:
� Schedule slips
� Business misunderstood� Business misunderstood
� Defect rate
� Project cancelled
� System goes sour
� Business changes
Schedule slipsSchedule slips
� Many projects are not delivered on time◦ Examples: Word 1.0, Netscape 6
� Some deadlines cannot be moved◦ Example: Y2K
�What if:
most business value is delivered on time
Business misunderstoodBusiness misunderstood
�Without direct communication, developers have to guess what the customer wants.
◦ Example: The Orthodontics Project◦ Example: The Orthodontics Project
�What if:
an on-site customer steers development
Defect rateDefect rate
� The software is put in production, but the defect rate is so high that it isn’t used.
�What if: you have automated testing�What if: you have automated testing
Project cancelledProject cancelled
Size of project Early On-Time Delayed Cancelled Sum
1 function point 14.68% 83.16% 1.92% 0.25% 100.00%
10 function points 11.08% 81.25% 5.67% 2.00% 100.00%
100 function points 6.06% 74.77% 11.83% 7.33% 100.00%
1,000 function points 1.24% 60.76% 17.67% 20.33% 100.00%
10,000 function points 0.14% 28.00% 23.83% 48.00% 100.00%
100,000 function points 0.00% 13.67% 21.33% 65.00% 100.00%
Average 5.53% 56.94% 13.71% 23.82% 100.00%
Table 1: Percentage of projects early, on-time, late, canceled(from Patterns of Software Systems Failure and Success, by Capers Jones)
Project cancelledProject cancelled
�What if:
short releases deliver at least some useful working software, reflecting investment to working software, reflecting investment to date
System goes sourSystem goes sour
� Software is put into production successfully, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.the system must be replaced.
�What if:
the design is simple and the code quality is high
Business changesBusiness changes
� New laws, market changes: business priorities change
�What if:
the customer can change their mind, substitute functionality, and change priorities
Economics of Economics of software developmentsoftware development
cost of change
Requirements Analysis Design Implementation Testing Production
What if…What if…
cost of change
Time
eXtreme ProgrammingeXtreme Programming
� A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to quality software, and then evolving it to meet changing business needs.
eXtreme…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 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
XP valuesXP values
� Communication
� Simplicity � Simplicity
� Feedback
� Courage
XP practicesXP practices
� The Planning Game*
� Small Releases
� Metaphor
� Collective Ownership
� Continuous Integration
� 40-Hour Week� Metaphor
� Simple Design*
� Testing*
� Refactoring*
� Pair Programming*
� 40-Hour Week
� On-Site Customer
� Coding Standards
� Open workspace
� Daily Schema migration
The Planning GameThe Planning Game
� Business writes a story describing desired functionality
� Stories are written on index cards� Development estimates stories� Development estimates stories� Velocity determines number of stories per iteration
� Business splits and prioritizes stories and determines the composition of releases
� Velocity is measured and adjusted every iteration� Customer steers development
TestingTesting
� Unit Tests and Functional Tests
� Test a little, code a little…
◦ “Test-first programming”
� Tests become the specification� Tests become the specification
� Tests give confidence in the system
� Tests give courage to change the system
Unit testsUnit tests
Pair ProgrammingPair Programming
� Two people looking at one machine, with one keyboard and one mousemouse
� Two roles: implementation and strategy
� All production code is written in pairs
Pair Programming BenefitsPair Programming Benefits
� 15% less output than 2 solo programmers
� Continuous code review: better design, fewer defects
� Confidence to add to or change the system� 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)
Simple designSimple design
Do the simplest thing that could possibly work
� Passes all the tests
� No duplicate code
� States every intention
� Fewest possible classes and methods
RefactoringRefactoring
� 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
Why XP worksWhy XP works
� Light-weight: discipline without bureaucracy
� Under stress, people do what is easiest
◦ All XP practices have short-term benefits as well ◦ All XP practices have short-term benefits as well as long-term benefits
� Development as a Conversation
� The code is the documentation
� XP is fun
Who benefits from XP?Who benefits from XP?
� get clear requirements & priorities
can do a good job
� get most business value first
get accurate feedback
Programmers: Customers:
� can do a good job
� can make technical decisions
� don’t work overtime
� get accurate feedback
� can make informed business decisions
� can change their mind
ConclusionsConclusions
� Use XP on projects◦ with vague or changing requirements
◦ with small teams
� XP works, and is very fast
XP is fun to execute� XP is fun to execute
� At Azzurri, we use XP as much as possible with clients, and exclusively for internal projects
XP books and papersXP books and papers
� Extreme Programming Explained – Kent Beck� Refactoring – Martin Fowler� Planning Extreme Programming – Kent Beck et al� Extreme Programming Installed – Ron Jeffries et al� Extreme Programming Examined – Giancarlo Succi et al� Extreme Programming Examined – Giancarlo Succi et al� Extreme Programming in Practice – Robert C. Martin et al� Extreme Programming Explored –William C. Wake� Extreme Programming Applied – Ken Auer et al� The Costs and Benefits of Pair Programming – Alistair Cockburn et al
Web resourcesWeb resources
� www.junit.org
� www.xprogramming.com
� www.extremeprogramming.org
� www.refactoring.com� www.refactoring.com
� www.pairprogramming.com
Thank youThank youThank youThank you