introduction to extreme programming xp n.
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to eXtreme Programming (XP) PowerPoint Presentation
Download Presentation
Introduction to eXtreme Programming (XP)

Loading in 2 Seconds...

play fullscreen
1 / 58

Introduction to eXtreme Programming (XP) - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Introduction to eXtreme Programming (XP)' - quincy

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
introduction to extreme programming xp

Introduction to eXtreme Programming (XP)

Collaboration in Software Development Process

xp overview
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
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 solutions1
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 solutions2
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 solutions3
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 solutions4
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 solutions5
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 solutions6
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 solutions7
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 solutions8
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 solutions9
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 solutions10
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 solutions11
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
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 xp1
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 xp2
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 xp3
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 xp4
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 xp5
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 xp6
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

Strategies in XP

Collaboration in Software Development Process

xp strategies
XP – Strategies
  • Traditionalism is skeptical towards change
  • Paradigm shifts require strategies to tackle…
    • Planning
    • Management
    • Design
    • Development
    • Testing
xp planning strategy
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
XP - Management Strategy
  • Estimate: metrics, *relevance*
  • Train: actors (programmers)
  • Track: progress, compatibility
  • Reorganize: teams, solutions, problem space
xp design strategy
XP - Design Strategy
  • Stick to the values!
  • Simplicity
  • Low initial investment
  • Lightweight
  • Incremental change
xp design strategy cont d
XP - Design Strategy (cont’d…)

Cost of change grows dramatically over time

xp design strategy cont d1
XP - Design Strategy (cont’d…)

Cost of change remains cheap over time

xp development strategy
XP - Development Strategy
  • Quick iteration
  • Small releases
  • Collective ownership
    • Pair programming
    • Refactoring
    • Testing
    • Continuous integration
xp testing strategy
XP - Testing Strategy


Test suite = Product specs.

You pass the tests, you fulfill the specs.

  • Unit
  • Acceptance
  • Parallel
  • Stress
  • Monkey !!
vcaps vehicle cost and profit system ford motor company 1993
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
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
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
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.


Collaboration in Software Development Process

pair programming

Pair Programming

Collaboration in Software Development Process

  • 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
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
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
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
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
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 programming1
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 programming2
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 programming3
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
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 programming1
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 programming2
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
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 results1
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 results2
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 programming1

Pair Programming

Collaboration in Software Development Process

xp a construction management perspective
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.
  • What is a project?
  • Why project management?
  • Why so many projects fail?
  • How can we measure the “success” of a project?
project partnering
Project Partnering
  • Background
  • How construction industry practices partnering?
  • Initial partnering meeting
  • Why it works?
  • What software industry can learn from it?
vague specifications
Vague specifications
  • Build as you design
  • Frequent communications
  • Flexible organization
virtual team design vtd
Virtual team design (VTD)


(“Assumed Model”)












virtual team design vtd1
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?