Agile Methods and Extreme Programming CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 23, 2007

2 Outline I.Origin of Agile Methods II.Extreme Programming III.Test First Development

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

7 Some Agile Methods ASD - Adaptive Software Development Crystal FDD - Feature Driven Development DSDM - Dynamic Systems Development Method Lean Software Development Scrum XP - eXtreme Programming

8 II. Extreme Programming

9 Motivation Knobs on a control board Each knob a practice that works well Turn all knobs up to 10

10 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

11 Four Values Simplicity –create the simplest thing that could work Communication –face-to-face, not document-to-face Feedback –lots of tests Aggressiveness

12 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

13 Twelve Practices 7. Pair programming 8. Collective ownership 9. Continuous integration 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

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

15 5. Testing Any feature without an automated test does not exist. Programmers need confidence in correct operation Customers need confidence in correct operation

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

17 Second Cartoon of the Day

18 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

19 Workspace

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 III. Test First Development

22 Code the Unit Test First Makes it easier to write the code Translates requirements to specific tasks that must be accomplished by code Creates tests at moments when they can best be defined Provides immediate feedback to coding

23 Similar to Deming's PDSA Cycle (below) Plan: Write a test case expressing what you hope to accomplish. Do: Write the code. Study: Run the test. Act: If it passes, check the code in and go on. If it fails, rerun the cycle. Maybe the code is bad or maybe the test is bad.

24 Side Effects Designing in small steps –only need to do a little bit at a time A sense of unhurriedness –always know what you are doing and when you are done Monological thinking –focus on one thing at a time