eXtreme Programming XP is not hacking Whole Team · eXtreme Programming ¥Introduced by Ward Cunningham, Kent Beck, and Ron Jeffries. ¥XP is what it says, an extreme way of developing

Agile Development Processes 1

eXtreme Programming

• Introduced by Ward Cunningham, Kent Beck,

and Ron Jeffries.

• XP is what it says, an extreme way of developing

software.

– If a practice is good, then do it all the time.

– If a practice causes problems with project agility, then don’t

do it.


XP is not hacking

• When using XP you write as little documentation aspossible.

• This does not mean that XP is simple hacking. Justthat XP has other means for achieving quality.

• “A sane and disciplined way to quickly succeed – ontypical small projects – by focusing on code andtests, while avoiding most other documentationoverhead”

– Craig Larman


XP practices

• Whole Team (Customer Team Member, on-site customer)

• Small releases (Short cycles)

• Continuous Integration

• Test-Driven development (Testing)

• Customer tests (Acceptance Tests, Testing)

• Pair Programming

• Collective Code Ownership

• Coding standards

• Sustainable Pace (40-hour week)

• The Planning Game

• Simple Design

• Design Improvement (Refactoring)

• Metaphor


Whole Team

A.K.A: Customer Team Member, on-site customer

• Everybody involved in the project works together asONE team.

• Everybody on the team works in the same room.(Open Workspace)

• One member of this team is the customer, or thecustomer representative.

Agile Development Processes 5 Agile Development Processes 6

Pair Programming

• All program code is written by two programmers

working together; a programming pair.

• Working in this manner has a number of positive

effects:

– Better code Quality

– Fun way of working

– Information spreading

– Skills spreading

– …


Test-Driven development

A.K.A: Unit tests, Testing

• No single line of code is ever written, without first writing a testthat tests it.

• All tests are written in a test framework like JUnit so theybecome fully automated.


Customer tests

A.K.A: Acceptance Tests, Testing

• The customer (or the one representing the customer)

writes tests that verifies that the program fulfills

his/her needs


Continuous Integration

• Daily build

– A working new version of the complete software is released

internally every night.

• Continuous build

– A new version of the complete software is build as soon as

some functionality is added, removed or modified.


Small releases

A.K.A: Short cycles

• The software is frequently released and deployed to thecustomer.

• The time for each release is planned ahead and are neverallowed to slip. The functionality delivered with the release canhowever be changed right up to the end.

• A typical XP project has a new release every 3 months.

• Each release is then divided into 1-2 week iterations.


Collective Code Ownership

• All programmers are responsible for all code.

• You can change any code you like, and the minute

you check in your code somebody else can change it.

• You should not take pride in and responsibility for the

quality of the code you written yourself but rather for

the complete program.


Coding standards

• In order to have a code base that is readable and

understandable by everybody the team should use

the same coding style.


Sustainable Pace

A.K.A: 40-hour week

• Work pace should be constant throughout the project

and at such a level that people do not drain their

energy reserves.

• Overtime is not allowed two weeks in a row.


Simple design

• Never have a more complex design than is needed

for the current state of the implementation.

• Make design decisions when you have to, not up

front.


Design Improvement

A.K.A: Refactoring

• Always try to find ways of improving the design

• Since design is not made up front it needs constant

attention in order to not end up with a program

looking like a snake pit.

• Strive for minimal, simple, comprehensive code.


Metaphor

• Try to find one or a few metaphors for your program.

• The metaphors should aid in communicating design

decisions and intends.

• The most well known software metaphor is the

desktop metaphor.


The Planning Game


Project organization


The Planning Game

• Planning is done in order to determine what to do,

when to do it, and by whom.

• The planning game gives a list of tasks that is to be

done in the coming iteration.


Meeting with the customer

• Help the customer formulate what he wants the

program to do.

• Typically the customer and one or two developers


User stories

“The story is the unit of functionality in an XP project.

Progress is demonstrated by delivering tested,

integrated code that implements a story. A story

should be understandable to customers and

developers, testable, valuable to the customer, and

small enough so that the programmers can build half

a dozen in an iteration.”


Prioritizing user stories

• Have the client order the user stories roughly in order

of importance.

• Assign to e.g. three categorize:

– “essential, to be done first”

– “needed, but not top priority”

– “only if there is time”


Iteration Planning meeting

• The customer or the customers representative

presents and explains the (top priority) user stories.

• Discuss the user stories and resolve uncertainties.

– If the customer is not present take notes on uncertainties

and categorize them on whether they affect planning or

implementation.


Estimating user stories work effort

• Estimate relative work effort of user stories.

• Estimate each story’s work effort in IT (ideal time).

• Use 1 IT = 1 hour.

• Never assume an order of implementation. Estimate

the time for each story in isolation.


Determine available time

• Determine available units of time in iteration

• Use yesterdays weather

– Assume you will implement as many IT:s worth of user stories asyou did last week.

• Count only finished stories.

• Take known differences to last week into account.


Choose stories for current iteration

• Given the estimated user stories and the available

time, the customer choose the stories for the current

iteration.


Break stories into tasks

• Break the chosen User stories into Programming Tasks

• A Programming Task is a task that needs to be done in order to

implement a story. A task does not need to be understandable

to the customer but is there to help the programmers in planning

their work. E.g:

– Update database

– Construct GUI

– Extend the Engine package with needed functionality

• Avoid making unnecessary design decisions when formulating

tasks.


User Stories and

Programming Tasks

• “CRUD contact entry”

• In address book software, the basic storage unit is an

individual contact entry. As a bare minimum, the

software must allow the user to:

– Create or add new entries

– Read, retrieve or view existing entries

– Update or edit existing entries

– Delete existing entriesProgramming Tasks

User Story


Programmer velocity

• The amount of ideal time that each programmer can

commit to work.

• Equals the amount of time used on finished tasks last

iteration (yesterdays weather).

– Modify if circumstances differs.

• Should be prepared by tracker prior to meeting.


Assign tasks to programmers

• All programmers that are interested in doing a task estimatehow long it will take them.

• The one with the lowest estimate “wins the bid” and gets to dothe task.

• No programmer can sign up for more time than his velocity.

• Update the estimated time for each US with the sum of its tasks.


If the time don’t match

• If not all tasks fit in the iteration or if there is extra

time have the customer remove or add user stories.


Project organization


Preparation for

Iteration start-up meeting

OutcomeTaskParticipants#

User Stories (US)Interview the customer and formulateuser stories (US) together with the

customer based on his wants and needs.

Customer1

Ordered USOrder stories in order of importanceCustomer2


Coducting

Iteration start-up meeting

Estimated USEstimate US work effortEntire Team3

Availble timeDetermine available units of time in

iteration

Entire Team4

Set of US for current

interation

Choose US for this iterationCustomer5

Programming tasksBreak the US for this into programming

tasks (PT)

Entire Team6

Resolve uncertainties in USCustomer2

Assigned and

estimated PT. Updated

US estimations

Assign PT to programmers by biding on

the units of time needed

Entire Team7

OutcomeTaskParticipants#

Questions for

Customer

Determine uncertainties in USEntire Team1

If not all US fits or if there is extra time

go to 5 otherwise finish meeting

8


Technical tasks

• On all projects there are purely technical tasks thatthe customer don’t care about that needs to done.

• A Technical task can be:– Upgrading development tools

– Large Refactorings

– Evaluating frameworks

– …

• Use a story card for documenting tasks that need tobe done.

Documents

eXtreme Programming XP is not hacking Whole Team · eXtreme Programming ¥Introduced by Ward Cunningham, Kent Beck, and Ron Jeffries. ¥XP is what it says, an extreme way of developing