Introduction toeXtreme Programming    www.talkwiseconsulting.com
ContentsThe problem◦ Problems in software developmenteXtreme Programming (XP)◦   Values◦   Practices◦   Why XP works◦   Be...
Problems in software developmentRisks: Schedule slips Business misunderstood Defect rate Project cancelled System goes sou...
Schedule slips Many projects are not delivered on time ◦ Examples: Word 1.0, Netscape 6 Some deadlines cannot be moved ◦ E...
Business misunderstood Without direct communication, developers have to guess what the customer wants. ◦ Example: The Orth...
Defect rate The software is put in production, but the defect rate is so high that it isn’t used. What if: you have automa...
Project cancelled      Size of project      Early   On-Time      Delayed     Cancelled           Sum       1 function poin...
Project cancelled What if: short releases deliver at least some useful working software, reflecting investment to date
System goes sourSoftware is put into production successfully, butafter a couple of years the cost of makingchanges or the ...
Business changesNew laws, market changes: businesspriorities changeWhat if:the customer can change their mind,substitute f...
Economics ofsoftware development         cost of change Requirements   Analysis   Design   Implementation   Testing   Prod...
What if…    cost of change                     Time
eXtreme Programming A system of practices that a community of software developers is evolving to address the problems of q...
eXtreme…Taking proven practices to the extreme  If testing is good, let everybody test all the time  If code reviews are g...
XP valuesCommunicationSimplicityFeedbackCourage
XP practicesThe Planning Game*   Collective OwnershipSmall Releases       Continuous IntegrationMetaphor             40-Ho...
The Planning GameBusiness writes a story describing desiredfunctionalityStories are written on index cardsDevelopment esti...
Testing Unit Tests and Functional Tests Test a little, code a little… ◦ “Test-first programming” Tests become the specific...
Unit tests
Pair Programming Two people looking at one machine, with one keyboard and one mouse Two roles: implementation and strategy...
Pair Programming Benefits15% less output than 2 solo programmersContinuous code review: better design, fewerdefectsConfide...
Simple designDo the simplest thing that could possibly work Passes all the tests No duplicate code States every intention ...
Refactoring Design becomes everybody’s daily business Continuously improve quality of the code Unit Tests and Pair Program...
Why XP worksLight-weight: discipline without bureaucracyUnder stress, people do what is easiest◦ All XP practices have sho...
Who benefits from XP?Programmers:              Customers:   get clear requirements    get most business   & priorities    ...
Conclusions Use XP on projects ◦ with vague or changing requirements ◦ with small teams XP works, and is very fast XP is f...
XP books and papersExtreme Programming Explained – Kent BeckRefactoring – Martin FowlerPlanning Extreme Programming – Kent...
Web resources www.junit.org www.xprogramming.com www.extremeprogramming.org www.refactoring.com www.pairprogramming.com
Thank you
Upcoming SlideShare
Loading in …5
×

Extreme programming talk wise consulting - www.talkwiseconsulting

7,509 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,509
On SlideShare
0
From Embeds
0
Number of Embeds
6,520
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Extreme programming talk wise consulting - www.talkwiseconsulting

  1. 1. Introduction toeXtreme Programming www.talkwiseconsulting.com
  2. 2. ContentsThe problem◦ Problems in software developmenteXtreme Programming (XP)◦ Values◦ Practices◦ Why XP works◦ Benefits of XPConclusionsResources
  3. 3. Problems in software developmentRisks: Schedule slips Business misunderstood Defect rate Project cancelled System goes sour Business changes
  4. 4. Schedule 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
  5. 5. Business misunderstood Without direct communication, developers have to guess what the customer wants. ◦ Example: The Orthodontics Project What if: an on-site customer steers development
  6. 6. Defect 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
  7. 7. Project 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)
  8. 8. Project cancelled What if: short releases deliver at least some useful working software, reflecting investment to date
  9. 9. System goes sourSoftware is put into production successfully, butafter a couple of years the cost of makingchanges or the defect rate rises so much thatthe system must be replaced.What if:the design is simple and the code quality is high
  10. 10. Business changesNew laws, market changes: businesspriorities changeWhat if:the customer can change their mind,substitute functionality, and change priorities
  11. 11. Economics ofsoftware development cost of change Requirements Analysis Design Implementation Testing Production
  12. 12. What if… cost of change Time
  13. 13. eXtreme 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 meet changing business needs.
  14. 14. 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
  15. 15. XP valuesCommunicationSimplicityFeedbackCourage
  16. 16. XP practicesThe Planning Game* Collective OwnershipSmall Releases Continuous IntegrationMetaphor 40-Hour WeekSimple Design* On-Site CustomerTesting* Coding StandardsRefactoring* Open workspacePair Programming* Daily Schema migration
  17. 17. The Planning GameBusiness writes a story describing desiredfunctionalityStories are written on index cardsDevelopment estimates storiesVelocity determines number of stories periterationBusiness splits and prioritizes stories anddetermines the composition of releasesVelocity is measured and adjusted every iterationCustomer steers development
  18. 18. 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
  19. 19. Unit tests
  20. 20. Pair Programming Two people looking at one machine, with one keyboard and one mouse Two roles: implementation and strategy All production code is written in pairs
  21. 21. Pair Programming Benefits15% less output than 2 solo programmersContinuous code review: better design, fewerdefectsConfidence to add to or change the systemDiscipline to always test and refactorTeach each other how the system works (reducedstaffing risks)Learn from partner’s knowledge and experience(enhances technical skills)
  22. 22. Simple designDo the simplest thing that could possibly work Passes all the tests No duplicate code States every intention Fewest possible classes and methods
  23. 23. Refactoring Design becomes everybody’s daily business Continuously improve quality of the code Unit Tests and Pair Programming give courageResult: Fast development speed Code becomes easy to change
  24. 24. Why XP worksLight-weight: discipline without bureaucracyUnder stress, people do what is easiest◦ All XP practices have short-term benefits as well as long-term benefitsDevelopment as a ConversationThe code is the documentationXP is fun
  25. 25. Who benefits from XP?Programmers: Customers: get clear requirements get most business & priorities value first can do a good job get accurate feedback can make technical can make informed decisions business decisions don’t work overtime can change their mind
  26. 26. Conclusions Use XP on projects ◦ with vague or changing requirements ◦ with small teams XP works, and is very fast XP is fun to execute At Azzurri, we use XP as much as possible with clients, and exclusively for internal projects
  27. 27. XP books and papersExtreme Programming Explained – Kent BeckRefactoring – Martin FowlerPlanning Extreme Programming – Kent Beck et alExtreme Programming Installed – Ron Jeffries et alExtreme Programming Examined – Giancarlo Succi et alExtreme Programming in Practice – Robert C. Martin et alExtreme Programming Explored – William C. WakeExtreme Programming Applied – Ken Auer et alThe Costs and Benefits of Pair Programming – AlistairCockburn et al
  28. 28. Web resources www.junit.org www.xprogramming.com www.extremeprogramming.org www.refactoring.com www.pairprogramming.com
  29. 29. Thank you

×