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 solve 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 developers Assume simplicity –solve today’s problems today, and tomorrow’s problems tomorrow Incremental change –solve problems with a series of the smallest 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

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, clear 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: DateStatusTo DoComments _____________________________________

Engineering Task Card Date: ________ Story Number: _______ Engineer: _________________ Task Estimate: ____________ Task Description: Software Engineer’s Notes: Task Tracking: DateStatusTo DoComments _____________________________________

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 on the story cards to make a good first release Planning –Customers and programmers agree on a date by which the smallest, most valuable set of stories will be done The plan for the first release should be between 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 Xprogramming –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 process and call it to their attention Consultant –XP Projects often do not require specialists XP Team Roles

Big Boss –Provides the team with courage, confidence, and 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 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