Agile Requirements Methods CSSE 371 Software Requirements and

Agile Requirements Methods CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 18, 2005

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

I. Origin of Agile Methods 3

Cartoon of the Day 4

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

Boehm's Risk Exposure Profile Black curve: Inadequate plans Red curve: Market share erosion Source: "Get ready for agile methods, with care" by Barry Boehm, IEEE Computer, January 2002. 6

Safety-Critical Profile Black curve: Inadequate plans Red curve: Market share erosion Source: "Get ready for agile methods, with care" by Barry Boehm, IEEE Computer, January 2002. 7

Agile Profile Black curve: Inadequate plans Red curve: Market share erosion Source: "Get ready for agile methods, with care" by Barry Boehm, IEEE Computer, January 2002. 8

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

II. Extreme Programming 10

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

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

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

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

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

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

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

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 18

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 19

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

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 21

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 22

III. How could this work? 23

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 24

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 25

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 26

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 27

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

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 smallscale priority and scope decisions 29