Being Agile！敏捷开发中的故事点估算-京东云开发者社区

#### 一、什么是故事点
**故事点 **是用于估算一个或多个用户故事的**复杂度**的一种**描述方式**，包括：
- 功能的难易程度
- 风险或不确定性
- 拆解的工作量

#### 二、故事点估算的特点
故事点（story point）和预估时间（estimated）不一样，它并不能和类似“人天”这样的单位画等号，它没有单位，是一个**相对数字**。每个人完成同样复杂度的工作所需的时间是不同的，所以不能等同于“人天”估算。还是那个例子，同样是1000米，我花的时间和你花的时间不一样，但都是1000米。

- 故事点估算是一种**相对的估算**，不是绝对值
- 故事点估算采用团队**共同估算**的方式进行

#### 三、故事点估算的好处
故事点估算相对于**预估时间**估算，可以更快且相对准确的评估迭代范围，通过历史迭代速率很方便的建立交付计划。

**使用这种方式的好处是它能让所有人对评估更容易达成共识**。而且它可以有效的避免不假思索的跟风行为，每个人必须对用户故事的复杂度进行思考，才能给出一个相对可靠的故事点，否则就要向所有人进行解释。
- 基于故事点的估算更纯粹，不会因为开发人员的变更，时间的推移而改变
- 故事点估算是相对估算，会让估算更迅速
- 集合了所有成员的意见，比一个人的估算少了很多主观成分
- 在估算过程中，强化了对需求和任务的理解，降低了不确定性

#### 四、故事点估算的流程
1. PO对某一个用户故事进行讲解，团队进行充分讨论，澄清用户故事
2. 团队进行共同估算，所有人对用户故事进行独立打分（**可以使用计划扑克，如微信小程序：Scrum敏捷估算**）
3. 当所有人都打分完成，显示打分结果
4. 请估算差异最大的两位成员澄清各自估算的原因
5. 团队讨论，消除分歧，当所有人对估算达成共识，将点数结果记录在行云卡片里面（用户故事的细节和风险因此可以得到更加充分讨论）
6. 重复上述步骤，直到所有卡片完成

##### 五、建立故事点的基准
**估算前需要建立一个基准值，团队可以跟据过往完成的需求来设定基准，**这个需求的规模需要所有成员达成共识，有一致的认知。如果设定这个基准故事用例故事点为2，在以后做其他用户故事估算的时候，就去参照这个基准进行评估。

**以下为【XX自动化团队】通过长期实践摸索出来的故事点基准：**

##### Java服务单工程修改
- Java服务端增删改查：1起

##### 前端工程
- 前端新增功能：0.5 起
- 前端修改： 0.2起
- 打印类：0.5起
- 新增报表类：0.5起

##### MQ消费类的
- 基本消费落库：0.5起

##### JSF服务类
- 基本对外服务：0.5起
- 基本跳转服务：0.5起

##### 六、注意事项
- **更小规模**的用户故事总是更容易被估算，所以建议对用户故事进行小颗粒度的切分
- 估算的时候保证**参与成员都对估算对象有足够的了解**，有疑问的地方一定要和PO充分沟通
- 团队一定要坚持**统一的故事点标准**，以便于测量团队的交付速率
- 故事点对于**不同团队**有着不同的定义。**团队间横向比较是没有太大意义的**
- **不要过度关注故事点的绝对大小。**比如只需保证3个故事点的需求比2个故事点大，比5个故事点小就够了
- **当多轮估算仍不能达成一致时，可以考虑取相对较大的数值**，因为软件研发领域的估算相对乐观，同时避免在一个故事的估算上纠结太久（支持多种得分计算方式：算术平均数、切尾平均数、中位数、众数、自定义等）

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：效能提升部 刘启佳
![](//img1.jcloudcs.com/developer.jdcloud.com/43de63e2-08d6-41a6-ab62-d37b8f81463020210113144615.png)