估算介绍

在以前开发 IT 软件时，使用较多的衡量软件开发工作量的单位是：小时、人天 或 人月。它是预估开发时间。比如：这个功能张三一个人开发需要 3 天时间完成.

这种 “人天” 估算只是 “理想人天” 的估算，有时与实际开发完成所需天数有很大差别。因为每个人完成同样复杂度工作所需的时间是不同的.

那在敏捷 Scrum 框架中，用户故事的开发工作量，如何估算一个用户故事开发工作量？估算开发任务工作量是一件很困难的事情，它需要考虑的因素有很多，包括:

• 用户故事的规模大小
• 业务复杂度、难度
• 业务规则复杂度
• 开发人员能力大小、个体差异
• 团队成员休假、有事请假等突发因素

等等各种因素.

虽然很困难，但是智慧的人们还是给出了一些估算的方法，帮助 Scrum 团队对开发任务进行估算。下面介绍几种估算的方法.

估算在 Scrum 的哪个环节呢?

一般在 Sprint 计划会议上。 当产品负责人和 Scrum 团队人员选择好了 Sprint backlog 里的待开项，也对大的开发项进行了拆分。对不理解的一些开发项，相关负责人也进行了解释，团队成员理解也达成了一致。这时就可以进行开发任务工作量的估算了.

故事点Story Point

故事点介绍

什么是故事点 Story Point?

故事点是一个度量单位，完成某项开发任务所有工作量的估算结果。被估算的不是花费的时间长短，而是工作量多少.

故事点一般用来衡量用户故事或任务的工作量、复杂度和不确定性，它不是传统的估算方法：小时 或 人天。它不依赖具体的开发人员或开发速度，更多强调团队内部讨论，协商一致性和相对估算.

不同于预估完成任务所需时间长短，故事点关注的重点是复杂度和不确定性.

它是一个相对度量单位，一般是相对于基准故事.

在做故事点度量估算时，会选择一个基准故事（一个已知大小和复杂度的故事）作为基准点来参考，其它故事相对这个基准故事来做度量，对故事工作量进行估算。 然后额外考虑故事的复杂度因素、风险因素、不确定性因素，并且为这些额外的因素加上点数，这样估算出来的故事点数相对来说正确性就提高了许多.

故事点数 = 完成故事所需工作量 + 复杂度因素点数 + 风险因素点数 + 不确定性因素点数 。

注意:

• 1、 这里的点不代表任何时间长度。它只是一个工作量多少的度量单位。

估算数值选取

通常采用斐波那契数列，如 0、1/2、1、2、3、5、8、13，20，40，100；有时也采用自然数来替代，如 1，2，3，4，5，6。 具体情况要看故事之间的大小差别，怎样的数字间隔更加适合团队估算的情况.

斐波那契数列称为黄金分割数列，随着数字间距的扩大，对于颗粒度较大的需求更加便于我们判断选择哪个数字.

估算故事点简单流程

1、选择基准故事 。

团队先选择一个已知的用户故事作为“基准故事”，这个基准故事的任务复杂度和工作量是团队成员已知且易于理解的任务，然后给这个基准故事打一个故事点值（比如 3）。其它故事就和这个基准故事进行比较.

2、讨论和理解故事 。

在估算其它用户故事或开发任务时，要确保团队成员对任务的需求、复杂度、潜在风险的理解相一致。大家一起提问、讨论问题，产品负责人进行解释回答.

3、选择估算值 。

讨论完成后，团队成员各自独立选择，选择认为合适的故事点数值（如 3，5，8）。每个人的估算都应该是基于对任务相对复杂度、风险因素的理解上，而非实际工作时长.

4、展示估算结果 。

团队每个成员独自选择估算值完成后，所有人同步一起展示选择的数值。如果估算结果一致，则记录下该数值；如果估算结果值差异较大（比如一个是 3 ，一个是 13 ），则需进一步讨论.

5、 讨论估值差异后达成共识 。

当出现较大估值差异时，团队成员需要解释为什么选择该值。在讨论中，通过进一步澄清需求细节、拆解任务等方式，帮助团队成员更好地理解任务的复杂度，从而达成共识。 达成共识后，记录下最终讨论的估值数。然后进行下一个故事估算的讨论.

计划扑克估算

计划扑克估算，和上面的故事点估算，做法大同小异，它把故事点估算通过游戏化的方式来进行，改进了估算方式体验。 计划扑克是通过游戏化方式来进行估算，带有一点娱乐性质，体验效果可能会更好.

计划扑克介绍

在敏捷框架下，Scrum 团队是一个自组织团队，团队决策多数是集体协商，共同承诺。计划扑克就是一种集体估算的工具，通过游戏化的方式来进行估算，鼓励团队成员充分表达意见.

计划扑克是一种基于团队共识的估算方法。团队成员每人会拿到一套特制的卡片（扑克牌），卡片上标有数字，这些数字通常是斐波那契数列（如 0、1/2、1、2、3、5、8、13，20，40，？，∞ 等），卡片上数字大小表示对任务估算的估值数.

• “∞” 卡用来表示估算者不认为这项任务能够完成
• “？” 卡用来表示估算者无法进行估算

有的还有一张 咖啡 卡牌 ，表示估算久了，需要休息片刻.

有的团队也用自然数排列的牌，也可以，根据被估算的故事差异大小而定.

参与人数

一般是 4 - 8 人，参与人数太多，会拉长估算的时间，降低估算效率；人数太少，会导致估算结果偏差大.

计划扑克游戏过程

1、讲解用户故事 。

产品负责人从 Backlog 中选择一个待开发项（用户故事或任务），然后为大家进行简要的介绍.

2、讨论故事需求 。

团队成员针对该开发故事进行讨论，提出问题，产品负责人负责解答所有问题.

这一步是团队成员和产品负责人进行交互讨论：理解需求、实现细节、潜在风险等等，帮助团队成员和产品负责人对开发的需求理解是一致性。 这时，产品负责人可以根据大家的反馈，及时修改并完善开发项（需求）.

3、选择估算值 。

3.1、选择基准故事 。

估算时，常用的是相对估算值，不是绝对估算值。跟上面的故事点估算一样，会选择一个大家易于理解的故事作为一个基准故事，比如这个基准故事故事点值为 3，然后其它故事和这个基准故事比较，得出估算的相对点数值.

3.2、进行估算 。

团队成员已经对该开发故事有充分了解，没有问题后，大家就根据自己的理解和经验，各自独立选出一张代表自己估算值的卡牌，卡牌面朝下放置，不明牌.

这一步团队成员之间不可相互讨论估算值.

团队成员估值都完成后，大家同时亮牌，展示各自估算结果.

4、讨论估值差异 。

若每个成员对用户故事的估值差距不大，则记录下估值； 若每个成员对用户故事的估值差距较大，说明大家对该用户故事的理解、价值没有达成共识，大家需要解释为什么这样估值？然后对估值结果进行讨论.

例如第一轮估值亮牌结果为：3，3，8，13。这 4 个估值数明显 1 个偏大（与平均值对比），2 个偏小，大和小差距过大。平均值为 6.75，四舍五入为 7。 两个估值数 3 过小（偏离平均值）的成员需要解释为什么这样估值？估值数 13 过大的成员也需要解释为什么？然后大家对给出的解释一起讨论，对需求开发不同认知点、怀疑的点进行讨论.

讨论注意点:

• a、敏捷教练要维护活动秩序，避免不必要的争吵和跑题。
• b、无需深入代码细节，这是开发人员最爱跑题项之一。
• c、鼓励大家都发言，不能总是某几个人发言讨论。

大家讨论完成后，再进行估值。重复上面的第 3 、4 步骤。一般经过 2 到 3 轮就可以得到一个相差比较近的估值.

如果第 3 轮估算结束后，大家还没有得到一个相近的估值，那就取一个大家认可的平均值作为估算结果.

差距大时，估值讨论不能无尽循环下去，这样会浪费大家本可以做其它工作的时间。这也是扑克估算的缺点，有时会耗时.

估值的目的，第一，大家都了解故事开发的复杂度和工作量；第二，大家了解所做的详细工作有哪些；第三，大家对做的工作能有一个共识.

团队成员需要在尽可能短时间内，达成一个一致的估值结果.

其它估算方法介绍

亲和估算（Affinity Estimating）

亲和估算首先需要在一个白板或者墙上划分出不同的区域，每个区域代表一个工作量范围（同样可以用故事点来衡量），例如分为 “小（1 - 3 个故事点）”、“中（4 - 8 个故事点）”、“大（9 - 13 个故事点）” 等区域.

然后将所有的用户故事写在卡片上，团队成员一起把这些卡片按照自己对用户故事工作量的判断，放置到相应的区域中。在放置过程中，团队成员可以对每个用户故事进行简单讨论，确定其所属的工作量范围.

优点： 相对来说估算比较快速，能够在短时间内对大量用户故事进行初步估算。帮团队成员整体上把握用户故事的规模.

缺点： 它的估算精度相对较低，因为只是将用户故事划分到大概的工作量范围，没有像计划扑克那样精确到具体的数字。还有团队成员对工作量理解不一致，导致用户故事放置混乱，需要花时间重新讨论和调整.

功能点数估算

功能点估算方法是从用户的功能需求角度出发，通过计算用户故事中的功能点数来估算工作量。 比如后台用户管理功能，可能有增加、删除、修改、搜索、查看用户详情等功能.

优点： 以功能需求点为基础，比较客观，能一定程度上避免团队成员主观因素导致的估算偏差。它适用有详细需求文档的情况下，可以较准确估算工作量.

缺点： 功能点估算方法需要对系统的功能有详细的分析和定义。计算功能点数需要一定的专业知识和经验，而且不同的人对功能点的计算标准可能会有差异。此外，它没有考虑到非功能因素（如性能要求、安全要求等）对工作量的影响，可能会导致估算结果不够全面 。

最后此篇关于敏捷开发：用户故事估算方法介绍的文章就讲到这里了,如果你想了解更多关于敏捷开发：用户故事估算方法介绍的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。