软件开发中估算的困境和思考
组织和个人花了无数精力进行各种估算，结果往往不尽如人意，产出和付出难成比例。为什么？
估算是什么？
单独看估算这个词，其实意义不大，他只是一个动作，并不完整。完整的说，应该是，某人来给某物（某事）估计出某种度量指标。比如，我给这件古董估计一个价格，分析师给明天的大盘估计一个点数。回到软件行业，系统工程师给这个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 广州
