extreme 4

8/8/2019 Extreme 4

1/35

Extreme ProgrammingTeam Members Aaron Zedonis Cesar Garduno Jian Song Jose Cortes Ko-Wei Pan

Date: May 29, 2001Class: Programming

MethodsInstructor: Dan Klawitter

8/8/2019 Extreme 4

2/35

PlanningUser stories; Release planning; small releases; Business Analysis; Project Velocity; Iterations;Iteration planning; Move people around; Stand-

up meeting day; Fix XP when it breaks .

DesigningSimplicity; System metaphor.

Use CRC cards for design sessions.Spike solutions to reduce risk. No functionality added early.

Refactor.

CodingCustomer is always available; Standards.Code the unit test first; Pair programmed;

Integrates often; Collective code ownership.Optimization till last; No overtime.

TestingAll code must have and pass unit tests before it

can be released; When a bug is found tests arecreated; Acceptance tests are run often and the

score is published.

Copyright 1999 J. Donovan Wells all rights reserved

Rules and Practices of Extreme

Programming

8/8/2019 Extreme 4

3/35

Overview

Extreme programming (Jose)User Stories (Cesar)Business Analysis in XP (Pan)CRC Cards (Aaron)

Extreme programmingimplementation example (Jian)

8/8/2019 Extreme 4

4/35

Extreme Programming Overview

8/8/2019 Extreme 4

5/35

One iteration of ExtremeProgramming

8/8/2019 Extreme 4

6/35

8/8/2019 Extreme 4

7/35

Programmers activities and work Style

8/8/2019 Extreme 4

8/35

User Stories

8/8/2019 Extreme 4

9/35

A user story is a short description of whatthe business or customer wants the softwareto do, written by the customer in thecustomer terminology without techno-syntax.

What are User Stories?

They are in the format of about three sentences

typically written on 4x6cards.

8/8/2019 Extreme 4

10/35

PurposeUser Stories are used to create time estimates for the release planningmeeting.They are also used instead of a large requirements document.User Stories also drive the creation of the acceptance tests.

8/8/2019 Extreme 4

11/35

Example" Tell me the story and write down the name of the story and a paragraph or two. "

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

Tomorrow or 'maana'?

L icense Enforcement

When run for the first time, JeraWorks puts up a license dialog, and will not proceed untilthe 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.

8/8/2019 Extreme 4

12/35

User Stories & t h e PlanningGame

The basic goal is to create a release planThe basic pieces are the User Stories (cards)The players are the customers and developersThe 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 thosereleases.

8/8/2019 Extreme 4

13/35

User Stories & t h e PlanningGame (cont.)

Once the release plan is set, the selected stories arethen translated into individual programming

tasks that will be implemented during the iterationto 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.

8/8/2019 Extreme 4

14/35

8/8/2019 Extreme 4

15/35

Requirements SpecificationsVS User Stories

level of detail User stories are short and to the point

User stories should only provide enough detail to makea reasonably low risk estimate of how long the storywill take to implement.

focus on user needs You should try to avoid details of specific technology,

data base layout, and algorithms. You should try tokeep stories focused on user needs and benefits asopposed to specifying GUI layouts.

8/8/2019 Extreme 4

16/35

Business Analysis inExtreme Programming

8/8/2019 Extreme 4

17/35


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 makeeffective choices.

8/8/2019 Extreme 4

18/35


Both customers and programmers learn and prosper during thecycle of life.

Business analysts are added when there is a wide range of customers or the customers have difficulties in makingdecisions.

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 others work Improves mutual communication, accuracy and consistency of the

product

8/8/2019 Extreme 4

19/35


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

8/8/2019 Extreme 4

20/35


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

8/8/2019 Extreme 4

21/35

CRC Cards

8/8/2019 Extreme 4

22/35

CRC CardsClass, Responsibilities, and CollaborationCards

A simple way to specify a designFirst introduced by Kent Beck and WardCunningham at OOPSLA 89

Not specifically part of ExtremeProgrammingbut works well with the XP paradigm

8/8/2019 Extreme 4

23/35

What is a CRC Card?On the top of the card isthe Cl ass

The list on the left are the Responsibi l itiesThe list on the right arethe C oll aborating classesA simplespecification/design of aclass, and what it does

8/8/2019 Extreme 4

24/35

How are they used?

Create cards for the obvious classesTalk through a user story, describing howthe classes interact with each other Move cards (exploring different designs)Add/Delete cards as needed

8/8/2019 Extreme 4

25/35

Documenting Your DesignYou dont need to keep the cards, nor doyou need to produce any extra design

documents.Well written and well tested code is thedocumentation of the design.

Why waste time writing and updating thedocumentation? Or why live with out-of-date documentation?

8/8/2019 Extreme 4

26/35

8/8/2019 Extreme 4

27/35

XP Implementation Example

8/8/2019 Extreme 4

28/35

XP Programming example:

This is a very primitive example of using XP programming methodologyto revive a project.

Project Structure Project: Customized an existing Labor Collection System. Primary User: H uman 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 Databaseobjects;

User contact in team: project manager.

8/8/2019 Extreme 4

29/35

Original project structurediagram. Any communication among

users and programmers goesthrough program manager.

Code ownership: monopoly.

Programmanager

Prog1

Pro 2Senior Pro.

DBA

User

P1

P3

P2

P1, P2, P3R and Data

R

Data

8/8/2019 Extreme 4

30/35

Problems encountered: In the absence of any member of team, work slows down or stops. Impossible to maintain other programmers 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;

8/8/2019 Extreme 4

31/35

8/8/2019 Extreme 4

32/35

Implement XP with limited available human resources torevive the project:

First work in pair and take over the ownership of code left by the senior programmer using one computer in each others 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 eachimplementation. Users are consistently available to each programmer onfeedback about changes, requirements implementations.

User stories are used to describe requirements, and test theimplementation.

All above had made development, modification, unit testing and

integration testing much easier and faster.

8/8/2019 Extreme 4

33/35

Prog1

Pro 2

ser

P1, P2, P3

and

ata

Pro

ead

New project diagram after following X P

programming method. irect communication among

users and programmers. Nomiddle man;

irect access to any resources

of project. No middle barrier; Collective ownership of

project .

P roject status: In production with parallel

testing three months after thechange of project structure and

programming method.

8/8/2019 Extreme 4

34/35

SummaryW e h ave reviewed as we said:

Extreme programming (Jose)User Stories (Cesar)Business Analysis in XP (Pan)CRC Cards (Aaron)

Extreme programming implementationexample (Jian)

8/8/2019 Extreme 4

35/35

Referenceshttp://www.extremeprogramming.org/Wiki Wiki. The Portland Pattern repositoryhttp://c2.com/cgi/wiki?UserStoryhttp://xprogramming.com/

extreme 4

Documents