Extreme Programming

• Team Members
– Aaron Zedonis
– Cesar Garduno
– Jian Song
– Jose Cortes
– Ko-Wei Pan

Date: May 29, 2001

Class: Programming
Methods
Instructor: Dan Klawitter
 Rules and Practices of Extreme
Programming
Planning
User stories; Release planning; small releases;
Business Analysis; Project Velocity; Iterations;
Iteration planning; Move people around; Stand-up
meeting day; Fix XP when it breaks.
Designing
Simplicity; System metaphor.
    Use CRC cards for design sessions.  
    Spike solutions to reduce risk.
    No functionality added early.
    Refactor.
Copyright 1999 J. Donovan Wells all rights reserved
Coding
Customer is always available; Standards.
    Code the unit test first; Pair programmed;
Integrates often; Collective code ownership.
Optimization till last; No overtime.
Testing
All code must have and pass unit tests before it
   can be released; When a bug is found tests are
created; Acceptance tests are run often and the
score is published.
 Overview

 Extreme programming (Jose)

 User Stories (Cesar)
 Business Analysis in XP (Pan)
 CRC Cards (Aaron)
 Extreme programming
implementation example (Jian)
Extreme Programming Overview

                                                               

                              
 One iteration of Extreme
Programming

                                                               

                              
 Development overview

                                                                

                               
Programmers activities and work
Style

                                                              

                                 
User Stories
 What are User Stories?
• A user story is a short description of what
the business or customer wants the software
to do, written by the customer in the
customer terminology without techno-
syntax.
They are in the format of
about three sentences
typically written on 4x6
cards.
 Purpose
• User Stories are used to create time estimates for the release planning
meeting.
• They are also used instead of a large requirements document.
• User Stories also drive the creation of the acceptance tests.
 Example
"Tell me the story and write down the name of the story and a paragraph or two."

License Enforcement

When run for the first time, JeraWorks puts up a license dialog, and will not proceed until
the user enters either:

• a valid non-time-limited (paid) license certificate or

• a valid time-limited (demo) license that has not yet expired.

A valid license is stored so the user doesn't have to re-enter it on subsequent runs.

License info is displayed on the splash screen.

When a demo license expires, the license dialog re-appears the next time JeraWorks is run.

I'll put on my "Development" hat tomorrow and estimate this.

Tomorrow or 'mañana'?
 User Stories & the Planning
Game
• The basic goal is to create a release plan
• The basic pieces are the User Stories (cards)
• The players are the customers and developers
• The Rules:
– Developers estimate how long the stories might take to
implement
– Business then decides which stories are going to be
implemented for each release and the dates for those
releases.
 User Stories & the Planning
Game (cont.)
• Once the release plan is set, the selected stories are
then translated into individual programming
tasks that will be implemented during the iteration
to complete the stories.
• Each story will get a 1, 2 or 3 week estimate in
"ideal development time".
• A typical XP project of six to 12 months calls for
between 50 and 100 user stories.
 Requirements Specifications
VS User Stories
• level of detail
– User stories are short and to the point
– User stories should only provide enough detail to make
a reasonably low risk estimate of how long the story
will take to implement.
• focus on user needs
– You should try to avoid details of specific technology,
data base layout, and algorithms. You should try to
keep stories focused on user needs and benefits as
opposed to specifying GUI layouts.
 Business Analysis in
Extreme Programming
 Business Analysis in
Extreme Programming

XP "circle of life":
• the customer decides which features have value,
• programmers estimate the cost of providing the features,
• the customer chooses the best combination of features
based on value and cost,
• programmers build the features, learning how to estimate
costs in the process,
• the customer learns how to define value and how to make
effective choices.
 Business Analysis in
Extreme Programming
• Both customers and programmers learn and prosper during the
“cycle of life”.

• Business analysts are added when there is a wide range of

customers or the customers have difficulties in making
decisions.

• Advantages of adding analysts:

– Both customers and programmers learn and understand more about
their own work
– Both customers and programmers learn and understand more about
each other’s work
– Improves mutual communication, accuracy and consistency of the
product
 Business Analysis in
Extreme Programming
• The problems with translation:
– The translation interferes with learning, in both directions
– Customers will not respect the programmers' work, or the estimates
– Customers will lose control and decrease satisfaction

• Solutions:
– Business analysts should work as aides to the customer, not as an
interface between customer and programmer
– Have regular meetings between analysts and customers
– The analysts should help the customers to write their stories instead of
translating for them
 Business Analysis in
Extreme Programming
– Help the customers decide the priorities instead of deciding for them

– Have all the customers understanding what they should know and make
them feel as much control over the project as possible

– Help customers define the acceptance tests

CRC Cards
 CRC Cards
• Class, Responsibilities, and Collaboration
Cards
• A simple way to specify a design
• First introduced by Kent Beck and Ward
Cunningham at OOPSLA ’89
• Not specifically part of Extreme
Programming
• …but works well with the XP paradigm
 What is a CRC Card?
• On the top of the card is
the Class
• The list on the left are the
Responsibilities
• The list on the right are
the Collaborating classes
• A simple
specification/design of a
class, and what it does
 How are they used?
• Create cards for the obvious classes
• Talk through a user story, describing how
the classes interact with each other
• Move cards (exploring different designs)
• Add/Delete cards as needed
 Documenting Your Design
• You don’t need to keep the cards, nor do
you need to produce any extra design
documents.
• Well written and well tested code is the
documentation of the design.
• Why waste time writing and updating the
documentation? Or why live with out-of-
date documentation?
 But what’s wrong with UML?
• Well… nothing
• Why invest the time drawing pictures of a
design, when in XP your design will change
via constant refactoring?
• CRC Cards can be a front-end for a heavier
process if your project requires that (or if
you just really like making the documents.)
XP Implementation Example
 XP Programming example:

This is a very primitive example of using XP programming methodology

to revive a project.

• Project Structure
– Project: Customized an existing Labor Collection System.
– Primary User: Human resource
– Project Team: Programer1, Programer2, Senior Programmer, DBA,
Project Manager.
– Project Manager owns: Project plan, project source code, project user
requirements.
– Prog1 owns Part P1; Prog2 owns Part P2; Senior Part P3; DBA Database
objects;
– User contact in team: project manager.
• Original project structure
diagram. User R
Program

– Any communication among

P1, P2, P3
R and Data manager

users and programmers goes

through program manager. P2
Senior Pro.
Pro 2

– Code ownership: monopoly. Prog1

P3

P1
DBA

Data
• Problems encountered:
– In the absence of any member of team, work slows down or stops.
– Impossible to maintain other programmer’s work;
– System testing and feedback takes long time;
– Programmers and users are in the dark about requirement interpretation
and implementation;
– Each part of system is owned by a team member;
– When one person is gone, it’s
difficult to back up the person’s
work. When more than one person P1, P2, P3
User R

left, the project is to die unless and R.

some critic changes are made to

project structure.

– Three months into project, three

P2
people left in two months. Project
Pro 2
looked like.
Prog1

P3

P1

Data
• Implement XP with limited available human resources to
revive the project:

– First work in pair and take over the ownership of code left by the senior
programmer using one computer in each other’s cubic.
– Started to work on each others code in pair. Promote a code standard.
Promote a collective ownership of project.
– Perform unit test, integration test, and user test frequently on each
implementation. Users are consistently available to each programmer on
feedback about changes, requirements implementations.
– User stories are used to describe requirements, and test the
implementation.
– All above had made development, modification, unit testing and
integration testing much easier and faster.
• New project diagram after
following XP
programming method.
P1, P2, P3
– Direct communication among R and Data
User
users and programmers. No
middle man;
– Direct access to any resources
of project. No middle barrier;
– Collective ownership of
project. Pro 2

Prog1

• Project status: Pro

Lead
– In production with parallel
testing three months after the
change of project structure and
programming method.
 Summary
We have reviewed as we said:
Extreme programming (Jose)
User Stories (Cesar)
Business Analysis in XP (Pan)
CRC Cards (Aaron)
Extreme programming implementation
example (Jian)
 References
• http://www.extremeprogramming.org/
• Wiki Wiki. The Portland Pattern repository
http://c2.com/cgi/wiki?UserStory
• http://xprogramming.com/