组织和个人花了无数精力进行各种估算，结果往往不尽如人意，产出和付出难成比例。为什么？

估算是什么？

单独看估算这个词，其实意义不大，他只是一个动作，并不完整。完整的说，应该是，某人来给某物（某事）估计出某种度量指标。比如，我给这件古董估计一个价格，分析师给明天的大盘估计一个点数。回到软件行业，系统工程师给这个feature估计出Man hour的数值，PO或者团队给这个user story估计一个点数。

这里看到了估算的几个要素：

评估者

评估对象

评估单位，用什么尺子

评估约束条件，比如时间，谁来做这件事情，谁来买这个东西等等。

这些因素都影响着估算的结果。

既然估算是一个估计的活动，那么它还有其它相关因素

估算的方法

估算的工具

估算活动本身的成本

估算所需要的时间

估算的精度

估算的假设

估算的有效性（时效性，条件性等）

我们为什么要估算？

我们进行估算主要是为了帮助我们进行决策，指导我们的活动和行为。比如估计股市的趋势，进行操作，估计商品的价值进行买卖，估计市场的变化做好准备。

那么我们在软件开发活动中进行估算的目的是什么呢？

计算成本，估值报价

计算人工，安排人手

做项目计划，预计交付时间

项目、feature的横向评比

现实中估算的实际情况

现实中，估算活动的一些特点

估算是一项非常有挑战性的任务，尤其是对于人类而言

越是难以准确估算的领域，越是具有巨大的估算效益

估算是一项价值很高的大能力，精通的人很少

受不同估算因素的影响，估算的结果差异很大。不同的估算者，方法的不同，假设条件的不同等等

准确的估算只能产生于，局部，小范围，简单的环境下，短期内等，尽管估算相对准确，然而这样的估算对象往往难以产生较大的价值，它们往往被更多的不确定性所包围。比如汽车厂可以精确的估计汽车的生产速度，原材料的成本，可是很难去估算库存等成本，也就难以准确的估算汽车真正的厂家成本。

很多估算活动本身是费时、费力、费钱的

讽刺的是，很多估算活动本身成为了估算不准确的原因，比如长时间的估算过程，导致很多要素发生了显著变化

对于估算活动进行大量的投入，并不能带来相应的回报。估算的准确度不能成比例的提高，甚至会降低。然后由于准确的估算可以带来巨大的价值，很多组织无法忍受无所作为，依然投入不菲去加强估算活动。

走出估算的困境

估算为什么这么困难？原因很简单，估算的复杂度超出了估算的能力。解决的方法也是从两方面着手

提高估算能力

降低估算对象的复杂度

或者两者结合

如何提高估算能力，如何降低估算复杂度，必须从组织的实际情况，业务的实际情况出发来思考。没有包治百病、一吃就灵的灵丹妙药，必须认真思考。

敏捷实践中估算新思路

敏捷中很多实践就是从这两个方面入手的。

提高估算能力：

提高估算能力的核心是提高业务能力，对业务有着更深刻的理解。不深入钻研业务而希望估算能力有实质性的提高，是在希望一根魔术棒。如果有这么一根魔术棒的话，它也一定是价值不菲的。

计划会议，以往很多估算往往是少数专家进行估算，他们在必要的时候征求团队的意见。现在的做法是要求团队集体进行估算，在估算的时候，PO, 团队，团队内部的专家全部都在，而且可以采用planning poke的方式充分的收集团队意见。在现有人员基础上，增强了估算的能力，提供了更多的估算信息。

在SAFe (scaled Agile Framework) 模型中，大规模团队也要求所有scrum 团队一起，进行全员的计划会议，在大规模项目中聚集了更多的估算能力。

从发展的角度看，所有的员工都参与到了估算的活动中，随着短周期迭代，估算的经验不断丰富，每个员工的估算能力都得到提高，进而整个组织的估算能力也得到提高

有效的高频率反思会可以可以不断提高估算的能力

从精益和丰田生产方式来观察，通过价值流分析，安灯，看板，消除浪费等一系列的工具去暴露问题、发现问题，每当发现一个新问题的时候，就意味着对业务的理解又加深一些，当解决这些问题的时候，又意味着进一步的提高。当竞争对手还在用库存在解决问题的时候，丰田已经对形成库存的各种原因进行了细致而深入的理解。因此，丰田可以对各个生产、流通、物流环节有着更为精确的评估和预计。

降低估算对象的复杂度：

降低估算的复杂度主要从两个方面入手，一是改变业务方式，降低业务对估算的要求，二是分而治之，减小评估对象的规模、进而降低复杂度。

从估算目的上讲，敏捷弱化了估算目的2）计算人工，安排人手和3）预计交付时间，强化了估算目的4）横向比较，确定feature优先级，PO在管理backlog的时候，通过ROI来对待办事项进行排序，估算是为ROI排序服务的。基于这个目的，对于估算精确的要求大大降低了。估算侧重中相对排序，而不是绝对价值。五个指头比长短，要比五个指头量长度要容易很多。

从估算对象上，限定到可以在一个短周期的scrum迭代中完成的user story上，相比一个feature,或者项目，估算的规模要小很多。

把user story这个粒度上，它的技术复杂度也降低了，一个scrum 团队具备所有的相关知识和技能，评估者的能力和评估对象复杂度的鸿沟给弥补了。

评估的周期也在几周之内，而且估算之后马上执行，减少了不连续带来的变化和不确定性。

估算和执行也是由同一个团队完成，也消除了替他人进行评估的复杂度和不准确性。

敏捷实践中估算的问题

良好的实践可以带来估算新思路的收益，然而现实中还是遇到种种问题。

热衷于形式化的工具，比如planning poke, 不花心思去钻研业务，工具只成为了形式和热闹，没有切实提高业务能力和估算能力

专家和PO，或者其它架构师、系统工程师游离于团队之外，依然控制着估算过程，本质上估算的主体和方式没有发生太多变化

估算目的依然是安排人手、 报价、预计交付时间等，依然要求对于项目和feature级别在早期进行较为准确的估算，要求觉得人工、资金等成本估算。

PO对于product backlog的管理，徒有形式

User story不是独立的用户价值

Scrum 团队无法独立完成user story, 团队间依赖关系很强。

因为这些原因，团队的估算能力没有提高，估算对象的复杂度也没有减低，所以估算的困境并没有得到改善。因为估算要求未发生改变，新的估算方式（尤其是相对估算）不能完全满足估算要求，老的估算的方式依然以某种形式存在，反而增加整个组织的负担

相对估算和绝对估算

严格意义上讲，没有绝对估算，所有的估算都是相对的。是评估者，评估对象，评估单位（尺子），约束条件下的产物而已。只看尺子，是有失偏颇的。从尺子看，也没有绝对的尺子，黄金、美元、人民币这些都是绝对的么？换一把尺子，就会有不同的结论。

先来看看软件领域内所谓的绝对估算吧，man hours, 或者 man days, person months, 这人月真的就成了一个神话，离了他很多人都心中不安。

man day 中的这个man是谁呢？评估者自己，或者评估者心中的平均水平的那个抽象的人，或者是评估者预计到的那个工作者（或者工作团队）的抽象的劳动力，或者其它心中构思出来的man。换一个评估者，那个man又不一样了。这个man day绝对么？

Man day不是一个绝对的评估值，她是一个人人都可以理解的评估值。然而，虽然人人都可以理解，但是每个人看到这个评估值的时候，心中理解的真实工作量都会是不一样的，也会根据评估者的背景和自己的背景再来折算、评估一下。

除了容易理解，man day还有一个优点，管理者可以利用人月神话去计算各种需要的数据了。可以计算成本，可以计算交付周期，还可以用人手去换取时间，用时间去换取人手。有了man day, 一切都可以管理了。有了意外怎么办？有风险管理，危机管理，还可以有lesson learn去反思为啥估算不准确，找几个改进点，下次继续改善。从管理上看，已经自我完备了，各种情况都可以得到处理。

再来看相对估算，相对估算的单位是点 (point), 它的尺子是某个功能或者user story （用户故事），这尺子和man day有所不同，它是一个客观的任务，不是人的工作量，这是这把尺子的优点。估算就是用这把尺子和估算对象进行比较。我们类比一下用货币去衡量商品的价值，我们可以用黄金、美元、人民币，这些货币的尺子是大家用了很多年的，广为理解和熟悉的，而且所有的人都在用这几把尺子。

很不幸的是，在开发中，相对估算没有黄金这样的尺子。这把尺子很不固定，一个scrum 团队在不同的迭代中都有可能用不同的尺子，不同的scrum 团队也会用到不同的尺子，不同的产品线也会用的不同的尺子。这把尺子本身时间上不具备稳定性，空间上不具备通用性。所以这样的尺子就很难被大家理解。

当用这样的尺子去计算成本，交付周期，安排人手的时候，就会遇到很大麻烦。在现实中，需要在某个环节进行一些复杂的计算和转换。

对于相对估算来说，需要有几个问题要考虑：

划定相对估算的作用范围，时间范围和空间范围，一个团队，几个团队，一个产品？若干迭代, 一个release, 一年？

在各个独立的作用域里，选择合适的尺子，保持尺子的稳定性和通用性，使大家容易理解

有了稳定和通用的尺子，计算出来的velocity就有了实用价值。可以用点数，结合velocity, 计算、评估进度，工作量，具体的 man days (这不是抽象的man, 是那个具体工作的man, 这不是评估的man day, 是根据经验趋势计算出来的 man days, 因此也是更加准确的 man days), 也可以预计成本和交付时间

User story的质量是找到这把尺子的关键，如果没有良好的product backlog, 没有高质量 (INVEST) 的用户故事，是很难找到这把尺子的。

寻找一把合适尺子是相对估算的计算，没有这把尺子，相对估算的各种方法和技术只能是水中月、鏡中花，看起来很美，带给人的却是困惑、忧愁，抱着美好的愿望，花费了很多心力，到头来却是竹篮打水一场空。

建议

要想用好相对估算，需要打好基础，这基础打好了，即便不用相对估算，团队也能收益。

管理好product backlog

提高用户故事的质量

提高scrum 团队的独立工作能力，尽量解耦各个团队。

寻找一把好的尺子做相对估算。

结合相对估算和velocity，给管理团队提供各种数据。

2015-08-11 广州