如何进行用户故事估算——Ethan 分享观后感

昨天晚上参加了 Ethan Huang 老师的”用不做估算来做估算”的线上分享，颇有感触——Ethan 的分享每次都是干货满满。今天做了一些总结，分享到这里希望对大家也有启发。

敏捷估算一直是一个无法绕开又非常令人头疼的话题。无法绕开是因为无论是产品还是项目都离不开估算。令人头疼是因为估算结果一般都很难令人满意。

工作量一词的起源

工作量一词英文叫 Effort，他的定义是为了把一件事情完成，他的背后所有需要努力的综合。也就是消耗的能量。例如喝一杯啤酒，你要做多少功(能量/卡路里)。同一个人同样一杯啤酒可能需要的时间会不同，根据场景不同。但是对你来说最后消耗的功应该是一样的。这么看这个 Effort 其实和时间没有关系。而我们工作中的评估常常会把工作量和工时关联起来。而从上面的喝酒的例子也能看出，现在项目管理中估算的工作量更多的是通过时间换算成成本而不是真正的 Effort。

准确和精确的认识

之前确实没有特别在意这两个的不同。例如一个靶子，射中靶心的圆圈，这就是准确。你射 10 支箭可能都在靶心圆内但是很分散，这种叫做不精确，如果你 10 支箭都射中一个点位或者距离很近那叫做精确。我们在项目管理中都希望评估又准确又精确，3.125 人天和 4 人天有多大的区别？在传统项目管理中估算只做一次，要求既准确又精确其实很难，毕竟那时候一切都还是不清晰的。而敏捷项目估算发生在每一个 sprint 前，至少可以做一下调整，就算不能做到精确也能做到准确。所以从这个角度来考虑性价比准确但不精确来的更高一些。

对比 User Story 的三个因素

绝对和相对估算这里就不再细说了。这次分享让我眼前一亮的是比较 User Story 估算的三个因素：工件的大小，技术复杂度，需求复杂度。这三个维度能够相对完整的引导团队在评估时候的思考。例如软件项目中的国际化工作，也就是翻译 UI 上面的词条支持多语言。那么技术复杂度和需求复杂度都不高，可以说 0，但是工作内容要 Copy Paste 很多词条到资源文件重复工作这个大小很大。另外一种思路也让我眼前一亮。可以想办法设定某几个因素固定，这样评估就只是一个因素。例如我要用乐高做出来下面几个动物：瓢虫，鸡，青蛙，猫，狗，老虎，龙。乐高的技术复杂度是一样的，我要求动物都一样大小，那么决定最后评估量的就是需求复杂度了。这个例子中龙肯定是最高的，猫狗老虎应该是相似。瓢虫最简单，鸡和青蛙相似。当然在实际软件项目中，每一个 User Story 都可以用这三个因素为一行，拉出来一个 Matrix，把每一个因素的评估用数字来代表(当然需要一个基础 User Story 来做相对估算)，最后三个因素相乘计算出加权平均数。选择一个 User Story 的加权平均数为基准，其他改成他的倍数。相对评估的一个典型例子出来了。不过 Ethan 建议这种方式在介绍相对评估以及故事点评估方法时候可以用来教学使用，实战的时候仍然会有很大出入。因为大家还是会用自己的实际人天数来参与评估，其实还是绝对评估，而每一个维度的评估的偏差都会带来很大的误差。不过个人觉得如果在 Team 转型过程中，如果有足够的时间，这个方式确实可以作为一个过度来让 Team 了解相对评估的感觉。

斐波拉契数列的用法

1/2,1,2,3,5,8,13……。用它玩过敏捷估算扑克，居然没发现自己一直没有用对。其实每一个数字代表的是代表前一个和后一个之间的估算的意思。例如 5 代表当前的估算是在 3 和 8 之间。因为比 3 要多而达不到 8，那么就选择 5。以前还考虑如果团队觉得 6 或者 7 的时候怎么办是不是选择大的。其实不需要纠结，5 代表的就是区间的所有可能。如果团队觉得已经到 8 了，那么就可以给出 8。从这里也验证了越大的数字可能很准确，但是不够精确，因为有很多不确定性，范围太宽泛了。

数 User Story 个数法

Ethan 老师推荐的估算方式是数 User Story 的方式(不用估算的估算)。当然前提是 User Story 的大小相近，那么数 User Story 来作为工作量的估算就成为了可能。这里需要用到用户故事拆分的一些技巧(感兴趣的朋友可以翻看我之前的分享)。当然这种方法如果要能实现，还有一个前提是团队需要是稳定的。对单次 Sprint 中能够完成的 User Story 大小和多少有自己的经验。这些需要团队花时间做充分的学习和练习才能实现，否则该方法也是无法实现的。介绍这个方法的时候有两个小技巧让我印象深刻：

1. 数 AC 的个数能够对比出两个 User Story 的工件大小。(还记得上面说过的比对的三因素吧)所以要保证 Story 大小接近——数 AC 个数。

2. 如果 AC 时使用 Gherkin 语法，观察前置条件能够发现 User Story 之间的依赖关系。对于思考降低依赖的方向是一种洞察。

技术债不应该计入 User Story

技术债是债没有价值，不写成 User Story。用户故事都是要最终产生价值的。最好的效果是每次 Sprint 不应该留下债务，如果要还债就要考虑降低产能来实现。所以留下的拷问就是：你是希望每次都不留债务呢？还是攒着之后拿出一次集中的时间来还债？哪个更有价值？

【欢迎关注我的博客】