Introduction to eXtreme Programming (XP)

Document Sample
Introduction to eXtreme Programming (XP) Powered By Docstoc
					Introduction to eXtreme
Programming (XP)

       Collaboration in Software
       Development Process
XP overview

   A large percentage of software projects fail,
    due to a variety of problems we will see
   Most of these problems are really issues of
    Design, Learning, and Collaboration in the
    software process
   XP takes innovative approaches to improve
    Design, Learning, and Collaboration in the
    software process
Traditional Problems, XP
solutions
   Problem: Improper planning
       Not enough planning
       Too much planning: planning for situations that
        will never occur
   Solution: XP says to quickly determine the
    scope of the next (short) development cycle.
       Business priorities
       Technical feasibility
       Keep the plan updated as things change
   Result: improved Design
Traditional Problems, XP
solutions
   Problem: Schedules blown at the last
    minute:
       Example: software project where all
        development is done before integration
       Integration takes unexpectedly long
   Solution: XP promotes Iterative
    development: Releases as small as possible
   Solution: XP also includes constant
    integration
   Result: managed risk
Traditional Problems, XP
solutions

   Problem: Design doesn’t fit together
    well because individual designers and
    implementers all have different ideas
   Solution: In XP, a Metaphor, or simple
    shared story, is created for the entire
    project
   Result: improved Collaboration
Traditional Problems, XP
solutions

   Problem: “Over-engineered” software
       Design for situations that will never occur
       Complexity causes defects
   Solution: Extreme programming promotes
    maximum simplicity
       Implement the bare minimum that is needed
        now
       Add additional complexity as it is needed
   Result: improved Design
Traditional Problems, XP
solutions

   Problem: The last few weeks in a 6 month
    long project is allocated for testing, but
    testing takes 4 more months instead
   Solution: XP requires that programmers
    write unit tests for all code
       All tests must pass before development on new
        items can continue
   Result: improved Design
Traditional Problems, XP
solutions

   Problem: Programmers know about bad
    sections of code, but do not fix them
       They don’t feel like they have time
       They are afraid to cause more trouble
   Solution: XP makes Refactoring an official
    part of the development process.
       Programmers are empowered to fix problems
   Result: improved Design
Traditional Problems, XP
solutions

   Problem: Programmers just code without
    thinking about the big picture, design
    problems and bugs result
   Solution: XP requires that _all_ production
    code be written with 2 programmers behind
    the desk, one typing and one observing
       Pairs are “rotated” over time
   Result: improved collaboration AND learning
Traditional Problems, XP
solutions

   Problem: One programmer won’t let others
    work on “his code,” thus nobody else
    understands it. Then he gets hit by a bus.
   Solution: in XP, everyone owns all of the
    code. Everyone is allowed to work on any
    part of the system
   Result: improved collaboration and learning
Traditional Problems, XP
solutions

   Problem: Programmer works 80 hours per
    week on a “death march” project trying to
    get a release out the door, wife leaves him,
    he quits to become a candle maker in
    Oregon
   Solution: XP requires 40 hour weeks, and
    never allows overtime 2 weeks in a row
   Result: Improved performance of
    programmers in many ways
Traditional Problems, XP
solutions

   Problem: Customer wants a High Heel shoe,
    development builds a Combat Boot
       Development solves the wrong problem
   Solution: XP requires a “real life customer”
    on every team, ensuring that the project
    solves the right problems.
   Result: improved collaboration (with
    customer)
Traditional Problems, XP
solutions

   Problem: Every programmer uses the
    language in different ways, formats their
    code and declares variables differently
   Solution: XP implements coding standards
    so that a programmer new to a section of
    code can quickly attack the problem, not the
    style
   Result: improved collaboration
Traditional Problems, XP
solutions
   Problem: A programmer spends hours on a
    problem that the person in the next cubicle could
    have answered in 2 minutes
   Solution: XP includes daily meetings where each
    programmer shares what he or she is working on.
       This gets difficulties out in the open
   Solution: Pair programming helps engineers keep
    track of what everyone on the team knows best
   Result: improved collaboration
Senior Developer views of XP

   Interviewed 2
   Not a pure XP environment, but rapid
    development
   These developers are familiar with XP
   Their names are Scott and Pete
Senior Developer views of XP

   Planning
       Both agreed that a clear “forest” view is
        necessary – understand the problem to solve
           Easier with short iterations
   Short iterations
       Pete: major construction requires longer
        iterations, at the risk of schedule predictability
           Suggests conservative scheduling for heavy
            construction phases
Senior Developer views of XP

   Metaphor
       Pete: One person sets the direction for a
        product
           Consider feedback from others
           This is a “best practice” in other processes
           XP does not do this, more consensus based
Senior Developer views of XP

   Simplicity
       Scott: strike a balance with Flexibility
       Pete: believes maximum simplicity can
        still be flexible
   Testing
       Pete: unit tests for every line difficult in
        practice
           Acceptance tests equally important
Senior Developer views of XP

   Refactoring
       Both agree that refactoring has been
        going on for a long time
           But making it an official part of the process
            helps, especially for scheduling
   Pair programming
       Pete hates pair programming
           Feels that a solid engineer can beat any 2
            engineers together
Senior Developer views of XP

   Collective ownership
       Pete: Everyone should be familiar with all parts
        of the system
           BUT there should be a “Design Owner” for important
            sections, to maintain vision in the small
   40 hour week
       Both feel this is possible in a stable world
       Pete would rather work more some of the time
           40 hours is very arbitrary
Senior Developer views of XP

   Customer on the team
       Pete: Real customers don’t know what
        they want
           Give shallow feedback
           The “Vision Keeper” for the product should
            know enough about the customers to be the
            “uber user”
Strategies in XP


      Collaboration in Software
      Development Process
XP – Strategies

   Traditionalism is skeptical towards
    change
   Paradigm shifts require strategies to
    tackle…
        Planning
        Management
        Design
        Development
        Testing
XP - Planning Strategy

   Goal:        maximize value
   Game plan:   low investment, high return
   Actors:      developers, managers, clients
   Tools:       user stories, CRC cards
   Actions:     explore, commit, steer
XP - Management Strategy

   Estimate: metrics, *relevance*
   Train:      actors (programmers)
   Track:      progress, compatibility
   Reorganize: teams, solutions, problem space
XP - Design Strategy

   Stick to the values!
   Simplicity
   Low initial investment
   Lightweight
   Incremental change
XP - Design Strategy (cont’d…)




Cost of change grows dramatically over time
XP - Design Strategy (cont’d…)




Cost of change remains cheap over time
XP - Development Strategy

   Quick iteration
   Small releases
   Collective ownership
       Pair programming
       Refactoring
       Testing
       Continuous integration
XP - Testing Strategy

   Unit
                 Test suite = Product specs.
   Acceptance
   Parallel     You pass the tests, you
   Stress       fulfill the specs.
   Monkey !!
VCAPS – (Vehicle Cost and Profit System)
Ford Motor Company, 1993

   Planning – Changing specs, priorities, regulations…
    caught up!!
   Management – Separated from technical issues.
    Had a low view of developers’ efficiency.
   Design – Mostly centralized, code got UGLY
   Leadership and Coaching – Low morale
   Integration: 20+ developers, race to the finish, ONE
    integrator working nights
   Testing – Last two months. Bugs had a domino
    effect.
VCAPS – XP to the rescue

   Planning – CRC card culture: bigger picture
   Management – Integrated. Developers had
    responsibility and authority. One-week
    iterations. Upper management worked as
    before.
   PP – caught up more slowly, initial
    reluctance. Teaching techniques & level of
    experience. Pairs vs. Trios.
VCAPS – XP to … (cont’d)

   Integration: small releases nip the problem
    in the bud.
   Testing – smaller sized unit and functional
    tests: more targeted, easier to automate.
VCAPS - Conclusion
   9 out of 12 XP practices embraced.
   Threw away old system and started afresh.
   Took one year for people to start enjoying.
   Management stopped seeing value.
    Customers still wanted it. Got canned!!
   Lessons:
       Transition slowly, one practice at a time.
       Management must take the lead.
       test vigorously, release frequently.
Activity


       Collaboration in Software
       Development Process
Pair Programming


     Collaboration in Software
     Development Process
Introduction

   Two programmers working side by
    side as stated by Kent Beck in
    Extreme Programming (XP) in 1996.
   Objective is to improve software
    Quality and reduce Time-to-Market.
   Pairs enjoy problem-solving process
    and outperform individual
    programmers.
   They have greater confidence in their
    solutions.
Pair Jelling

   Two programmers jointly produce one
    artifact.
   One partner is the driver and has control of
    the pencil/mouse/keyboard and is writing
    the design or code.
   The other person continuously and actively
    observes the work of the driver (watching
    for defects, thinking alternatives, looking up
    resources, and considering strategic
    implications of the work at hand).
Pair analysis and Pair design

   It is important for the pair to collectively
    agree on the development direction and
    strategy outlined during these stages.
   “Two brains are better than one” when
    performing analysis and design.
   Significantly decreases the probability of
    proceeding with a bad design.
   Other partner can think more strategically
    about implications of the design.
   Avoid “design tunnel vision”.
Pair implementation

   One programmer types into the
    computer while the other is actively
    engaged in observing, performing a
    continuous code review.
   Efficient form of defect removal:
    removed right from the start.
   Drawback: most programmers prefer
    to do a thorough review of their
    individual work and incorporate it into
    the project.
Pair Testing

   Is the least critical part of the
    development cycle, as long as the
    pair develops the test cases
    together.
   Testing discovers new bugs. Pair
    testing allows for different points of
    view on how to test an application,
    hence finding even more bugs.
Good Practices for Pair
Programming

   Don’t hit your partner: make sure
    your partner stays focused and on-
    task.
   Put things back where they belong:
    have confidence but not too much
    confidence.
   Clean up your mess: The “watch over
    the shoulder” technique epitomizes
    defect prevention and efficient defect
    removal.
Good Practices for Pair
Programming

   Don’t take things too seriously:
    “Ego-less programming”
   Say you’re sorry when you hurt
    somebody while moving furniture:
    Appropriate workspace layout is critical
    to the pair success.
   Wash your hands of skepticism
    before you start: develop an
    expectation of success and greet your
    collaborative partner.
Good Practices for Pair
Programming

   Flush: Pair programmers will work on
    something independently, when rejoining
    your partner review your work done
    separately.
   When you go out into the world, watch
    out for traffic, hold hands and stick
    together: your work is done together, do not
    leave your partner apart.
   Be aware of the power of two brains: You
    remember better, more knowledge and
    skills.
Good Practices for Pair
Programming

   Take a break from working together
    every afternoon: experiment new
    prototypes, deep-concentration, logical
    thinking is preferred to do it alone.
   Live a balanced life – learn some
    and think some and draw and paint
    and sing and dance and work every
    day some.
Issues in Pair Programming

   How do you create a good pair?
       One personality might consume the other. Or
        two clashing personalities might not get work
        done.
   Programmers tend to split work for more
    rote, routine and simple coding of a project.
   Design review might be best in larger
    numbers (Design Review Boards). But
    Design alone is better in small numbers.
Issues in Pair Programming

   What is a conducive workplace?
       Offices and cubicles are regular settings
        for offices that hinder pair programming.
       “Like many kings, some managers use
        divide-and-conquer tactics to rule their
        subjects, but programmers need contact
        with other programmers.” (Weinberg
        1998).
Issues in Pair Programming

   How much time should it occupy in a
    work day?
       Many programmers do not agree how
        much time they should give for pair
        programming.
       From all-day extreme, to few minutes a
        day.
   Alternative Solutions: “Distributed pair
    programming” (Baheti, Gehringer,
    Stotts).
Interviews and Results

   An experiment in Temple University
    showed that pair programmers
    produced 40% more quickly and
    effectively. Contrary to the notion of
    managers that believe that it would
    mean a 100% increase of production
    time.
   96% stated that they enjoyed their job
    more than when they programmed
    alone.
Interviews and Results

   Design is good in pairs, even better in 3-5
    members. But more than that it hinders
    (never reach to an agreement).
   Pair programmers is a positive form of peer
    pressure.
   Simple tasks should be done alone, but by
    pair design you can identify which tasks
    need to be done in pairs.
   Pairs enjoy their work more because they
    are more confident in their results.
Interviews and Results

   Good way to bounce new ideas off.
   You can spend more time doing
    challenging design and less time doing
    annoying debugging (due to better
    quality of product).
   “We nailed that one” feeling.
   People who are forced to pair-program
    despite their resistance might not do
    well.
Pair Programming


     Collaboration in Software
     Development Process
XP: A Construction
Management Perspective
   Both software and construction
    industries are “project-driven.”

   Software projects can be
    outsourced, while construction
    projects are heavy and fixed, built
    by local labor, having tremendous
    uncertainties.
Projects

   What is a project?

   Why project management?

   Why so many projects fail?

   How can we measure the
    “success” of a project?
Project Partnering

   Background
   How construction industry
    practices partnering?
   Initial partnering meeting
   Why it works?
   What software industry can
    learn from it?
Vague specifications

   Build as you design

   Frequent communications

   Flexible organization
   Virtual team design (VTD)
                  CONTROLS
              (“Assumed Model”)

                                  OUTPUTS
                    VDT
  INPUTS                          (“Measures
                 Simulation
(variables)                           of
                   Model
                                  progress”)

               MECHANISMS
                (“Systems”)
Virtual team design (VTD)

   Tool: SimVision 3.11
   A computational simulation
    model of project organizations
   VDT analysis objectives
       Can a team finish a project within
        a reduced time?
       What are the predicted effects on
        project when we change the
        organization of a project team?