Agile Methods and
Extreme Programming
CSSE 376, Software Quality Assurance
Rose-Hulman Institute of Technology
March 23, 2007
Outline
I. Origin of Agile Methods
II. Extreme Programming
III. Test First Development
2
I. Origin of Agile Methods
3
First Cartoon of the Day
4
Spectrum of Methods
Source: "Get ready for agile methods, with care" by Barry Boehm,
IEEE Computer, January 2002.
5
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.
6
Some Agile Methods
•
•
•
•
•
•
•
ASD - Adaptive Software Development
Crystal
FDD - Feature Driven Development
DSDM - Dynamic Systems Development Method
Lean Software Development
Scrum
XP - eXtreme Programming
7
II. Extreme Programming
8
Motivation
• Knobs on a control board
• Each knob a practice that works well
• Turn all knobs up to 10
9
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
10
Four Values
• Simplicity
– create the simplest thing that could work
• Communication
– face-to-face, not document-to-face
• Feedback
– lots of tests
• Aggressiveness
11
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
12
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.
12. Coding standards
Refactoring
13
Waterfall to XP Evolution
Source: "Embracing change with extreme programming" by Kent Beck,
IEEE Computer, October 1999.
14
5. Testing
• Any feature without an automated test
does not exist.
• Programmers need confidence in
correct operation
• Customers need confidence in correct
operation
15
Tools for Testing
• Test harnesses for various programming
languages
• Simplify job of creating and running the
tests
16
Second Cartoon of the Day
17
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
18
Workspace
19
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
20
III. Test First Development
21
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
22
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.
23
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
24