extreme programming xp is not hacking whole team · extreme programming ¥introduced by ward...
TRANSCRIPT
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.
Agile Development Processes 2
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
Agile Development Processes 3
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
Agile Development Processes 4
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
– …
Agile Development Processes 7 Agile Development Processes 8
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.
Agile Development Processes 9
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
Agile Development Processes 10
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.
Agile Development Processes 11 Agile Development Processes 12
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.
Agile Development Processes 13
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.
Agile Development Processes 14
Coding standards
• In order to have a code base that is readable and
understandable by everybody the team should use
the same coding style.
Agile Development Processes 15
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.
Agile Development Processes 16
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.
Agile Development Processes 17
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.
Agile Development Processes 18
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.
Agile Development Processes 19
The Planning Game
Agile Development Processes 20
Project organization
Agile Development Processes 21
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.
Agile Development Processes 22
Meeting with the customer
• Help the customer formulate what he wants the
program to do.
• Typically the customer and one or two developers
Agile Development Processes 23
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.”
Agile Development Processes 24
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”
Agile Development Processes 25
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.
Agile Development Processes 26
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.
Agile Development Processes 27
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.
Agile Development Processes 28
Choose stories for current iteration
• Given the estimated user stories and the available
time, the customer choose the stories for the current
iteration.
Agile Development Processes 29
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.
Agile Development Processes 30
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
Agile Development Processes 31
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.
Agile Development Processes 32
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.
Agile Development Processes 33
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.
Agile Development Processes 34
Project organization
Agile Development Processes 35
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
Agile Development Processes 36
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
Agile Development Processes 37
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.