An Introduction to XP and Agile Jason Yip,  [email_address] http:// www.thoughtworks.com
What’s the problem?
Software  takes too long ,  costs too much , and requires  too many people
The plan is fantasy… and we don’t learn this until it’s too late
We’re wasting our lives doing things that don’t matter
Why do the problems occur?
We only have one opportunity to decide, so we ask for everything… and we waste time building what we don’t actually need
How often are features used?
We defer concrete validation until it’s too late to respond
We punish raising problems
We have too much specialisation
We have a “not my problem” culture
What do we want instead?
Any feature, any order, one at a time
Highest productivity, highest quality, lowest cost, highest morale
Real visibility about what’s happening
Learn about problems as early as possible
Less administrative work; more value-adding work
XP and Agile as a solution
Philosophy, Process, People, Problem Solving Problem Solving People Process Philosophy
Philosophy: Values <ul><li>Simplicity </li></ul><ul><li>Communication </li></ul><ul><li>Feedback </li></ul><ul><li>Courage...
Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolut...
Process: Just-in-Time
User Stories <ul><li>AS an Agile team member, I WANT a way to have self-contained small units of work SO THAT I can focus ...
Card, Conversation, Confirmation <ul><li>Card  – index card; physical token used for visual planning and tracking </li></u...
Timeboxed iterative-incremental development
Small Releases http://www.slideshare.net/cching/rocks-into-gold-by-clarke-ching-presentation
Process: Built-in Quality
Mistake proofing <ul><li>Eliminate  – Don’t build it – YAGNI </li></ul><ul><li>Replace  – Use a reliable library </li></ul...
Test-driven Development <ul><li>Think </li></ul><ul><li>Red </li></ul><ul><li>Green </li></ul><ul><li>Refactor </li></ul><...
Continuous Integration
Pair Programming
People: T-shaped people
People: Whole Team http://www.think-box.co.uk/blog/2007/11/theres-hole-in-your-side-of-boat.html
Authority vs Responsibility
Problem Solving: Daily Standups <ul><li>What did I accomplish yesterday? </li></ul><ul><li>What will I do today? </li></ul...
Problem Solving: Retrospectives <ul><li>What did we do well, that if we don’t discuss we might forget? </li></ul><ul><li>W...
Problem Solving: Spikes over speculation <ul><li>&quot;What is the simplest thing we can program that will convince us we ...
Why should we believe this will work?
This is the evolution of what we’ve learned over decades <ul><li>“ Although many view iterative and incremental developmen...
Don’t believe… think for yourself… try something… see what happens… adjust
For some more conventional introductions… <ul><li>http://www.extremeprogramming.org </li></ul><ul><li>http://www.xprogramm...
Upcoming SlideShare
Loading in...5
×

An Introduction to XP and Agile

4,450

Published on

An introduction to XP and Agile for SyXPAC

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,450
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
134
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

An Introduction to XP and Agile

  1. 1. An Introduction to XP and Agile Jason Yip, [email_address] http:// www.thoughtworks.com
  2. 2. What’s the problem?
  3. 3. Software takes too long , costs too much , and requires too many people
  4. 4. The plan is fantasy… and we don’t learn this until it’s too late
  5. 5. We’re wasting our lives doing things that don’t matter
  6. 6. Why do the problems occur?
  7. 7. We only have one opportunity to decide, so we ask for everything… and we waste time building what we don’t actually need
  8. 8. How often are features used?
  9. 9. We defer concrete validation until it’s too late to respond
  10. 10. We punish raising problems
  11. 11. We have too much specialisation
  12. 12. We have a “not my problem” culture
  13. 13. What do we want instead?
  14. 14. Any feature, any order, one at a time
  15. 15. Highest productivity, highest quality, lowest cost, highest morale
  16. 16. Real visibility about what’s happening
  17. 17. Learn about problems as early as possible
  18. 18. Less administrative work; more value-adding work
  19. 19. XP and Agile as a solution
  20. 20. Philosophy, Process, People, Problem Solving Problem Solving People Process Philosophy
  21. 21. Philosophy: Values <ul><li>Simplicity </li></ul><ul><li>Communication </li></ul><ul><li>Feedback </li></ul><ul><li>Courage </li></ul><ul><li>Respect </li></ul>
  22. 22. Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters? … Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something. Kent Beck, http://www.c2.com/cgi/wiki?ExtremeProgramming
  23. 23. Process: Just-in-Time
  24. 24. User Stories <ul><li>AS an Agile team member, I WANT a way to have self-contained small units of work SO THAT I can focus on one thing at a time, show visible progress earlier, and allow for negotiation </li></ul>
  25. 25. Card, Conversation, Confirmation <ul><li>Card – index card; physical token used for visual planning and tracking </li></ul><ul><li>Conversation – primary medium of communication supplemented as necessary with documentation </li></ul><ul><li>Confirmation – Examples that indicate when story is complete; turned into automated tests </li></ul>http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
  26. 26. Timeboxed iterative-incremental development
  27. 27. Small Releases http://www.slideshare.net/cching/rocks-into-gold-by-clarke-ching-presentation
  28. 28. Process: Built-in Quality
  29. 29. Mistake proofing <ul><li>Eliminate – Don’t build it – YAGNI </li></ul><ul><li>Replace – Use a reliable library </li></ul><ul><li>Prevent by design </li></ul><ul><li>Facilitate – Only use the useful features, ignore the rest </li></ul><ul><li>Detect as early as possible – TDD, CI, pair programming </li></ul><ul><li>Mitigate – Make sure problems don’t cascade; error-handling </li></ul>
  30. 30. Test-driven Development <ul><li>Think </li></ul><ul><li>Red </li></ul><ul><li>Green </li></ul><ul><li>Refactor </li></ul><ul><li>Repeat </li></ul>http://jamesshore.com/Blog/Red-Green-Refactor.html
  31. 31. Continuous Integration
  32. 32. Pair Programming
  33. 33. People: T-shaped people
  34. 34. People: Whole Team http://www.think-box.co.uk/blog/2007/11/theres-hole-in-your-side-of-boat.html
  35. 35. Authority vs Responsibility
  36. 36. Problem Solving: Daily Standups <ul><li>What did I accomplish yesterday? </li></ul><ul><li>What will I do today? </li></ul><ul><li>What obstacles are impeding my progress? </li></ul>http:// martinfowler.com/articles/itsNotJustStandingUp.html
  37. 37. Problem Solving: Retrospectives <ul><li>What did we do well, that if we don’t discuss we might forget? </li></ul><ul><li>What did we learn? </li></ul><ul><li>What should we do differently next time? </li></ul><ul><li>What still puzzles us? </li></ul>http:// www.retrospectives.com /
  38. 38. Problem Solving: Spikes over speculation <ul><li>&quot;What is the simplest thing we can program that will convince us we are on the right track?“ </li></ul><ul><li>Ward Cunningham </li></ul>http://c2.com/xp/SpikeSolution.html
  39. 39. Why should we believe this will work?
  40. 40. This is the evolution of what we’ve learned over decades <ul><li>“ Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s.” </li></ul><ul><li>Craig Larman and Victor R. Basili </li></ul>http://www.cs.umd.edu/~basili/publications/journals/J90.pdf
  41. 41. Don’t believe… think for yourself… try something… see what happens… adjust
  42. 42. For some more conventional introductions… <ul><li>http://www.extremeprogramming.org </li></ul><ul><li>http://www.xprogramming.com/xpmag/whatisxp.htm </li></ul><ul><li>http://www.agilemanifesto.org/ </li></ul><ul><li>http:// www.poppendieck.com / </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×