Sprint 1, 2, …
Muddy cards evaluation
Annika Silvervarg
• The most important thing should be how to work with
design and development the project, I developed
system in many other courses
• The grade should depend on both the project work
and individual report, not only the report
• More clear information on what is mandatory
• Slides on homepgae before lecture
• Nice guest lecture (should be in English)
Sprint (0,) 1, 2, …
Customer
Developer
Interaction designer
Create product backlog, i.e.
write user stories
Planning game
Planning game
Planning game
Write accceptance test
Estimate tasks
(Help write acceptance test)
Available for clarifying
questions from developers
Signup for tasks and
implement stores
Design for current and next
sprint
Available for
workshops/evaluations
related to Interaction
designers work
Use XP practices to guide
implementation work
Plan usability testing (during
and) at the end of the sprint
Evaluate acceptance tests
at sprint end
Perform demo/acceptance
tests
Perform usability testing
Planning
• XP planning addresses two key questions in software
development:
– predicting what will be accomplished by the due date
– determining what to do next
• The emphasis is on steering the project rather than on
exact prediction of what will be needed and how long it
will take
• There are two key planning steps in XP, addressing
these two questions:
– Release planning
– Iteration planning
Release planning
Release Planning
• Customer presents the desired features to the
programmers as user stories
• Programmers estimate their difficulty
• Customer lays out a plan for the project
• Initial release plans are necessarily imprecise.
However, even the first release plan is accurate
enough for decision making and XP teams revise the
release plan regularly
www.extremeprogramming.org
1
Release planning –
Step 1: Writing user stories
Release planning
•
Customers write user stories
– Each story represents a desired feature and
all stories represent the specification of the system
– About three sentences of text in the customers terminology
•
Provide enough detail to make a reasonably estimate of how
long the story will take to implement
– Stories should be assigned business value: essential,
highly valuable or good idea (or a more fine grained scale,
eg. 1 to 10)
– Developers can suggest stories but the customer has
always final say
– Stories can allways be added, changed or deleted
User story template
• Title (one line describing the story)
• As a [role]
I want [user need]
So that/because [resulting ability] OR
• As a [role]
I can [do/view something]
A good story – INVEST
•
•
•
•
•
Independent, of other stories
Negotiable, not a contract
Valuable, to customer or end user
Estimable, enough information and reasonable scope
Small, coded and tested within half a day to two
weeks
• Testable, clear definition of ”done”
Release planning –
Step 2: Time esitmation
User story examples
•
Developers estimate how long the stories might take
to implement
– Each story will get a 1, 2 or 3 days estimate in ideal
development time
– Longer than 3 days means that the customer need to break
the story down further and less than 1 day that it is at too
detailed a level, combine some stories
– Stories should be assigned technical risk: low, medium,
high
2
Release planning –
Step 3: Prioritising stories
Estimating user stories
• Intuitive time estimates – how long it would take if you
programmed all days without interruptions, compare
the different stories for difficulty
• Spike solution – experiment to get an idea of how a
problem can be solved
• Estimate by comparison – compare a story with the
previously implemented stories
•
Together developers and customers move the cards
around on a large table to create a set of stories to
be implemented as the first/next release
– A useable, testable system that makes good business
sense delivered early is desired
– You may plan by time or by scope
•
•
Iteration planning
either how many stories can be implemented before a
given date (time), or
how long a set of stories will take to finish (scope)
Iteration planning
• A practice whereby the team is given direction every
couple of weeks
• During Iteration planning, the Customer presents the
features desired for the next iteration
• The programmers break them down into tasks, and
estimate their cost (at a finer level of detail than in
Release Planning)
• Based on the amount of work accomplished in the
previous iteration, the team signs up for what will be
undertaken in the current iteration
Iteration planning –
Step 1: Project velocity and scope
• Project velocity is based on previous iteration
– Number of completed stories/tasks/ideal hours divided by
actual hours
• Customer choose stories from release plan
• Failed acceptance tests to be fixed are also selected
Project velocity
• With six programmers and two-week iterations, a total
of 60 programmer-days (6 programmers x10 days) are
available
• With an initial velocity set to 1/3, a good start would be
to plan 20 ideal days worth of work in the iteration
• We recomend initial velocity at 0.5 and the time unit is
hours, this gives:
0.5 x 15 hours x 2 weeks x 6 devs = 90 hours of for
each iteration (60 hour for 4 developers)
3
Iteration planning –
Step 2: Creating tasks
• The user stories and failed tests are broken down into
the programming tasks that will support them by the
developers
– Tasks are written down on index cards like user stories
– While user stories are in the customer's language, tasks are
in the developer's language
– Duplicate tasks can be removed
– Each story has a corresponding task card for writing an
acceptance test together with the customer
Iteration planning –
Step 3: Time estimation
• Developers sign up to do the tasks and then estimate
how long their own tasks will take to complete*
– Each task should be estimated as 1, 2, or 3 ideal
programming hours** in duration
– Tasks which are shorter than 1 hour can be grouped
together and tasks which are longer than 3 hours should be
broken down farther
* or estimates are made by the team and tasks divided
at the end of the session, or put in a stack where
developers choose tasks one at a time
** or points
Planning poker
Planning poker
• A task is presented and briefly discussed (max 2 min)
• Each participant chooses from his own deck the
numbered card that represents his estimate
• All estimates are kept private until each participant has
chosen a card
• All estimates are revealed
• If estimates differ, the high and low estimators explain
their estimates
• The process is repeated until estimates are similar
Iteration planning –
Step 4: Prioritising
• Total up the time estimates in ideal programming
hours of the tasks, this must not exceed the project
velocity from the previous iteration
– If the iteration has too much then the customer must choose
user stories to be put off until a later iteration (snow
ploughing)
– If estimates are shown to be wrong during development
work, ask the customer to adjust the scope of the iteration
The first iteration
•
•
•
•
Choose several small tasks to lay a basic architecture
Do as much of the end-to-end application as possible
Helps gather data for future iterations
Choose velocity 0 and ask the customer to choose
new stories during the process, or choose an
arbitrary velocity, e.g. 0.5
• Start with the most important/highest risk task first
• Write down how your estimates were
4
Planning game
workflow
Development
• A picture says
more than a
thousand words?!
XP practices – Work flow
Pair programming
•
•
•
•
•
•
Choose task (Planning game)
Pair up (Pair programming)
(Write unit test) (Test-driven development)
Code (Code and Design Simply, Coding Standards)
Ask user for clarification (On-site customer)
Clean up (Refactor Mercilessly, Collective code
ownership)
• Check in test and code (Continuous integration,
Collective code ownership)
• Go home after 8 hours (Sustainable pace)
Practice – Pair Programming
• Goal: spread knowledge, experience and ideas
• Pairs work together on (small) tasks
• Driver focus on details of the task,
Navigator focus on project as whole
Practice – Test-driven Development
• Goal: prove that the code works as it should
• Acceptance test, write a test together with the
customer for each requirement
• Unit tests, write a test that fails, write code, check that
the test is passed, refactor, automate test
5
Testing
• Defects are expensive, but eliminating defects are
also expensive
– The sooner a defect is found the cheaper to fix it
• Acceptance tests test the functionality of the whole
system (customer)
• Unit tests test the components (developers)
• Once the test runs, the team keeps it running correctly
thereafter. This means that the system only improves,
always notching forward, never backsliding
Acceptance test template
• Scenario 1: Title
• Narrative:
Given [context] (And [some more context]...)
When [event]
Then [outcome] (And [another outcome]...)
Acceptance test example cont
• Acceptance test 2 – Over card limit
• Given a VISA card with correct card id number,
expiration date and purchase amount over card limit
When the user pays
Then payment fails and user receives error message
stating that the user is over the card limit
Acceptance test
• Acceptance tests are created from user stories
• During an iteration the user stories selected will be
translated into acceptance tests by the customer
• A story can have one or many acceptance tests, each
acceptance test represents some expected result from
the system
• Customers are responsible for verifying the
correctness of the acceptance tests and decide which
failed tests are of highest priority to fix in the next
iteration
Acceptance test examples cont
• User story – Payment
• The customer can pay by credit card
• Acceptance test 1 – Payment everything ok
• Given a VISA card with correct card id number, correct
expiration date and purchase amount under card limit,
When the user pays
Then payment goes through and user receives
confirmation on purchase
Acceptance test examples
User story
Criteria for acceptance test
6
•
•
•
•
Automating acceptance tests
Unit tests
Define input and expected output
Write functional test as programs
Have a scripting language simulate GUI commands
Have an input recorder and ask the customer use it to
define a test
• First you should create or download a unit test
framework to be able to create automated unit tests
suites (http://www.xprogramming.com/software.htm)
• Second you should test all classes in the system
(Trivial getter and setter methods are usually omitted)
• And last you should try to create your tests first, before
the code
• Unit tests are released into the code repository along
with the code they test
• Automate tests incrementally as needed
• Can be tricky for highly interactive GUI systems
Bug tests
• When a bug is found tests are created to guard
against it coming back
• A bug in production requires an acceptance test be
written to guard against it
• Given a failed acceptance test, developers can create
unit tests to show the defect from a more source code
specific point of view
• When the unit tests run at 100% then the failing
acceptance test can be run again to validate the bug is
fixed
You Aren’t Gonna Need It
• Do today’s work today and tomorrow's work tomorrow,
do not guess ahead
• Do not add flexibility if not needed, makes the code
more complex
• The customer/user identifies what needed
Code and Design Simply
• Goal: code that is easy to change
• Do the Simplest Thing That Could Possibly Work
– Solve the current problem
– Implement it simply
• Fewest possible classes and methods
(You Aren’t Gonna Need It)
– Code should pass all tests and nothing more
– Clean up
• No duplicate code (Once and Only Once)
Once and Only Once
• Eliminate repetition, simplify code by removing
complexity
• Refactor!
• Process
– Write code to solve problem
– When you write similar code refactor to remove duplication
– Next time you write similar code generalise to cover all
cases you will encounter
7
Coding Standards
• Goal: communicate ideas clearly through code
• Start with existing style guides and naming
conventions
• Conventions that evolves with the project
• All code should look the same – ideally it should not
be possible to determine who coded what based on
the code itself
On-Site Customer
• Goal: handle business concerns accurately and
directly
• Customer set project’s goal and schedule
• Gives quick and continuous feedback to the
development team
• If impossible to have on-site a proxy may be used
Refactoring
• Goal: optimal code design
• Changing how the system does something but not
what is done
• Improves the quality of the system in some way
• Do it regularly
Collective Ownership
• Goal: spread responsibility to whole team
• The idea that all developers own all of the code
• Any developer can change any code if needed to
complete a task
• Enables refactoring
Continuous Integration
• Goal: reduce impact of adding new features
• Merge tasks and tests to whole as soon as they are
completed
• Code is not worked on without being integrated for
more than a day
Sustainable pace
•
•
•
•
Goal: go home tired, but not exhausted
The work week should be limited to 40 hours
Time is fixed, adjust the scope if necessary
Regular overtime is a symptom of a problem and not a
long term solution
8
Perform Acceptance test (demo)
Acceptance test
• Acceptance tests are created from user stories
• During an iteration the user stories selected will be
translated into acceptance tests by the customer
• A story can have one or many acceptance tests, each
acceptance test represents some expected result from
the system
• Customers are responsible for verifying the
correctness of the acceptance tests and decide
which failed tests are of highest priority to fix in
the next iteration
Other types of testing
Release
• User interface testing – ensure all components behave
as expected
• Usability testing – ensure the application and functions
can be easily used (more next lecture)
• Performance testing – test performance during various
workloads
Small Releases
• Goal: return customer’s investment often
• Small in terms of functionality
• Less functionality means releases happen more
frequently
• Frequent opportunities for evaluation and feed-back
• Reduce chance of overall project slippage
Interaction design
• (Help Customer write user stories during planning
game)
• (Help Customer write acceptance tests)
• (Interviews, Observations, Create personas,…)
• LoFi prototype
– Continuous testing with customers/users
• Do usability testing with end users
9
Workspace
Workspace
Workspace
10