Extreme Programming - Computers and Scientific Thinking - Lecture Slides, Slides of Computer Science

Download Extreme Programming - Computers and Scientific Thinking - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Extreme Programming

Outline

• Traditional life cycle vs. XP
• XP motto: “embrace change”
  • How does this attitude compare with that

implicit with

traditional waterfall software life cycle?

• XP values
• XP practices
• Pair programming
• An XP development road map
• References

2

Successes in industry

• Chrysler Comprehensive Compensation system
  • After finding significant, initial development problems, Beck and Jeffries restarted this development using XP principles
  • The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods, went into production almost on schedule, and is still operational today (Anderson 1998)
• Ford Motor Company VCAPS system
  • Spent four unsuccessful years trying to build the Vehicle Cost and Profit System using traditional waterfall methodology
  • XP developers successfully implemented that system in less than a year using Extreme Programming (Beck 2000).

4

XP Introduction

Embrace change

• In traditional software life cycle models, the cost of

changing a program rises exponentially over time

• Why would it cost more to make large changes during testing than during requirements specification?
• A key assumption of XP is that the cost of changing a

program can be hold mostly constant over time

• Hence XP is a lightweight (agile) process:
  • Instead of lots of documentation nailing down what customer wants up front, XP emphasizes plenty of feedback
  • Embrace change: iterate often, design and redesign, code and test frequently, keep the customer involved
  • Deliver software to the customer in short (2 week) iterations
  • Eliminate defects early, thus reducing costs

5

Communication

• What does lack of communication do to projects?
• XP emphasizes value of communication in many of its practices: - On-site customer, user stories, pair programming,

collective ownership (popular with open source

developers), daily standup meetings, etc.

• XP employs a coach whose job is noticing when people aren’t communicating and reintroduce them - Is this a role for yours truly in our class?

7

XP values

Simplicity

• ''Do the simplest thing that could possibly

work'' (DTSTTCPW) principle

• Elsewhere known as KISS
• A coach may say DTSTTCPW when he sees an XP

developer doing something needlessly

complicated

• YAGNI principle (''You ain’t gonna need it'')
• How do simplicity and communication support

each other?

8

XP values

Courage

• The courage to communicate and accept

feedback

• The courage to throw code away

(prototypes)

• The courage to refactor the architecture of

a system

• Do you have what it takes?

10

XP values

Twelve XP Practices

• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Test-driven development
• Refactoring
  • Pair Programming
  • Collective Ownership
  • Continuous Integration
  • 40-Hours a Week
  • On-Site Customer
  • Coding Standards

11

XP Practices

Small and simple

• Small releases
  • Start with the smallest useful feature set
  • Release early and often, adding a few features each time
  • Releases can be date driven or user story driven
• Simple design
  • Always use the simplest possible design that gets the job done
  • The requirements will change tomorrow, so only do what's needed to meet today's requirements (remember, YAGNI)

13

XP Practices

Test-driven development

• Test first: before adding a feature, write a test for it!
  • If code has no automated test case, it is assumed it does not work
• When the complete test suite passes 100%, the feature is accepted
• Tests come in two basic flavors…
• Unit Tests automate testing of functionality as developers write it
  • Each unit test typically tests only a single class, or a small cluster of classes
  • Unit tests typically use a unit testing framework, such as JUnit (xUnit)
  • Experiments show that test-driven development reduces debugging time
  • Increases confidence that new features work, and work with everything
  • If a bug is discovered during development, add a test case to make sure it doesn’t come back!
• Acceptance Tests (or Functional Tests ) are specified by the customer to test that the overall system is functioning as specified - When all the acceptance tests pass, that user story is considered complete - Could be a script of user interface actions and expected results - Ideally acceptance tests should be automated, either using a unit testing framework, or a separate acceptance testing framework

14

XP Practices

Pair programming in CS classes

• Experiment at NC State
  • CS1— programming in Java
  • Two sections, same instructor, same exams
  • 69 in solo programming section, 44 in paired section
  • Pairs assigned in labs

16

XP Practices

Results : 68% of paired students got C or better vs. 45% of solo students Paired students performed much 16-18 points better on first 2 projects No difference on third project (perhaps because lower performing solo students had dropped before the third project) Midterm exam: 65.8 vs. 49.5 Final exam: 74.1 vs. 67. Course and instructor evaluations were higher for paired students

Similar results at UC Santa Cruz (86 vs. 67 on programs)

Pair programming in CS classes?

• Strategies for making it work
  • Peer evaluation helps motivate students work; perceived fairness
  • Pair programming in labs alleviates scheduling time for meetings
  • Pair programming labs (with role reversals) are noisier than solo labs
• Instructors need to coach and reinforce pair programming
  • Students are used to individual work
  • Students are reluctant to switch roles (need pausing points)
  • Students show increased willingness with each passing week
• 90% of students say they are compatible (Katira et al., 2004)
  • Experienced programmers may want to work alone
  • Inexperienced students may be disengaged
  • Students may prefer being matched with students based on achievement level, gender or culture

17

XP values

More practices

• 40-hour work week
  • Programmers go home on time
  • “fresh and eager every morning, and tired and satisfied every night”
  • In crunch mode, up to one week of overtime is allowed
  • More than that and there’s something wrong with the process
• On-site customer
  • Development team has continuous access to a real live customer, that is, someone who will actually be using the system, or a proxy
• Coding standards
  • Everyone codes to the same standards
  • Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code

19

XP Practices

13

th XP practice:

Daily standup meeting

• Goal: Identify items to be accomplished for

the day and raise issues

20

• Everyone attends,

including the customer

• Not a discussion forum
• Take discussions offline
• Everyone gets to speak
• 15 minutes