1. Agile Requirements Methods CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 26, 2004

2. 2 Outline I.Origin of Agile Methods II.Extreme Programming III.How could this work?

3. 3 I. Origin of Agile Methods

4. 4 Cartoon of the Day

5. 5 Spectrum of Methods Source: "Get ready for agile methods, with care" by Barry Boehm, IEEE Computer, January 2002.

6. 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. 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. 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. 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. 10 II. Extreme Programming

11. 11 Twelve Practices 7. Pair programming 8. Collective ownership 9. Continuous integration 10. 40-hour week 11. On-site customer 12. Coding standards 1. The Planning Game 2. Small releases 3. Metaphor 4. Simple design 5. Testing 6. Refactoring

12. 12 1. The Planning Game Business people decide: –scope –priority –release dates Technical people decide: –estimates of effort –technical consequences –process –detailed scheduling

13. 13 The Planning Game Collect User Stories on cards Stories are written by customers Stories generate tests

14. 14 Estimating Be concrete No imposed estimates Feedback: compare actuals to estimates Re-estimate periodically

15. 15 Scheduling Each story gets an estimate of effort Customers decide which stories are most important Programmers calculate how long each release will take

16. 16 2. Small Releases Every release should be as small as possible Every release has to completely implement its new features

17. 17 Waterfall to XP Evolution Source: "Embracing change with extreme programming" by Kent Beck, IEEE Computer, October 1999.

18. 18 3. Metaphor Each XP project has its own metaphor –naive –system is a spreadsheet Metaphor replaces architecture as the view from 10,000 feet Metaphor replaces vision statement

19. 19 5. Testing Any feature without an automated test does not exist. Programmers need confidence in correct operation Customers need confidence in correct operation Develop test first, before code

20. 20 Tools for Testing Test harnesses for various programming languages Simplify job of creating and running the tests

21. 21 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

22. 22 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

23. 23 III. How could this work?

24. 24 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

25. 25 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

26. 26 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

27. 27 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

28. 28 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)

29. 29 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