Extreme Programming

Document Sample
Extreme Programming Powered By Docstoc
					         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,   5
IEEE Computer, January 2002.
                             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.   Refactoring         12. Coding standards


                                                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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:6/30/2012
language:English
pages:24