昨天晚上参加了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大小和多少有自己的经验。这些需要团队花时间做充分的学习和练习才能实现，否则该方法也是无法实现的。
介绍这个方法的时候有两个小技巧让我印象深刻：
- 数AC的个数能够对比出两个User Story的工件大小。(还记得上面说过的比对的三因素吧)所以要保证Story大小接近——数AC个数。
- 如果AC时使用Gherkin语法，观察前置条件能够发现User Story之间的依赖关系。对于思考降低依赖的方向是一种洞察。
技术债不应该计入User Story
技术债是债没有价值，不写成User Story。用户故事都是要最终产生价值的。最好的效果是每次Sprint不应该留下债务，如果要还债就要考虑降低产能来实现。所以留下的拷问就是：你是希望每次都不留债务呢？还是攒着之后拿出一次集中的时间来还债？哪个更有价值？
