Extreme Programming

Document Sample
Extreme Programming Powered By Docstoc
 Embrace Change
Chapter 1

What is XP?
     Software Development Risks
•   Schedule slips
•   Project canceled
•   System goes sour
•   Defect rate
•   Business misunderstood
•   Business changes
•   False feature rich
•   Staff turnover
Chapter 2

Learning to Drive

a description of an
 XP session
Chapter 3

Values, Principles,
 and Practices
        Are you ready for XP?
• Stay Aware. Adapt. Change.

• What are principles?

• What are values? (don’t list them)

• What are practices?
Chapter 4

               XP Values
•   Communication
•   Simplicity
•   Feedback
•   Courage
•   Respect
•   Others??
Chapter 5

                      XP Principles
•   Humanity                 •   Flow
•   Economics                •   Opportunity
•   Mutual Benefit           •   Redundancy Failure
•   Self-similarity          •   Quality
•   Improvement              •   Baby Steps
•   Diversity                •   Accepted
•   Reflection                   Responsibility
Chapter 6

               Summary of Practices
      10-minute build
                                                        test-first programming
 continuous integration                 programming
                                                       incremental design
  weekly cycle
                     planning      energetic work
 quarterly cycle

                                                   negotiated scope contract
                                        business    pay per use
 shared code single code base
                 programming                       daily deployment
code & tests

                           team root cause analysis          COROLLARY
      team continuity

      shrinking teams           real customer involvement
Chapter 7

Primary Practices
             Primary Practices
•   Sit Together            •   Slack
•   Whole Team              •   10-Minute Build
•   Informative Workspace   •   Continuous Integration
•   Energized Work          •   Test-First Programming
•   Pair Programming        •   Incremental Design
•   Stories
•   Weekly Cycle
•   Quarterly Cycle
Chapter 8

Getting Started
           Getting Started
• As you consider implementing XP, which
  person should you try to change first?
• Which practices should you try to
  implement first?
Chapter 9

Corollary Practices
             Corollary Practices
•   Real Customer Involvement
•   Incremental Development
•   Team Continuity
•   Shrinking Teams
•   Root-Cause Analysis
•   Shared Code
•   Code and Tests
•   Single Code Base
•   Daily Deployment
•   Negotiated Scope Contract
•   Pay-Per-Use
Chapter 10

The Whole XP Team
           The Whole XP Team
•   Testers
•   Interaction Designers
•   Architects
•   Project Managers
•   Product Managers
•   Executives
•   Technical Writers
Chapter 11

The Theory of
         Theory of Constraints
• What does the theory say?

• How do you find the constraint?

   Washer: 45   Dryer: 90
                            Folding: 15
              Waterfall Process
• Can bottleneck be identified by knowing
  how long each step should take?

 Marketing Requirements Document

     Engineering Requirements Document
                                          move design?
                                          don’t design features
                                          that never get
                                          implemented (ERD
       move         Integration Testing   bottleneck)
                Push vs Pull Model
   Specification       Design      Code             Test

“Push” model

                   Specification          “Pull” model

       Design                      Test

Chapter 12

Planning: Managing
        Planning: Managing Scope
Three variables by which to manage projects:
    –   speed
    –   quality
    –   price
•   Fourth variable sometimes overlooked: scope

Steps in every timescale:
1. List the items of work to do
2. Estimate the items
3. Set a budget
4. Agree on the work to be done within the budget.
   Don’t change the estimates or the budget. Be
   sure everyone is heard!
          Yesterday’s Weather
• Plan in any given week for exactly as
  much work as you actually accomplished
  in the previous week. Adjust as soon as
  you are sure of new information.

• What if progress is slower than planned?
  – distractions?
  – helpful practices?
  – reprioritize stories
Where should stories be?

Chapter 13

Testing: Early, Often
 and Automated
• Defects destroy trust
• Without trust, people spend must of their
  time defending themselves against the
  possibility that someone else may have
  made a mistake.
• Is it possible to eliminate all defects?
• Which is more expensive, to fix defects or
  to prevent them?
• Which XP practices are aimed at reducing
• What is the concept of double-checking?
                                                long feedback loops =
Defect Cost                                     many residual defects,
Increase (DCI)                                  increased cost

           Frequent testing reduces costs and defects
• Dangerous to copy results of a calculation as its
  expected value: you’ve only thought it through
   – calculate by hand
   – write one set of tests from programmer’s perspective,
     another from user’s
• With manual testing, the more stressed the
  team, the more mistakes the team members
  make (in both coding and testing)
• With automated tests, running the tests relieves
• Which comes first, test or code?
Chapter 14

Designing: The Value
 of Time
Physical Design vs Software

              The Question
• Not whether to design but when to design
• Pendulum has swung from ‘design
  everything’ to ‘design nothing’ – not good!
• Alternative to Big Design Up Front is Little
  Design Up Front or Enough Design Up
• XP is not ‘design nothing’ it’s ‘design
                When to design?

 Quality                                                Threshold

           Instinct     Thought      Experience
   Any old design will do – go ahead and design today


             Instinct    Thought       Experience

    Some design thought or experience required – not as clear
    when to design, but unconscious design leads to failure
               When to design?


          Instinct   Thought       Experience
 Incremental design is inevitable, must have some experience
 to get reasonable quality
                When to design?


           Instinct     Thought      Experience
   Experience doesn’t help, designing sooner makes sense


             Instinct    Thought       Experience

 Lots to learn from experience, design just enough to get going
         Once and Only Once
• Important Design Heuristic
• Data, structure or logic should exist in
  only one place in the system.
Chapter 15

Scaling XP
        Scales along dimensions:
•   Number of people
•   Investment
•   Size of entire organization
•   Time
•   Problem complexity
•   Solution complexity
•   Consequence of failure
                         Some ideas
• conquer-and-divide vs divide-and-conquer

Programming               Smaller
  Problem                 Projects

                                     Solve with small teams

 Integrate frequently.
Chapter 16

       Sabre Airline Solutions
• What useful advice did you get from this
Chapter 17

Creation Story
         The beginning of XP
• What motivated the creation of the XP

• What mistake did Kent make in
  November? (until Chet reminded him how
  XP was supposed to work)
Chapter 18

Taylorism and
           Factory Productivity
• Taylor & disciples (Gilbreths, Gantt) created
  Scientific Management – industrial engineering
  based on methods of science: observation,
  hypothesis and experimentation
• Observe worker, devise alternative ways to do
  task, pick best way (“The One Best Way”). Then
  standardize through whole factory.
• Limitations due to three simplifying assumptions:
  – Things usually go according to plan
  – Micro-optimization leads to macro-optimization
  – People are mostly interchangeable and need to be told
    what to do
Implications for Software Engineering
• Time-and-motion studies don’t apply (and
  we don’t try to use them)
• Social structure also ill-suited, but we
  sometimes try to use it
  – separate planning from execution
  – separate quality department
• “Quality, architecture and frameworks are
  too important to be left to Taylorist social
  structures that impede the flow of
  communication and feedback vital to
  creating working, flexible and inexpensive
  software in a changing world.”
Chapter 19

Toyota Production
                   Toyota Factory
                                Bad Part               the
                                 Here!                Chain

• Workers don’t get in trouble for pointing out defects, they are
  praised for telling the truth and pointing out flaws
• Everyone is responsible for quality
• Waste is eliminated through kaizen (continuous improvement) and
  all workers are involved
• Parts are immediately put to use, not stockpiled. Gives feedback
  about each part of process (if backlog, some part not working)
Chapter 20

Applying XP
Reasons performance might fall…
• May not have enough experience
• May not have been ready for the new
  practice, because some hidden
  prerequisites weren’t in place

What to do?
• Change back and address underlying issue
• Get a coach
     When you shouldn’t use XP
• XP is ineffective in organizations whose
  actual values are at odds with the XP
  values. If an organization’s actual values
  are secrecy, isolation, complexity,
  timidity, and disrespect; suddenly
  expressing the opposite values through a
  new set of practices will cause trouble
  rather than create improvement.
Chapter 21

Chapter 22

Offshore Development
Chapter 23

The Timeless Way of
Chapter 24

Community and XP
Chapter 25

XP Stories
          Helpful Resources
• Planning Extreme Programming, Kent
  Beck and Martin Fowler
• Extreme Programming Installed, Ron
  Jeffries, Ann Anderson and Chet
• Extreme Programming Explored, William
         What is a Release?
• A version of the system with enough new
  features to be valuable to the customer
• Probably represents 1 – 3 months work
• Release planning can take one to a few
                Release Planning Game
                               Write a Story
                  “Too big”                        “Don’t know how”
                               Estimate Story
           Split Story                                Spike Story

                                                        may need “quick”
smaller stories less risky                              exploration – couple days
                                 Sort Stories
> 3 weeks, split!                                       max, throw-away code

                              Declare velocity

                               Choose Scope

*Only customer should write story, only when they want a feature
                              A Story             must provide value to
                                                  customer, not neat new

           Story: Story Title

           Several sentences to describe a desired feature.

                                                Cite or attach

           This is a promise to discuss a feature, not a
           complete description of it.

           Estimate: Added by programmer, in “story points”

Put story on index card: keep
terse (the shorter the better),       Ideal programmer weeks
easy to manipulate
                     Release Planning

                                                Could have

                           Customer sorts
                                                 Should have

                                                    Must have

NOTE: Customer can change stories,
accept new date, get a different team…
but can’t change the estimates!
      Customer chooses                      declare velocity
      stories                               (story points in iteration,
                                            1-3 weeks in iteration)
                     Sample Stories
Vision                                   a little vague, but it’s a starting
Produce a system for faculty to
track student progress

Story: Query=>Details                          Programmers can’t estimate,
                                               tell customer it’s too big
Given a query, return a list of all matching
items. Look at the details of any items.
Store the information in any format.
                    Split Story

           Story: Query

           Want to query by student name, student
           username or by course

           Story: Details

           Want to know student name, email, GPA,
           major, minor, student ID, courses taken
           and grades received.

           Story: Any format

           Want to store information as csv or as
Requires   xml or in .rtf
                     More stories
Programmers may prompt customers for stories, for example about
types of systems, performance, etc.

           Story: Portable

           System should be usable on a PC. Running
           under Unix would be a plus.

Programmer may add constraint to the story when doing the estimate
(customer must agree). Or story could be split, so parts could be
estimated separately (e.g., PC vs Unix)

           Story: Portable (Java)

           System should be usable on a PC. Running
           under Unix would be a plus.
             More on Stories
• Stories should be independent. Can then be
  built in any order (can’t always achieve, of
• Each story must be testable.
• Should trace acceptance test to story, not
  underlying class.
• Writing stories should be iterative. Write
  between 2-5 stories then stop. Estimate
  stories, conversation between programmers
  and customer.
         More quick examples
• Show hotels
  – Show hotels near a place
• Book a hotel
  – Book a hotel. Charge to credit card and check
    credit card validity. Send confirmation.
• Cancel hotel reservation
  – Find reservation, cancel it, apply credit on
    credit card, send confirmation
• Bank Overdraft
  – When a transaction causes a customer’s
    account to go into overdraft, transfer money
    from the overdraft protection account, if any
            Estimating Stories
Three keys to estimation:
• Keep it simple
• Use what happened in the past
• Learn from experience

Look for something similar you’ve already done.
  How long did it take? Need to keep records!
Estimates are not commitments.
Goal: continuously improve ability to make
  estimates. Choose optimistic estimates: don’t let
  estimates get too long, BUT don’t let team be too
        The XP Flexibility Test
• Unwrap package of index cards
  – 4x6 or 5x8, unlined
• Scribble to test pens
• Tear up cards
• Any resistance???
  When are you done writing stories?

• Never (until the project is canceled)

• But majority written in early phases
   When can you begin to code?
• When the customer is sure the most
  important stories have been identified
  – and
• You have enough stories to develop for
  awhile (several months)
• Rule of thumb: need at least one story per
  programmer per month, two is better.
What do you do with stories that have
         been developed?

• Pitch them!

• But be sure you have good acceptance
  tests in place first.
  Do Programmers Write Stories?
• Better if they don’t
• May work with customer, conversations
  become stories
• Resist temptation to write stories
• Relate “technical stories” back to real
  customer need
     What about conversations?
• Capture as additional documentation
• Do as Class Responsibility Collaborator
  (CRC) design session
• Create acceptance tests
        Interesting Anecdotes
• Chet’s fault
• Impossible to estimate

Shared By: