0% found this document useful (0 votes)
5 views

Extremprogramming 1

Uploaded by

ravikumark.it
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

Extremprogramming 1

Uploaded by

ravikumark.it
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Agile and XP

Development

Dan Fleck
2008

Coming up: What is Agile?


What is Agile?
» Software development practice aimed at:

» Individuals and interactions over processes and tools


» Working software over comprehensive documentation
» Customer collaboration over contract negotiation
» Responding to change over following a plan

That is, while there is value in the items on the right, we value the
items on the left more.
- Excerpt
Excerpt from
from The
The Agile
Agile Manifesto
Manifesto

Coming up: What is Agile?


What is Agile?
» A classification of methodologies that
adhere to the agile principles
» Developed at a conference in Utah in 2000
» Agile Manifesto (agilemanifesto.org)
documentation

Coming up: An Agile Process


An Agile Process
» Is driven by customer descriptions of what
is required (scenarios)
» Recognizes that plans are short-lived
» Develops software iteratively with a heavy
emphasis on construction activities
» Delivers multiple ‘software increments’
» Adapts as changes occur

Coming up: eXtreme Programming (XP)


eXtreme Programming
(XP)
» Predates Agile so extreme he
never smiles?!?
» XP was created by Kent Beck at
DaimlerChrysler in 1996
» Kent Beck attended the conference in Utah,
2000.
» Is probably the best-known and most
complete “agile-method”

Coming up: XP Fundamentals


XP Fundamentals
» Take the good things we do and turn them
up to 10!

 Simplicity
 Communication
 Feedback
 Courage

Coming up: XP Practices


XP Practices
» The Planning Game » Refactoring
» Small Releases » Continuous
» Metaphor Integration
» On-site Customer » Collective Ownership
» Simple Design » Coding Standards
» Pair Programming » Sustainable Pace
» Test-Driven
Development

Coming up: The Planning Game


The Planning Game
» Distinguish between business people’s decisions
and developer’s decisions
» Short iterations (1-2 weeks)
» Each iteration satisfies a number of user-stories
» Total time for user stories cannot exceed previous
iteration’s user story time
 Velocity is a measure of the number of stories finished
during an iteration.

Coming up: Planning Game


Planning Game
Split a Story Sort stories by
(Customer) value
(Customer)
“too big”

Write a Story Estimate a


story Declare velocity
(Customer) (Developer)
(Developer)

“don’t know how”


Choose scope
Spike a Story
(Customer)
(Developer)

Exploration Planning
Coming up: XP - User Stories
XP - User Stories
» Similar purpose as use cases
 Written by customers
 Estimated by developers
 Replaces large requirements documents
 Represents anything that is “progress” to the customer
 Examples:
» Students can purchase monthly parking passes online.
» Parking passes can be paid via credit cards.
» Parking passes can be paid via PayPal
» Professors can input student marks.
» Students can obtain their current seminar schedule. ・
Students can order official transcripts.

Coming up: The Whole Team


The Whole Team
» Communication is key!
 Developers, business analysts, QA, project
management, customers, etc… all work in one
room
 Maximizes collaboration

Coming up: Small Releases


Small Releases
» Systems released to production (or pre-
production) very frequently (2-3 months
maximum, 1 month is better!)
» Much easier to plan next month than the
next 6 months

Coming up: Continuous Integration


Continuous Integration
» The whole system is built and tested several
times a day
» Automated testing is required (see TDD
later)

Coming up: System Metaphor


System Metaphor
» Establishes common vocabulary for the
system
» Consistent naming of classes and methods
» Names should be easy to learn and relate to

Coming up: Example System Metaphor


Example System Metaphor
» Examples: Shared blackboard
 An
An Expert
Expert puts
puts aa Problem
Problem on on the
the Board.
Board.
 There
There are
are aa number
number of of Experts
Experts sitting
sitting around:
around: when
when anyone
anyone sees
sees aa
problem
problem they
they can
can solve
solve (or
(or know
know how
how toto break
break into
into easier
easier sub-problems),
sub-problems),
they
they do
do so.
so.
 There's
There's aa protocol
protocol that
that defines,
defines, "Who
"Who gets
gets the
the chalk
chalk next?"
next?" and
and "When
"When are
are
we
we done?"
done?"

» This metaphor suggests a few potential problems:


 experts
experts have
have different
different skills,
skills, and
and they
they may
may not
not necessarily
necessarily agree
agree on
on how
how to
to
solve
solve aa particular
particular problem.
problem.
 The
The chalkboard
chalkboard may
may become
become aa scarce
scarce resource.
resource.
 The
The most
most knowledgeable
knowledgeable person
person may
may find
find they're
they're doing
doing all
all the
the work.
work.
 We
We may
may have
have "experts"
"experts" who
who aren't
aren't as
as good
good as
as they
they think
think they
they are.
are.

Coming up: Sustainable Pace


Sustainable Pace
» Coding is a marathon, not a sprint.
» Team works 40 hours a week -
MAXIMUM!
» Tired people aren’t productive

Coming up: Pair Programming


Pair Programming
» All code is written in pairs
» One developer writes code while the other
thinks about the code
 Is the overall system going to work
 Are there better ways of doing this
 What test cases still don’t work
» Pairs switch roles frequently (every two
hours or so)

Coming up: Collective Ownership


Collective Ownership
» No individual owns any piece of the
software. All pieces may be worked on by
any team member

» Coding Standard - All team members must


abide by a coding standard

Coming up: Test Driven Development (TDD)


Test Driven Development (TDD)
» Write automated unit tests FIRST
» Tests must run and fail before code is written
» Code then written until unit tests pass
» Coding must STOP when unit tests pass (no extra
features/functions)
» No previously working unit tests can fail

Coming up: Refactoring


Refactoring
» All code is continuously reviewed and cleaned.
Working code is not enough -- must be clean!

» Simple Design - the simplest working design that


satisfies the task at hand is used. More complex
and general designs may become useful, but not
now so we don’t use them!

Coming up: XP Project People


XP Project People
» Customer
» Developers
» Project Manager
» Tracker
» Coach

Coming up: Tracker


Tracker
» Tracker » Coach
 Tracks release plan  Watches everything
 Tracks iteration plan  Responsible for the
 Tracks acceptance process (keep it
extreme!)
tests (passed/failed)
 Helps with anything
else needed… but stay
back to let the team be
self-reliant!

Coming up: When not to use XP


When not to use XP
» Customer requires a big specification
» Large teams > 100 -- no way! Approx 15 people
max.
» If your solution requires you to create complex
solutions for future problems (exponential cost
curve)
» When you can’t get feedback immediately (space
shuttle?)
» When you can’t get people physically close
together (same room)
Coming up: Summary
Summary
» eXtreme Programming is a set of practices that
conform to Agile principles
» Xp is one of many Agile methods: DSDM,
Crystal, FDD, SCRUM, and others…
» These processes are a logical next step from the
older “prescriptive” or “heavyweight” processes

Coming up: References


References
» These references were used to create these
slides:
 http://xp123.com/xplor/xp0004/
 http://www.objectmentor.com/omSolutions/agil
e_xp_differences.html
 Beck K., Extreme Programming Explained,
2000
 Pressman R., Software Engineering: A
Practitioner’s Approach, 6/e, 2005
Coming up: References

You might also like