Customer Collaboration
Central Principles
• The customer is part of the team
• The customer plays key role in directing the
team
1
XP Collaboration with Customers
1.
2.
3.
4.
5.
6.
7.
2
Customers & Engineers- Collect user stories
Engineers- Identify tasks
Engineers- Estimate effort
Customers- Prioritize stories
Engineers- Plan work
Engineers- Communicate progress
Customers & Engineers- evaluate results
User Story
• Fits easily on 3x5 note card
• Can also be typed into spreadsheet…
• But harder to review with customers
• Name + short description
3
User Story: Example
Title: View eco-friendliness
Description: The e-commerce website users can click
on a product and view its eco-friendliness ratings.
4
User Story: Example
Title: Upload eco-friendliness data
Description: Trusted 3rd parties can upload an XML
document specifying eco-friendliness ratings for
products.
5
User Story: Principles
• Not written in stone
• Revision is acceptable and expected
• Fuzzy
• Further communication is usually needed
• Minimalist
• If you add stuff that the customer doesn’t want, then the system will
surely cost too much
• Backed up by acceptance tests
• To be discussed in a later lecture..
6
User Story: How to Collect
• Gathering user stories
•
•
•
•
•
Have a starting point in mind
Let the customer walk through the vision
“Chunk” the vision into user stories
Ask questions to clarify
Don’t invent stories; let customer “drive”
• Remind customer that they can add stories later
7
Identify Tasks
• Systematically break down each user story into pieces of work
• Can often be decomposed similar to architecture
• E.g., object, process, feature, process etc.
• E.g., “first we’ll implement this change to the system,
… then this change,
… then this change, etc.
8
Identify Tasks: Example
• Helpful to sketch an architecture
Watchdog XML docs
Shopping users
UI to upload watchdog data
E-commerce interface
PHP/Apache
Mysql
Linux
9
Databas
e
Identify Tasks
• User story: View eco-friendliness
• Set up a database to store product data / ratings
• Create web page to show a product’s data
• Create web page listing products, so user can click
10
Identify Tasks
• User story: Upload eco-friendliness data
• Set up a database to store product data / ratings
• Create a web page for uploading XML document
• Write code to read data into database
11
Effort Estimates
• Figure out effort of each task
• Estimates done in nebulous “unit” of your own calibration
• Typically based on experiences with similar work
• If needed, do a spike (an experimental implementation) to estimate
difficulty
• Take “bids” from team members for the lowest effort on each task
• Sum up task efforts to compute story effort
• Tweak the estimate as appropriate
12
Effort Estimates: “Unit”
• A unit - how much work you can finish in a week’s iteration
• To start with, a unit could be defined as how much an average
pair of programmers could accomplish in an “ideal“ day
• E.g., 8-person team has 4 pairs.
• Each pair can complete 5 “units” per week
• Team can do 20 “units” per week
13
Effort Estimates: Example
• User story: View eco-friendliness
• 1u: Set up a database to store product data / ratings
• 1u: Create web page to show a product’s data
• 1u: Create web page listing products, so user can click
3 units of effort
14
Identify Tasks
• User story: Upload eco-friendliness data
• 1u- Set up a database to store product data / ratings
• 0.5u?- Create a web page for uploading XML document**
• 1u- Write code to read data into database
2.5 units of effort
** Not sure? May call for a spike!!
15
Be Empirical
• When in doubt, do a spike
• What it is: a small program that explores / tests possibilities
• How to do it:
•
•
•
•
16
Identify one key to discover
Write a little code to test an idea
Tweak code until you get info you need
Throw code away, keep the knowledge
Effort Estimates: Be Conservative
• Conservative estimates based on each user story
• Don’t assume a certain ordering of user stories
• You will over-estimate effort
• Accurate effort estimates takes experience
17
Effort Estimates: Be Realistic
• Expected to work at a sustainable pace
• No heroes, no all-nighters, no super-human feats
• Either you’ll get the code done like a human being, or you don’t
18
Effort Estimates: Be Honest
• Engineers should give honest estimates customers can trust
• Engineers make estimates
• Customers make priorities
• XP Saying: “He who does the work sets the estimate.”
19
Effort Estimates: Customers Prioritize Stories
• Customers makes business decisions
• Engineers make technical decisions
• Don’t “steer” the customer
• Do help customer understand consequences of choices
• Do NOT try to persuade customer of priority ordering
20
Planning Work
• Once customer has chosen stories, teammates get organized
• Decide who will perform each story’s task
• Figure out how to work in pairs
• Plan how to avoid stepping on each other’s toes
• Finalize your development environment
21
Planning Work: Examples
• Monday: Jim & Peg
• Set up a database to store product data / ratings (1u)
• Load with two sets of test data
• Tuesday / Wednesday: Jim & Joe
• Create web page to show product’s data (1u)
• Create web page listing products, so user can click (1u)
• Use one set of test data for unit tests
• Tuesday / Wednesday: Peg and Phil
• Create a web page for uploading XML document (0.5u)
• Write code to read data into database (1u)
• Use the other set of test data for unit tests
22
Communicating Progress
• Track effort using PSP or similar technique
• PSP- personal software progress
• Track velocity- how many units per week?
• Constantly refine understanding of your capabilities
• All news (good or bad) should be communicated early
• Keep the customer informed of good & bad news
• Keep your team informed, too
• Release dates don’t slip; functionality slips
• May be necessary to delay user stories
• Customer prefers 3 fully-working user stories over 6 half-working
23
Communicating Progress: Examples
• Monday: Jim & Peg
• Set up a database to store product data / ratings (1u)
• Monday at noon: “DONE! Everybody should log in and try the DB”
• Tuesday / Wednesday: Jim & Joe
• Create web page to show product’s data (1u)
• Create web page listing products, so user can click (1u)
• Wednesday: “Finished story and completed integration test”
• Tuesday / Wednesday: Peg and Phil
• Create a web page for uploading XML document (0.5u)
• Write code to read data into database (1u)
• Wednesday: “Not done yet… probably tomorrow @ noon”
24
Evaluating Results: Continual Testing
• Unit tests
• Each pair responsible for writing tests, then writing code to satisfy tests
• Integration tests
• Several times during the week, check if pieces work together properly
• Acceptance tests
• Customer tests the system upon receiving it
25
Evaluating Results: After the Iteration
• Debrief (without customer present)
• Discuss what went well, what didn’t
• Assess your productivity
• Refine estimates of remaining tasks / user stories
• Evaluate release
• Customer runs acceptances tests
• Discuss what works, what to do next
26
Evaluating Results: Example Debrief
• Setting up database was faster than expected
• Jim was good at setting up database
• Have Jim teach this during future pairings
• Peg & Phil struggled with XML file upload
• Maybe pair them differently?
• Need a different file upload component?
• What files will be delivered during release?
• Configuration instructions?
27
Evaluating Results: Release
• Customer tries out acceptance tests
• User interface isn’t what customer expected
• Sketch some changes on paper
• Staple to the user story
• Customer shares five other ideas for extending vision
• Engineers write them as new user stories
• Launch into next iteration (estimating effort)
28
Next Steps…
• HW #4 (Design) due Friday!!
• Vision statement peer review next Tuesday!!
• Bring hard copy of rough draft
• Don’t forget your midterm!!
• Due 11/25
29