Extreme Programming Practices and Tools - PowerPoint

Document Sample
Extreme Programming Practices and Tools - PowerPoint Powered By Docstoc
					Extreme Programming
 Practices and Tools
          IT Expo 2004

         Marty Phelan
    Wostmann & Associates, Inc
           Agenda
 Extreme Programming Overview
 Extreme Programming Core Practices
 Tools to Support Core Practices
Extreme Programming Overview
   Software Development Challenges
   Methodologies as Solutions
   Extreme Programming Methodology
    Software Development Challenges
   In a 1996 study, the Standish Group found over 50% of
    government technology project were “challenged”, i.e.
    late, over budget, and with fewer features than specified.
    Even projects smaller than $750K had a success rate of
    less than 60%.
   Source: Perlman, Ellen, “Technotrouble”, Governing, Sept.
    1998, Vol. 11, No. 12, pp. 21-24.
          60%
          50%
          40%                                                                               Challenged

          30%                                                                               Failed
          20%
                                                                                            Succeeded
          10%
           0%   More than     $6 to 10   $3 to $6   $1.5 to $3    $750K to      Less than
                $10 million    million    million    million     $1.5 million    $750K
       Complexity Challenges
 Users demand complex systems
 New system has to do everything the old
  system did plus new capability
 Users don’t dare defer requirements for fear
  of losing capability forever
 Technology brings its own growing
  complexity
     Requirements Challenges
 Business requirements more complex
 Difficulty in expressing requirements
 Difficulty in identifying all requirements
 Shifting business priorities
       Integration Challenges
 Multiple Technologies
 Integration Hell
 Long rework cycles
        Resource Challenges
 Shift in resource costs from hardware to
  human resources.
 Diverse technologies
 Limited HR Pool
    The Solution: Methodologies
 Best practices for engineering software and
  managing the process
 Developed from research in the 1970’s and
  1980’s
 Mainly funded by the Department of
  Defense
 Originally oriented to real-time systems
  with high cost of failure
     Heavyweight Methodologies
   Process Oriented
   Documentation Intensive
   Rules and procedures
   Effective, but somewhat costly
   Examples: IEEE Standards, Software Engineering
    Institute maturity level practices
   Some practices have high value, e.g.
    Requirements Specification
    Heavyweight Shortcomings
 More costly
 Can be slower to deliver
 Change is difficult
Extreme Programming Methodology
 Developed by Kent Beck, Ward
  Cunningham, and others
 Originally developed for Object Oriented
  software, but applies to other forms of
  software development
 Proven on the other e.g. Chrysler C3 project
 Small set of values
 Practices which embody those values
                       Forces
   Software requires ongoing changes
   Software development costs are spread over the
    lifetime of the software
    - Initial development cost
    - Maintenance and enhancement cost
   Hardware costs are small compared to software
    development costs (people)
   Programmers are poor prognosticators of what
    users will want in the future
          Extreme Values
 Communications
 Feedback
 Simplicity
 Courage
              Communications
   Customers, Management, and Developers
   Avoids time wasted working on the wrong thing
    due to misunderstandings
   Communicate and plan for Change
   Establishes common understanding of what’s
    possible and what’s reasonable
   Allows the entire team to know what is being done
   Code should communicate intent
                Feedback
 Testing = Feedback!
 Theory says testing cannot prove
  correctness, nor can quality be tested in
 In practice, if most common usages are
  tested they will work
 Emphasis on testing encourages design for
  testability
 Test only what needs to work
               Simplicity
 XP strives for simple solutions
 Methods (Functions) should be simple and
  easy to understand
 Simple code is easier and quicker to modify
 Short development cycles geared to simple
  improvements every time
                    Courage
   Communications + Feedback + Simplicity = >
    Courage
   XP gives the development team the courage to
    move forward rapidly, and to be aggressive in
    making changes to code
   Testing keeps code under control
   Communications allows the entire team to have
    confidence about what is being done
   Continuous integration avoids Integration Hell
    Weeks
   Frequent releases are the result
XP Methodology
XP Practices
             Whole Team
 Team is made up Customer and IT staff
 Customer involvement is crucial
 Customer team member brings knowledge
  of business requirements and priorities
 Many roles: Programmers, Analysts,
  Testers, Coaches, Manager
               Planning Game
 Predict what will be done by due date
 Determine what to do next
 Emphasis on steering rather than exact
  prediction
 Uses two steps to accomplish this:
    - Release Planning
    - Iteration Planning
           Release Planning
 Customer presents requested features
 Programmers estimate difficulty
 Customer prioritizes and dictates plan
 Initial release plan is generally imprecise
 Plan is revised regularly
 Accurate enough for decision making
           Iteration Planning
 Provides direction every 2-3 weeks
 Each iteration produces functional, tested
  code.
 Customer selects features to implement
 Programmers break them down into tasks
  and estimate time.
 Team finalizes features for this iteration
                  Spikes
 A spike is an exploration to enhance
  estimates
 Architectural spikes used to explore new or
  unfamiliar technology
 End-to-end spike frequently used to engage
  all dimensions of a system
 Spikes provide courage
                      Project Variables
                                     Quality can only be
          Scope
                                      varied within narrow
                      +               bounds
                           Time
                                     Resources cannot be
                  +                   fine-tuned
Quality
                                     Scope most directly
                      ?               influences Time
                                     When communicating
     Resources
                                      with Management and
                                      Customers talk about
                                      scope
            Planning Game
 Progress is highly visible
 Decisions are easier to make
 No “90% complete” problem
 Customer can cancel is insufficient progress
 Generally more productive with less stress
           Customer Tests
 Customer defines one or more automated
  acceptance test for each feature
 Team builds test
 Test becomes “proof” that feature works
 Automation of tests is key
 Once running, keep them running
 Good for the life of the system
            Small Releases
 Releases are frequent and small
 Customer may use for review or release to
  end users
 End user releases are frequent
 Only possible because of obsession with
  testing and other practices
XP Practices
        Collective Ownership
 Team owns the code
 Code written in programming pairs
 Anyone can modify the code
 Live code review
 Features more likely to be properly located
 Better adhesion to standards
 More maintainable
          Coding Standards
 Code appears to have single author
 Enhances collective ownership
 Enhances maintainability
          Sustainable Pace
 Work hard but at a sustainable pace
 Overtime may be needed occasionally
 Red-line pace degrades quality and
  productivity
                Metaphor
 Provides a way the team can visualize the
  system.
 Provides common language to describe
  otherwise abstract constructs
 Examples: Assembly line, shopping cart,
  desktop, ledgers.
       Continuous Integration
 Integration builds should be done frequently
 Daily may not be frequent enough
 Avoids “Integration Hell” where everything
  breaks
 Eliminates “code freeze” problems
XP Practices
          Pair Programming
 Software is written by two programmers
  working as a team – side-by-side
 Provides code review, better analysis, better
  testing – better code
 Overall results exceed solo programming
 Introduces force of “pair-pressure”
 Requires practice to be proficient
     Test Driven Development
 Tests are written before code
 Team then codes to make test work
 Once tests work, they must be kept working
 Makes requirements of what you need to
  code clearer
 Enables refactoring and other practices
              Refactoring
 Improves design of code
 Does not change capability
 Object-oriented languages lend themselves
  to refactoring
 Reduces duplication, coupling – increases
  cohesion
 Testing supports refactoring
            Simple Design
 Do simplest thing that could possibly work
 Not most general purpose, most features,
  most hooks
 YAGNI – You aren’t going to need it
 Refactoring will provide the enhancement
 Supported by testing
 Design is continuous and incremental
                XP Summary
Traditional Way          Extreme Way
 Limited Customer        Customers on Team
  input
                          Evolve to the future,
 Build for the future
                           just in time
 “Big Bang”
                          Continuous integration
  integration
 GUI driven              Code Object driven

 Complex                 Radical simplicity
  implementation
Tools for Extreme Programming
 Role and importance of tools
 Availability of tools
 Specific Tools
    Role and Importance of Tools
 Provides efficiencies
 Provides consistency
 Extreme Programming requires automated
  testing
 Continuous integration requires automation
 Version management supports team coding
 Should not replace understanding
        Availability of Tools
 Tools are available for Unix, Mac and
  Windows
 Available for many languages including
  Java, MS .NET, Oracle
 Many open source tools
            Types of Tools
 Version control tools
 Build automation tools
 Automated testing tools
 Code generation tools
       Version Control Types
 Generation Tracking
 Version Control with Locking
 Concurrent Version Control
    Version Control Requirements
 Change tracking
 Version designation
 Concurrency
 Branching
 Security
    Concurrent Version Control
 CVS runs on multiple platforms
 Clients available for many platforms
 Clients integrated into many IDE’s
 Demo
       Version Control Practices
 Nightly build tag and test results
 Release version numbers – major vs. bug
 Branching and merging
    - Branch at every mainline release
    - Merge branches frequently
      Build Automation Tools
 Beyond simple compile
 Sometimes integrated into IDE’s
 “Make” tool is most widely known
 Need to support not only construction, but
  testing, documentation, and deployment
 Provides consistency and documents
  process
                   Ant
 Ant is a Java based “make” tool
 Extended by writing Java tasks
 Portable – not OS bound
 “Makefiles” are simple XML
 Open source with many extensions
 Demo
         Automated Testing
 A must for Extreme Programming
 Needed for unit and acceptance tests
 Must provide visual and published results
 UI testing is still not state-of-the-art
             Essence of a Test
 Tests should be simple in nature and focus
 Each test build around a test case
 A single feature may have many tests
 Test structure consists of
    - Setup state
    - Perform transaction
    - Extract and measure results against expected
               Testing Tools
 Variety of open source tools available
 JUnit is most widely known for Java
 NUnit is available for MS languages
 JUnit has many open source extensions
    - Web testing – HttpUnit
    - Test objects – Mock Objects
    - Database – dbUnit, SQLUnit
                    JUnit
 Simple set of base classes to extend
 Provide ability to run single or multiple
  tests
 Results can be displayed in GUI, text or
  XML
 Provides many assertion methods
 Highly extensible
 Demo
          Code Generation
 Supports many Extreme Programming
  practices
 Can be simple template for new objects
 Can be complex code generation from meta
  data
 Code generation must not be magic to
  programmers
       Code Generation Tools
 Many IDE’s include some level of code
  generation
 First level: Templates, Wizards, code
  completion
 Second level: Generate initial code – once
  only
 Third level: Generate final code –
  repeatable – uses meta data
      Middlegen and XDoclet
 Open source tools that are extensible
 Middlegen generates objects from database
  schema
 XDoclet generates objects from meta data
  in Java classes
 Both run as Ant tasks
XDoclet
         Other Support Tools
 Issue tracking systems: iTracker, bugzilla
 Documentation generation tools: JavaDoc,
  XDoclet
 Project management tools: XPlanner
 Project repository tools: GForge,
  SourceForge
        Importance of Tools
 Version control enables team ownership,
  collaboration, safety, history and pace
 Build tools provide consistency, speed,
  accuracy
 Automates testing increases speed and
  quality
 Code generation enhances code standards,
  quality and speed
Extreme Programming
 Tools and Practices
    IT Expo 2004
     by Marty Phelan
Wostmann & Associates, Inc.

 http://www.wostmann.com