Extreme Programming

David Li

CTO, DigitalSesame

Problem in Developing Software

• The Basic Problem - Risk– Schedule slips– Project canceled– System goes sour– Defect rate– Business misunderstood– Business changes– False feature rich– Staff turnover

Software Engineering Models

• Waterfall Approach– Sequential– Analysis, Design, Development, Test, and

Release

• Spiral Approach– An iterative waterfall

• RUP (Rational Unified Process)– User-centered design– Business system modeling– Heavy investment up front on analysis

The Cost of Change

• In the past, the cost of changing software over time was exponential– Requirements: $1– Analysis: $10– Design: $100– Implementation: $1,000– Testing: $10,000– Production: $100,000

• In the present, XP inverts and flattens the cost change curve

System Control Variables

• Cost– Often he most constrained variable– Throwing more money at a problem does not always sol

ve it

• Time– More time can improve quality and increase scope

• Quality– The most difficult control variable

• not as easy to measure

– External quality and internal quality

• Scope

Variables Control

• External forces (managers, customers) get to pick the value of 3 of the 4 variables

• Development team picks the value of the 4th

The Four Values of XP

• Communication– Pair programming– On site customers

• Simplicity– “What is the simplest thing that could possibly work?”

• Feedback– “Have you written a test case for that yet?”

• Courage– it takes courage to fix architectural flaws 3/4 of the way

through a project– it takes courage, and humility, to toss code

The Basic Principles• Rapid feedback– from both customers and other developer

s

• Assume simplicity–solve today’s problems today, and tomorr

ow’s problems tomorrow

• Incremental change–solve problems with a series of the smalle

st changes that will make a difference

The Basic Principles

• Embracing change

• Quality work–of the 4 control variables, the only

possible values are “excellent” and “insanely excellent”

• Teach learning

• Small initial investment

• Play to win

• Concrete experiments

• Open, honest communication

• Work with people’s instincts, not against them

The Basic Principles

The Basic Principles

• Accepted responsibility

• Local adaptation

• Travel Light

• Honest measurement

The Basic Activities• Coding

–coding as learning

–coding as communication

• Testing

–“Anything that can’t be measured, doesn’t exist.” Lock, Berkeley, Hume

–automated testing

–unit tests and integration tests

The Basic Activities

• Listening

–“Programmers don’t know anything.”

• Designing

–creating a structure that organizes the logic in the system

The Practices• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

The Practices

• Pair Programming

• Collective Ownership

• Continuous integration

• 40-hour week

• On-site customer

• Coding standards

• Business people decide:– Scope– Priority– Composition– dates of releases

• Technical people decide:– Implementation estimates– Consequences– Process– Detailed scheduling

The Planning Game

Small Releases

• Releases should be as small as possible

Metaphor

• Each project should be guided by a single overarching metaphor, I.e. desktop, business objects, such as customers and orders

Simple Design

• Passes all the tests

• Has no duplicated logic

• States every intention important to the team

• has the fewest possible classes and methods

Testing

• Automated tests are required for all program features

• Is there a way of changing the existing program to make adding a new feature simple?

• Now that I’ve added the feature, can I do anything to make the program simpler?

Refactoring

Pair Programming

• 2 people, 1machine, 1 keyboard, and 1 mouse

• 1 person is focused on the here and now, the other person is thinking of the bigger picture

Collective Ownership

• Anybody who sees an opportunity to add value to any portion of the code is required to do so

Continuous Integration

• Code is integrated and tested every few hours, not weeks or months

40-Hour Week

• “Overtime is a symptom of a serious problem on the project”

• A real live customer(future product user) must site with the team…being available to answer questions

On-site Customer

Coding Standards

• it should become impossible to tell who wrote what code

• no duplicate code

• do it right, or don’t do it at all!

How to Make this Work

• Management Strategy– Phased delivery, quick and concrete feedback, c

lear communication of business needs, and specialists for special tasks

• Facilities Strategy– Open workspaces with a common programming

area

How to Make this Work

• Planning Strategy– The Planning game has 2 players, business and

development– Relies on the creation of Story Cards

Customer Story and Task Card

Date: ________ Story Number: _______Type of Activity: New: __ Fix: __ Enhance: __Priority: __________________Prior Reference: ____________Functional Test: ____________Task Description:

Notes:Task Tracking:Date Status To Do Comments_______________________________________________________________________________________________________________

Engineering Task Card

Date: ________ Story Number: _______Engineer: _________________Task Estimate: ____________Task Description:

Software Engineer’s Notes:Task Tracking:Date Status To Do Comments_______________________________________________________________________________________________________________

• Relies on continuous integration

• Collective ownership

• Pair programming

• Coding standards

Development Strategy

Design Strategy

• Always have the simplest design that runs the current test suite

• Refactoring

Testing Strategy

• Write tests before we code

• Derive tests from the customer’s perspective

XP Project Lifecycle

• Exploration–Complete when there’s enough material o

n the story cards to make a good first release

• Planning–Customers and programmers agree on a d

ate by which the smallest, most valuable set of stories will be done• The plan for the first release should be betwe

en 2 – 6 months

XP Project Lifecycle

• Iteration to First Release– Each iteration produces a set of functional test

cases for each scheduled story• 1 – 4 weeks in duration

• Productionizing– The end product of a release…feedback cycle is

tightened, iterations are weekly or even daily

XP Project Lifecycle

• Maintenance– The normal state of an XP project– Requires simultaneously producing new

functionality, keeping the existing system running, incorporating new folks into the team, and bidding farewell to other members

• Death– The customer can’t generate any new stories– Or…the system isn’t delivering

XP Team Roles

• Programmer– The heart of XP– Requires the habit of simplicity

• Customer– The other half of the essential duality of Xprogra

mming–Must write good stories–Must write functional tests

XP Team Roles

• Tester– Focused on the customer..helps the customer

generate functional tests

• Tracker– The conscience of the team…responsible for

making estimates

• Coach– Responsible for the process as a whole–Must notice when team is deviating from the pro

cess and call it to their attention

• Consultant– XP Projects often do not require specialists

XP Team Roles

XP Team Roles

• Big Boss– Provides the team with courage, confidence, an

d occasional insistence that they do what they say they do

20-80 Rule and XP• The Rule: “80% of the benefit comes

from 20% of the work”– This tells the XP Programmer to put the most

valuable 20% of functionality into production, do the most valuable 20% of the design, and rely on the 20-80 rule to defer optimization

What Makes XP Difficult?

• It’s not the concepts, it’s the execution!– There are so many factors that can throw the

process off course