Extreme Programming:Introduced

Matthew HeusserExcelon Development – xndev.com - matt@xndev.comPresented to CS 611 at GVSU, 4/6/2005

Surfin’ the waterfall

• The Caste System

• The factory mentality

• Scientific Management

• ‘Managing Scope Creep’ and other bad ideas

• Can we have predictability without demeaning people?

Enter XP

• If our software development groups could just provide visibility and consistency, maybe customers, management, and coders could share the uncertainty.

• “Extreme Programming is a discipline of business and software development that focuses both parties on common, reachable goals. XP teams produce quality software at a sustainable pace. The practices that make up “book” XP are chosen for their dependence on human creativity and acceptance of human frailty.”

– Kent Beck, Extreme Programming Installed

Implications

• XP is a from-scratch development model that expects change and tries to share risk, instead of forcing it onto one group or another.

• The Truth is always a good thing. Even when it’s bad news.

• Self-Determination (Content, Collaboration, and Choice)

• The central person in the story of development is the CODER.

‘Book’ XP

• Whole Team • Small Releases• Simple Design• Test-First Development Design Improvement • Coding Standard Metaphor• Sustainable Pace Continuous Integration• Pair Programming Planning Game• Collective Code Ownership Customer Tests

Agile requirements …

• Customer and Developers write stories• Developers estimate stories in “Points”;

– 1-3 points per story

• Customers Prioritize Stories• Developers break Stories into tasks• Developers sign up for work • 1st iteration: Roughly 3 weeks

Iterations

• Iterative

• Feature-Based

• Time boxed

• Incremental– Jim Highsmith, Agile Project Management, 40

• Inch-Pebble Concept

Releases

• However often you need to realease

• 3 months sounds about right (or does it?)

‘Whole’ Team Concept

• Customers are members of the team

• Co-Location

• Who needs a ‘spec’?

“When will you be done?”

• 3 weeks

• Implications

Velocity

• V = D/T

• Velocity = Points Accomplished/Weeks

• Velocity normalizes over time

• Points for a story – “About the same size as” heuristics get better over time

On estimating

• Simple Working System

• Feature at a time

• Spikes as risk management

Design Sessions

• Two guys at a Whiteboard

• Emergent design (3 weeks ain’t that long)

• Very few, high-value artifacts

• Focus on design, documentation, etc in working code (you ain’t gonna update it)

Coding sessions

• Pair Programming

• One Task at a time / Continuous Integration

• Integration Machine

• Test Everything that could possibly break

• AUTOMATED, Test Driven Development – Unit, Integration, System

More coding

• Collective Code Ownership

• Coding Standard

• Simple Design

• Refactoring

Code Standards

Indentation

Capitalization

Hungarian Notation

(Variable Names)

Curly-Brace Placement

Function Names

Problems with frequent release

• Regression Testing

Test Driven Development

• Objects and Functions have unwritten, contracted behavior

• Mis-understanding about expected behavior causes integration defects

• Automated tests establish and evaluate expected behavior

More TDD

• Test-First Development (see handout)

• Maintenance programming: Find a defect, write a test for it, fix it, make sure it passes the test

• After the fix, automatically regression test the entire system

The XP Life-Style

• Sustainable PaceRarely work 1 week of mild overtime

• Minimal CodingSimplest solution

• Least number of interfaces, modules, classes, functions

Do not "design for extensibility"

• RefactoringGet Rid of Duplicate Code

“Steering”

• Requirements & Priorities Change

• Estimates change – Truth is good

• Steer the iteration/steer the release by managing velocity, stories, and bugs

When do you release?

• Customer-derived acceptance test

• No QA Department! No V&V!

• Iterate until the customer is happy or the money runs out. (Shippable at any time; always deliver business value.)

No Testers?

• 3. Cease dependence on mass inspection

Eliminate the need for mass inspection as the way of life to achieve quality by building quality into the product in the first place. Require statistical evidence of built in quality in both manufacturing and purchasing functions.

- Dr. Deming’s 3rd Point of TQM

• Note that this requires massive, constant peer review.

(Pair Design, Pair Programming, Pair Test Script Writing …)

XP Values

• Simplicity, Communication, Courage, Feedback

• You ain’t gonna need it

• Simplest thing that could possibly work

Tailoring XP

• Few people do ‘book’ XP

• Use what works for you

• Apply context-driven principles

• No Testers?

Cons

Probably best for small-to-medium projects

Involves change and investment (time) in learning new methods of testing

Culture Problems (“We don’t need no silly pair programming”)

May have problems with shrink-wrapped development

Conclusions

• XP is a collection of mutually supportive practices that optimize the shared mental model and keeps developers working on code.

Discussion

References

• http://www.xprogramming.com

• Extreme Programming Installed

• Extreme Programming Explained

• Planning Extreme Programming

• Agile Project Management