Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
212
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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