Agile Methods andExtreme 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

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

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