庖丁解牛用户故事 (splitting your user story)
Post on 20-Aug-2015
1.106 Views
Preview:
TRANSCRIPT
© Copyright 2011 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. HP Restricted
Ali
HP Agile Consultant Services
Splitting your
User Story 庖丁解牛用户故事
姓名: 郑立 （Ali）- HP 敏捷服务培训经验：5年 认证：MBA,CSM,CSP,PMP,ITIL Agile coaching experience : 5 years Certification: MBA, CSM, CSP, PMP, ITIL Email: Aliama0288@gmail.com Tel: 13761850288 Weibo：http://weibo.com/ali0288
惠普资深敏捷顾问，曾负责并参与惠普中国敏捷流程建设和开发。并不断对敏捷在惠普中的现状进行改进。 有丰富的团队辅导经验和培训经验，辅导过多个团队进行敏捷式开发。 参与各项敏捷大型活动，并乐与在社区相互分享经验，通过交流学习和提高敏捷在企业中的应用。 Senior Agile Consultant at HP, used to response for the HP Agile process building and deployment, and always focus on continuous improvement. He has rich experience on coaching and trainings, has coached many teams transfer from traditional to agile. He is active in many agile events, likes to share the experience with others, and learn from each other, for the purpose of improve the practical in enterprise.
上海惠普敏捷咨询团队
Objectives
Project Headaches!
Why need Spilt?
How to Split?
• Arrange them
• Split Them
Note:
HP Restricted | Date or Rev. # 6
Project Headaches !
Think different!
We Built Lots of Stuff we Don’t Use
One of the biggest costs of traditional development is overproduction of features • Must be designed, built and maintained
• Doesn’t get used – provides no value
Never 45%
Always 7%
Often 13%
Sometimes 16%
Rarely 19%
Feature Usage
Often or always used: 20%
Rarely or never used: 64%
Source: Jim Johnson of the Standish Group at XP2002
Things are happening
around us!
The Status of Software Project
Requirement Estimation
Change Defect
Employee
Value
HP Restricted | Date or Rev. # 10
Why Need Spilt ?
Small is to improve the Utilization
from Dean Leffingwell, User Story Primer
Small is Evaluable
Small is to priorities
3
4 5
2
8 9
User Story A User Story B
Small is to priorities
2 3 4 5 8 9
Low Medium High
HP Restricted | Date or Rev. # 16
How to Split?
庖丁解牛法
Starts from most important user stories
Keep User story integrated
Principle Cut off the non-value user stories
Priorities user stories
Easier to implement and test
Purpose
User Story Splitting Principle and Purpose
Arrange user stories
Find out the system backbone and joint
Themes - Joint
Grouping of related items in the product backlog
Themes act as placeholders for product functionality
EPIC
THEME
User Story
User Story
User Story
User Story
THEME
User Story
User Story
User Story
Take this for example
Example: Payment • Story 1: Pay by Visa Credit Card
• Story 2: Pay by MasterCard
• Story 3: Pay by China Union Pay
Ways to resolve dependencies… 1. Combine stories into one larger independent
story (Story 4)
2. Split the stories differently (one credit card, additional credit cards)
Story 1 Story 2 Story 3
Story 4 Becomes…
Story 5 Story 6
Air tickets booking history list page
We used to: (work follow)
Design Code
Implement Testing Documentation
Or (architecture )
Database Design
Business Logic
UI Design
Splitting in right way
Booking Information View - Theme
User Name and
1 book record
Add more user
information
Cancel Booking
Enhance Performance
List all book record
Filter Function
Search Function
User Passport Age,
Address, Company
name
Contact Informati
on
Split User Stories
Is your Knife sharp enough now?
Cut off the skin
type Role
Relationship
Data
status Operation
Break the joint
Story A
Common
Story B
Split methods
Workflow Steps
Business Rule Variations
Major Effort/Key Mechanisms
Simple/Complex
Variations in Data
Alternative Interface Options
Lifecycle of an Entity (CRUD)
Improving performance or user experience characteristics
Simple/Complex
When the team is discussing a story, and the story seems to be
getting larger and larger (“what about x? - have you considered y?”), stop and ask “what's the simplest that can possibly work?” Capture that simple version as its own story, and then break out all the variations and complexities into their own stories.
As a traveler, I can search for flights between two destinations…
...specifying a max number of stops
...including specifying specific airports
...using flexible dates
...specifying flight times
Source: Adapted from Dean Leffingwell, User Story Primer
Workflow Steps
Split the story into steps a user takes to accomplish a
workflow and then implement the workflow in incremental stages
As an online shopper I want to checkout my shopping cart
...I can select my shipping address
...I can review and confirm my order
...I can select my payment method
...I can select my shipping method
Source: Adapted from Dean Leffingwell, User Story Primer
Improving performance or user experience
characteristics
Sometimes, the initial implementation isn't all that hard, and the bulk of the effort relates to making it faster, more reliable, precise or scalable.
However, the team can learn a lot from a simple, quick implementation which unlocks some value for the user community in the first place. In such cases, break the epic into successive stories that add improved user experience characteristics (or “-ilities”).
As a traveler, I can search for flights between two destinations…
...showing a “searching” animation (slow)
...with results shown within 3 seconds
Source: Adapted from Dean Leffingwell, User Story Primer
Are you ready for Split?
©2009 HP Confidential
Thank You
Q & A
top related