XP: Hackers or Heroes

1
XP Hackers or Heroes?

• Chris Collins
• Software Engineer

2
Background

• Education
• MS Computer Science/Software Engineering, UWF,
  Aug. 1999
• BS Computer Science, UWF Dec. 1994
• Experience
• 14 years in software development industry
• 10 years Object-Oriented Development
• 1.5 years eXtreme Programming
• Teaching
• Graduate Course Object-Oriented Design, UWF,
  1999
• Undergraduate Course Introduction to Java, NC
  State, 2001

3

• "XP is the most important movement in our field
  today. I predict that it will be as essential to
  the present generation as the SEI and its
  Capability Maturity Model were to the last. Tom
  DeMarco

4
Objective

• Explain what XP is
• Relate my experience with XP

5
XP Values

• Communication
• Simplicity
• Feedback
• Courage

6
XP Practices

• The Planning Game
• Testing
• Pair Programming
• Refactoring
• Simple Design
• Collective Code Ownership

• Continuous Integration
• On-site Customer
• Small Releases
• 40-hour week
• Coding Standards
• Metaphor

7
Whats eXtreme?

• code reviews pair programming
• testing 100 unit tests
• design continuous refactoring
• integration daily or more often
• short iterations 1 - 3 weeks
• customer involvement they drive

8
Planning Game

• Stories are requirements
• Plan releases
• Plan iterations
• Dont waste time on your plan it will change
• Customer
• chooses scope
• sets priorities
• Developers
• estimate time required to implement requirements
• schedule within a release

9

• How do you know your code works?

10
XP Testing

• Developers
• write unit tests first, run them compulsively
• keep them running at 100 all the time
• Customers/Testers
• write acceptance tests for each requirement or
  feature
• decide which tests have to pass before release
• Test Automation
• Unit Tests xUnit
• Acceptance Tests Acceptance Testing Framework
• Run all tests with every build

11
(No Transcript)
12
(No Transcript)
13

• What if your guru gets crushed by a bus?

14
Pair Programming

• All production code
• written with two people sitting at one machine
• pass the keyboard and mouse back and forth
• Everyone knows a little about the whole system

15

• Have you ever worked on a system where there was
  some code that everyone was afraid to touch?

16
Refactoring

• Goal
• Improve code without changing functionality
• Reverses code entropy
• When
• Before adding a feature
• After adding a feature

17
Simple Design

• At all times, the system has
• simplest design that runs all test cases
• no code duplication
• clear statement of every intention important to
  the programmers
• no extra classes or methods
• Constantly evolved through refactoring
• Perfect ideas do not germinate, they evolve.
  Tom DeMarco

18
Collective Code Ownership

• Every team member must and can change any code at
  any time to make it better
• Tests verify you havent broken anything
• Collective ownership ltgt no ownership

19
Continuous Integration

• Build and test the entire system several times a
  day
• Unit tests must run at 100 before integration
• Unit tests must run at 100 after integration
• Single integration machine

20
On-Site Customer

• Provide immediate feedback
• Answer developer questions in a timely manner
• Makes all business decisions
• Must speak with one voice

21
Small Releases

• Feedback from real users keeps you on track
• Release early and often to get that feedback
• Simple design, short iterations make this
  possible
• Customer decides when to release, based on
  business value

22
Coding Standards

• Agree on a standard as a team, then stick to it.
• The goal is clear communication, not an
  exhaustive list of rules
• Eliminates trivial arguments
• Increases speed
• Easier to understand
• Easier to refactor

23
Metaphor

• Consistent, understood story about how the
  system works (e.g. C3 assembly line for
  payroll)
• Validate the metaphor quickly with a concrete
  design
• Often 5-20 CRC level concepts

24
40 Hour Week

• Keeps people sharp and creative
• Helps eliminate fatigue
• Improves morale
• 40 isnt a critical number, the principle is what
  matters
• OT is for short sprints

25
A Day In The Life

• Stand up meeting
• Identify tasks
• Pair up
• Load latest stuff

• Test first, code second
• If it works, integrate it
• Do the tests work?
• Release
• Next task?

26
Stand-up Meeting
27
Design is Crucial we do it daily
28
I Heard It Through The Pairvine
29
Papers On Agile Development

• XP Distilled by Chris Collins and Roy Miller
• http//www106.ibm.com/developerworks/java/library/
  j-xp/
• The New Methodology by Martin Fowler
• http//martinfowler.com/articles/newMethodology.ht
  ml
• Variations on a Theme of XP by Martin Fowler
• http//martinfowler.com/articles/xpVariation.html
• Manifesto for Agile Software Development
• http//agilealliance.org/
• The Costs and Benefits of Pair Programming by
  Alistair Cockburn and Laurie Williams
• http//members.aol.com/humansandt/papers/pairprogr
  ammingcostbene/pairprogrammingcostbene.htm
• Just-in-time Methodology Construction by Alistair
  Cockburn
• http//members.aol.com/humansandt/papers/jitmethy/
  jitmethy.htm
• Adaptation XP Style By Chris Collins and Roy
  Miller
• http//www.xp2001.org/xp2001/conference/papers/Cha
  pter13-Collinsalii.pdf

30
More Information

• Software
• xUnit testing frameworks
• http//www.xprogramming.com/software.htm
• Conferences
• eXtreme Programming and Agile Processes in
  Software Engineering www.xp2002.org
• XP Agile Universe www.xpuniverse.com
• Books
• eXtreme Programming Explained, Kent Beck
• eXtreme Programming Installed, Ron Jeffries, Chet
  Hendrickson, Ann Anderson
• eXtreme Programming Applied, Ken Auer and Roy
  Miller
• Planning eXtreme Programming, Kent Beck and
  Martin Fowler

31
Agile Software Links

• http//www.agilealliance.org
• http//www.c2.com/cgi/wiki?ExtremeProgrammingRoadm
  ap
• www.xprogramming.com
• http//crystalmethodologies.org/
• www.rolemodelsoft.com
• www.objectmentor.com
• www.martinfowler.com
• http//members.aol.com/acockburn/index.html
• http//www.pragmaticprogrammer.com/