Agile Methods and Extreme Programming CS 414, Software Engineering I Mark Ardis Rose-Hulman Institute December 19, 2002
Outline <ul><li>Origin of Agile Methods </li></ul><ul><li>Examples of Agile Methods </li></ul><ul><li>Extreme Programming ...
I.  Origin of Agile Methods
First Cartoon of the Day
Spectrum of Methods Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm,   IEEE Computer , January 2...
Boehm's Risk Exposure Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm,   IEEE Computer ,...
Safety-Critical Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm,   IEEE Computer , Janua...
Agile Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm,   IEEE Computer , January 2002.  ...
Agile Manifesto <ul><li>We are uncovering better ways of developing  software by doing it and helping others do it. Throug...
II.  Examples of Agile Methods
The List of Agile Methods <ul><li>Adaptive Software Development </li></ul><ul><li>Crystal </li></ul><ul><li>Dynamic System...
Adaptive Software Development Source:  &quot;Retiring lifecycle dinosaurs&quot; by Jim Highsmith,  Software Testing and Qu...
Crystal <ul><li>&quot;family of human-powered and adaptive, ultralight, 'shrink-to-fit' software development methodologies...
Dynamic System Development Method (DSDM) Source:  DSDM website
Feature Driven Development (FDD) <ul><li>At start of project: </li></ul><ul><ul><li>Develop an Overall Model </li></ul></u...
SCRUM Source:  SCRUM website
III.  Extreme Programming
Motivation <ul><li>Knobs on a control board </li></ul><ul><li>Each knob a practice that works well </li></ul><ul><li>Turn ...
Learning to Drive <ul><li>&quot;Driving is not about getting the car going in the right direction. </li></ul><ul><li>Drivi...
Four Values <ul><li>Simplicity </li></ul><ul><ul><li>create the simplest thing that could work </li></ul></ul><ul><li>Comm...
Four Basic Activities <ul><li>Coding </li></ul><ul><ul><li>cannot do without it </li></ul></ul><ul><li>Testing </li></ul><...
Twelve Practices <ul><li>Pair programming </li></ul><ul><li>Collective ownership </li></ul><ul><li>Continuous integration ...
1. The Planning Game <ul><li>Business people decide: </li></ul><ul><ul><li>scope </li></ul></ul><ul><ul><li>priority </li>...
The Planning Game <ul><li>Collect User Stories on cards </li></ul><ul><li>Stories are written by customers </li></ul><ul><...
Estimating <ul><li>Be concrete </li></ul><ul><li>No imposed estimates </li></ul><ul><li>Feedback: compare actuals to estim...
Scheduling <ul><li>Each story gets an estimate of effort </li></ul><ul><li>Customers decide which stories are most importa...
2. Small Releases <ul><li>Every release should be as small as possible </li></ul><ul><li>Every release has to completely i...
Waterfall to XP Evolution Source: &quot;Embracing change with extreme programming&quot; by Kent Beck, IEEE Computer , Octo...
3. Metaphor <ul><li>Each XP project has its own metaphor </li></ul><ul><ul><li>naive </li></ul></ul><ul><ul><li>system is ...
4. Simple Design <ul><li>Runs all the tests </li></ul><ul><li>Has no duplicated logic </li></ul><ul><li>States every inten...
5. Testing <ul><li>Any feature without an automated test does not exist. </li></ul><ul><li>Programmers need confidence in ...
Tools for Testing <ul><li>Test harnesses for various programming languages </li></ul><ul><li>Simplify job of creating and ...
6. Refactoring <ul><li>Always ask if there is a way to make the program simpler </li></ul><ul><li>When the system requires...
Second Cartoon of the Day
7. Pair Programming <ul><li>All code written with 2 people at one machine </li></ul><ul><li>Driver: </li></ul><ul><ul><li>...
Workspace
8. Collective Ownership <ul><li>Anybody who sees an opportunity to add value to any portion of the code is required to do ...
9. Continuous Integration <ul><li>Integrate and test every few hours, at least once per day </li></ul><ul><li>All tests mu...
10. 40-Hour Week <ul><li>People should be fresh and eager every morning </li></ul><ul><li>Overtime is a symptom of a serio...
11. On-Site Customer <ul><li>Real customer will use the finished system </li></ul><ul><li>Programmers need to ask question...
12. Coding Standards <ul><li>Everyone edits everyone's code </li></ul><ul><li>Standard should require least amount of over...
How could this work?
1. The Planning Game <ul><li>You couldn't start with only a rough plan </li></ul><ul><li>Unless: </li></ul><ul><ul><li>cus...
2. Small Releases <ul><li>You couldn't release new versions so quickly </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the...
3. Metaphor <ul><li>You couldn't start with just a metaphor </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you got feedba...
4. Simple Design <ul><li>You couldn't have just enough design for today </li></ul><ul><li>Unless: </li></ul><ul><ul><li>yo...
5. Testing <ul><li>You couldn't write all those tests </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the design was as si...
6. Refactoring <ul><li>You couldn't refactor the design all the time </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you w...
7. Pair Programming <ul><li>You couldn't write all the code in pairs </li></ul><ul><li>Unless: </li></ul><ul><ul><li>codin...
8. Collective Ownership <ul><li>You couldn't have everyone changing everything </li></ul><ul><li>Unless: </li></ul><ul><ul...
9. Continuous Integration <ul><li>You couldn't integrate every few hours </li></ul><ul><li>Unless: </li></ul><ul><ul><li>y...
10. 40-Hour Week <ul><li>You couldn't work only 40 hours/week </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the Planning...
11. On-Site Customer <ul><li>You couldn't have a real customer sitting by the programmers full-time </li></ul><ul><li>Unle...
12. Coding Standards <ul><li>You couldn't get everyone to use the same coding standard </li></ul><ul><li>Unless: </li></ul...
Upcoming SlideShare
Loading in...5
×

Ardis02

281

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
281
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ardis02

  1. 1. Agile Methods and Extreme Programming CS 414, Software Engineering I Mark Ardis Rose-Hulman Institute December 19, 2002
  2. 2. Outline <ul><li>Origin of Agile Methods </li></ul><ul><li>Examples of Agile Methods </li></ul><ul><li>Extreme Programming </li></ul>
  3. 3. I. Origin of Agile Methods
  4. 4. First Cartoon of the Day
  5. 5. Spectrum of Methods Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm, IEEE Computer , January 2002.
  6. 6. Boehm's Risk Exposure Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm, IEEE Computer , January 2002. Black curve: Inadequate plans Red curve: Market share erosion
  7. 7. Safety-Critical Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm, IEEE Computer , January 2002. Black curve: Inadequate plans Red curve: Market share erosion
  8. 8. Agile Profile Source: &quot;Get ready for agile methods, with care&quot; by Barry Boehm, IEEE Computer , January 2002. Black curve: Inadequate plans Red curve: Market share erosion
  9. 9. Agile Manifesto <ul><li>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: </li></ul><ul><ul><li>Individuals and interactions over processes and tools </li></ul></ul><ul><ul><li>Working software over comprehensive documentation </li></ul></ul><ul><ul><li>Customer collaboration over contract negotiation </li></ul></ul><ul><ul><li>Responding to change over following a plan </li></ul></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul>
  10. 10. II. Examples of Agile Methods
  11. 11. The List of Agile Methods <ul><li>Adaptive Software Development </li></ul><ul><li>Crystal </li></ul><ul><li>Dynamic System Development Method (DSDM) </li></ul><ul><li>Extreme Programming </li></ul><ul><li>Feature Driven Development (FDD) </li></ul><ul><li>SCRUM </li></ul>
  12. 12. Adaptive Software Development Source: &quot;Retiring lifecycle dinosaurs&quot; by Jim Highsmith, Software Testing and Quality Engineering , July/August 2000
  13. 13. Crystal <ul><li>&quot;family of human-powered and adaptive, ultralight, 'shrink-to-fit' software development methodologies&quot; </li></ul><ul><li>People-centric </li></ul><ul><li>Reduces bureaucracy to least practical </li></ul><ul><li>Start small and make it smaller </li></ul>
  14. 14. Dynamic System Development Method (DSDM) Source: DSDM website
  15. 15. Feature Driven Development (FDD) <ul><li>At start of project: </li></ul><ul><ul><li>Develop an Overall Model </li></ul></ul><ul><ul><li>Build a Features List </li></ul></ul><ul><ul><li>Plan by Feature </li></ul></ul><ul><li>Within each iteration: </li></ul><ul><ul><li>Design by Feature </li></ul></ul><ul><ul><li>Build by Feature </li></ul></ul>
  16. 16. SCRUM Source: SCRUM website
  17. 17. III. Extreme Programming
  18. 18. Motivation <ul><li>Knobs on a control board </li></ul><ul><li>Each knob a practice that works well </li></ul><ul><li>Turn all knobs up to 10 </li></ul>
  19. 19. Learning to Drive <ul><li>&quot;Driving is not about getting the car going in the right direction. </li></ul><ul><li>Driving is about constantly paying attention, making a little correction this way, a little correction that way.&quot; </li></ul><ul><li>-- Kent Beck, Extreme Programming Explained </li></ul>
  20. 20. Four Values <ul><li>Simplicity </li></ul><ul><ul><li>create the simplest thing that could work </li></ul></ul><ul><li>Communication </li></ul><ul><ul><li>face-to-face, not document-to-face </li></ul></ul><ul><li>Feedback </li></ul><ul><ul><li>lots of tests </li></ul></ul><ul><li>Aggressiveness </li></ul>
  21. 21. Four Basic Activities <ul><li>Coding </li></ul><ul><ul><li>cannot do without it </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>if it cannot be tested it doesn't exist </li></ul></ul><ul><li>Listening </li></ul><ul><ul><li>to those with domain knowledge </li></ul></ul><ul><li>Designing </li></ul><ul><ul><li>to keep the system from decaying </li></ul></ul>
  22. 22. Twelve Practices <ul><li>Pair programming </li></ul><ul><li>Collective ownership </li></ul><ul><li>Continuous integration </li></ul><ul><li>40-hour week </li></ul><ul><li>On-site customer </li></ul><ul><li>Coding standards </li></ul><ul><li>The Planning Game </li></ul><ul><li>Small releases </li></ul><ul><li>Metaphor </li></ul><ul><li>Simple design </li></ul><ul><li>Testing </li></ul><ul><li>Refactoring </li></ul>
  23. 23. 1. The Planning Game <ul><li>Business people decide: </li></ul><ul><ul><li>scope </li></ul></ul><ul><ul><li>priority </li></ul></ul><ul><ul><li>release dates </li></ul></ul><ul><li>Technical people decide: </li></ul><ul><ul><li>estimates of effort </li></ul></ul><ul><ul><li>technical consequences </li></ul></ul><ul><ul><li>process </li></ul></ul><ul><ul><li>detailed scheduling </li></ul></ul>
  24. 24. The Planning Game <ul><li>Collect User Stories on cards </li></ul><ul><li>Stories are written by customers </li></ul><ul><li>Stories generate tests </li></ul>
  25. 25. Estimating <ul><li>Be concrete </li></ul><ul><li>No imposed estimates </li></ul><ul><li>Feedback: compare actuals to estimates </li></ul><ul><li>Re-estimate periodically </li></ul>
  26. 26. Scheduling <ul><li>Each story gets an estimate of effort </li></ul><ul><li>Customers decide which stories are most important </li></ul><ul><li>Programmers calculate how long each release will take </li></ul>
  27. 27. 2. Small Releases <ul><li>Every release should be as small as possible </li></ul><ul><li>Every release has to completely implement its new features </li></ul>
  28. 28. Waterfall to XP Evolution Source: &quot;Embracing change with extreme programming&quot; by Kent Beck, IEEE Computer , October 1999.
  29. 29. 3. Metaphor <ul><li>Each XP project has its own metaphor </li></ul><ul><ul><li>naive </li></ul></ul><ul><ul><li>system is a spreadsheet </li></ul></ul><ul><li>Metaphor replaces architecture as the view from 10,000 feet </li></ul>
  30. 30. 4. Simple Design <ul><li>Runs all the tests </li></ul><ul><li>Has no duplicated logic </li></ul><ul><li>States every intention important to programmers </li></ul><ul><li>Has the fewest possible classes and methods </li></ul>
  31. 31. 5. Testing <ul><li>Any feature without an automated test does not exist. </li></ul><ul><li>Programmers need confidence in correct operation </li></ul><ul><li>Customers need confidence in correct operation </li></ul>
  32. 32. Tools for Testing <ul><li>Test harnesses for various programming languages </li></ul><ul><li>Simplify job of creating and running the tests </li></ul>
  33. 33. 6. Refactoring <ul><li>Always ask if there is a way to make the program simpler </li></ul><ul><li>When the system requires duplication of code, it is asking for refactoring </li></ul><ul><li>Can always find a series of small, low-risk steps </li></ul>
  34. 34. Second Cartoon of the Day
  35. 35. 7. Pair Programming <ul><li>All code written with 2 people at one machine </li></ul><ul><li>Driver: </li></ul><ul><ul><li>thinks about best way to implement </li></ul></ul><ul><li>Passenger: </li></ul><ul><ul><li>thinks about viability of whole approach </li></ul></ul><ul><ul><li>thinks of new tests </li></ul></ul><ul><ul><li>thinks of simpler ways </li></ul></ul>
  36. 36. Workspace
  37. 37. 8. Collective Ownership <ul><li>Anybody who sees an opportunity to add value to any portion of the code is required to do so </li></ul><ul><li>Everyone knows something about everything </li></ul><ul><li>Everyone feels obligated to make improvements </li></ul>
  38. 38. 9. Continuous Integration <ul><li>Integrate and test every few hours, at least once per day </li></ul><ul><li>All tests must pass </li></ul><ul><li>Easy to tell who broke the code </li></ul>
  39. 39. 10. 40-Hour Week <ul><li>People should be fresh and eager every morning </li></ul><ul><li>Overtime is a symptom of a serious problem </li></ul><ul><li>XP only allows one week of overtime </li></ul>
  40. 40. 11. On-Site Customer <ul><li>Real customer will use the finished system </li></ul><ul><li>Programmers need to ask questions of a real customer </li></ul><ul><li>Customer can get some other work done while sitting with programmers </li></ul>
  41. 41. 12. Coding Standards <ul><li>Everyone edits everyone's code </li></ul><ul><li>Standard should require least amount of overhead </li></ul><ul><li>Standard should be adopted voluntarily by the team </li></ul>
  42. 42. How could this work?
  43. 43. 1. The Planning Game <ul><li>You couldn't start with only a rough plan </li></ul><ul><li>Unless: </li></ul><ul><ul><li>customers did updating based on estimates of programmers </li></ul></ul><ul><ul><li>short releases (2) revealed any mistakes in plan </li></ul></ul><ul><ul><li>customer was sitting with programmers (11) to spot trouble </li></ul></ul>
  44. 44. 2. Small Releases <ul><li>You couldn't release new versions so quickly </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the Planning Game (1) helped work on the most valuable stories </li></ul></ul><ul><ul><li>you were integrating continuously (9) </li></ul></ul><ul><ul><li>testing (5) reduced defect rate </li></ul></ul>
  45. 45. 3. Metaphor <ul><li>You couldn't start with just a metaphor </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you got feedback on whether metaphor was working </li></ul></ul><ul><ul><li>your customer was comfortable talking about the system in terms of the metaphor </li></ul></ul><ul><ul><li>you refactored continually (6) to refine understanding </li></ul></ul>
  46. 46. 4. Simple Design <ul><li>You couldn't have just enough design for today </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you were used to refactoring (6) </li></ul></ul><ul><ul><li>you had a clear overall metaphor (3) </li></ul></ul><ul><ul><li>you were programming with a partner (7) </li></ul></ul>
  47. 47. 5. Testing <ul><li>You couldn't write all those tests </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the design was as simple as possible (4) </li></ul></ul><ul><ul><li>you were programming with a partner (7) </li></ul></ul><ul><ul><li>you felt good seeing all those tests running </li></ul></ul><ul><ul><li>your customer felt good seeing all those tests running </li></ul></ul>
  48. 48. 6. Refactoring <ul><li>You couldn't refactor the design all the time </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you were used to collective ownership (8) </li></ul></ul><ul><ul><li>you had coding standards (12) </li></ul></ul><ul><ul><li>you programmed in pairs (7) </li></ul></ul><ul><ul><li>you had a simple design (4) </li></ul></ul><ul><ul><li>you had enough tests (5) </li></ul></ul><ul><ul><li>you had continuous integration (9) </li></ul></ul><ul><ul><li>you were rested (10) </li></ul></ul>
  49. 49. 7. Pair Programming <ul><li>You couldn't write all the code in pairs </li></ul><ul><li>Unless: </li></ul><ul><ul><li>coding standards (12) reduced picayune squabbles </li></ul></ul><ul><ul><li>everyone were fresh and rested (10) </li></ul></ul><ul><ul><li>the pairs wrote tests together (7) </li></ul></ul><ul><ul><li>the pairs had a metaphor (3) to ground their decisions </li></ul></ul><ul><ul><li>the pairs were working within a simple design (4) </li></ul></ul>
  50. 50. 8. Collective Ownership <ul><li>You couldn't have everyone changing everything </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you integrated after a short time (9) </li></ul></ul><ul><ul><li>you had enough tests (5) </li></ul></ul><ul><ul><li>you programmed in pairs (7) </li></ul></ul><ul><ul><li>you adhered to coding standards (12) </li></ul></ul>
  51. 51. 9. Continuous Integration <ul><li>You couldn't integrate every few hours </li></ul><ul><li>Unless: </li></ul><ul><ul><li>you could run tests quickly (5) </li></ul></ul><ul><ul><li>you programmed in pairs (7) </li></ul></ul><ul><ul><li>you refactored (6) </li></ul></ul>
  52. 52. 10. 40-Hour Week <ul><li>You couldn't work only 40 hours/week </li></ul><ul><li>Unless: </li></ul><ul><ul><li>the Planning Game (1) were choosing the most important work to do </li></ul></ul><ul><ul><li>you had enough tests (5) to avoid nasty surprises </li></ul></ul><ul><ul><li>you were working at top speed already </li></ul></ul>
  53. 53. 11. On-Site Customer <ul><li>You couldn't have a real customer sitting by the programmers full-time </li></ul><ul><li>Unless: </li></ul><ul><ul><li>they could produce value by writing functional tests </li></ul></ul><ul><ul><li>they could produce value by making small-scale priority and scope decisions </li></ul></ul>
  54. 54. 12. Coding Standards <ul><li>You couldn't get everyone to use the same coding standard </li></ul><ul><li>Unless: </li></ul><ul><ul><li>they were part of a winning team by practicing XP </li></ul></ul>
  1. A particular slide catching your eye?

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

×