问题提出
近日有位做软件开发的朋友对我说，他的经理在回顾会的时候为各个团队买披萨。我一听，这好事啊，不时的庆祝团队取得的成果，对提高团队的士气非常重要，经理能意识到这个点，实在是团队之幸。可是我这朋友却高兴不起来，有些团队对这位经理间生了抱怨。 道出原委，原来经理买的披萨是跟据团队交付的故事点来的，故事点高的团队，可以得到大尺寸的披萨，故事点低的团队只能分食小尺寸的。
团队为什么会抱怨呢？是因为披萨太小不够吃吗？ 部分原因可能是。但最主要的原因，我想是这位经理把团队迭代的velocity 作为考核指标来用了。Velocity 是表示了一个scrum 团队一个迭代交付速率，我们是根据前面几个迭代的平圴交付的故事点来评估这个值。而故事点的由来，则是在refine meeting, planning meeting，由团队来估算的。
团队感觉到有考核的意味在，就开始警觉起来。更重要的一点，不同的Scrum团队的velocity, 在多个迭代的趋势上可能可以看出一些的差异，但单个迭代是绝对没有可比性。因为不同团队的story size估算基准是不一样的，项目本身也有差异性。这位经理看起来是用一个标准，即velocity大小来衡量不同团队的绩效。所以团队内在的抵抗开关就被这个事件触发了，导致的结果就是，团队开始往大了估算，因为领导希望看到大的结果，这是典型的measurement dysfunction。
这里就引出关于敏捷估算的问题，比如，什么是敏捷估算？估算有什么用？怎样做敏捷估算？怎样正确理解敏捷估算和velocity 的关系？
敏捷估算的特点
提到估算，相信即使是做瀑布的同学也非常熟悉。在瀑布项目管理过程中，项目经理会估算工作量，作为预算和工期估计和计划。《人月神化》有类似的这么一个比喻：一个项目估算出需要12人月，如果有12个人，换算过来，一个月就能完成。现在人们常用的一个比喻是，9个孕妇不可能一个月生出一个孩子！这都是对估算和计划的调侃。
敏捷估算有什么特点呢？首先敏捷估算同样也在项目计划中起到非常重要的作用。有效的估算活动，可以让团队心中有谱，降低项目的不确定性，提高预测能力。而在传统的软件项目管理，可预测性非常弱。鲜有按期交付的软件。即使有些项目满足了deadline, 也是多少攻城狮没日没夜堆出来的! 敏捷估算的过程也和传统项目管理不同。不像传统项目管理的一锤子买卖，敏捷估算是持续的一个过程，并且估算的准确性和用户故事粒度保持一致。即越接近当下的估算越准确；排期靠后的估计粗略一些。再者，也是敏捷估算最大的一个特点是是采用相对估算的方式，估算不带单位。
敏捷估算方法
谈到估算，我们一般会想到用一个量去衡量，并且带有单位。比如，升高用厘米，体重用千克。这种估算方式，我们叫做绝对估算。还有一种是比较式的估算，我们称作相对估算。做估算时，先选取一个参照物，再对照比较目标，有多少个参照物的当量。这种估算方式，在其他学科也用得比较多， google 搜索当量+某一学科，可以看到类似的应用和研究都比较多。
敏捷估算的标量常有两种方法，一种是用部分斐波那契数列，0 ，1 ，2 ，3 ，5 ，8 1，3， 21，∞ .还有一种是用 T shirt 尺寸 S，M，L， XL， XXL对应到数字是1 2 4 8 16。简单易用起见，推荐 T shirt尺寸。
估算需要选取一个基准story。比如这个估算的例子：一个团队用T shirt size序列来估计，团队选取了一个网页登录故事用例，包含了网页，开发包括后台，数据库的工作项，还有测试部署工作也估计在内。这个基准故事用例故事点为2。在以后做story size评估的时候，就去参照这个基准。
团队在评估故事点的时候，可以借助计划扑克或者便利贴。每个队员在做完评估后，亮出自己的估值果。当大家的数字不一致时，可以请最大估值和最小估值的同学说下自己的考虑。也可以参考已经估过的story，通过对比，得到一个合适的值，这样在团队共同理解的基础上达成一个共识。
正确理解估算
有很多团队，做估算慢慢变成了随意给一个值，甚至PO就把这个决定了。为什么会出现这种情况呢？因为有观点人为，story不管估算size多少都是要做的，估算的值没有意义。既然意义不大，花时间在这里不是一种浪费么？还有的团队也根据经验估计下，不过这个数字都往大了估，这样做起来就比较有安全感。这种现象的根源还是没有很好的理解估算。
估算一个重要功能是预测性的把控。这需要和velocity结合起来。如果估算环节没有做好，这些数据出来就没有反应出真实交付能力，可预测性就无从谈起。这直接影响到发布计划，进而影响到整个产品的上线时间和用户反馈，也会影响到产品相关的各种决策。所以我们通过估算，做到心中有谱，便于资源的调配和，给决策提供参考。
估算的另一个重要作用，是通过这个过程，团队可以对故事用例深入了解。因为要相对准确的估算，就需要对故事用例的业务逻辑，技术实现和工作量有全面的了解。在这个过程中，如果发现这些点比较复杂，就直接指导我们对故事用例进行拆分。这也是估算推荐的正确姿势：给出基准，把基准按业务，技术和工作量拆分，比如，都是1。同样，对目标故事也从这三个纬度去拆，每个纬度分别和基准的纬度比较，给出一个合适的值。最后把三个纬度的估值加起来，除以基准的三个纬度的值，就得到了相对准确的估值。
在三个纬度的估算上也有一些技巧。技术上，考虑功能点的多少，比如数据上是直接从数据库映射还是要通过一些处理，有没有技术难点，用已有框架还是要用新方案，页面实现难度怎么样。业务上，有多少业务逻辑在里面？参考代码的圈复杂度，业务上有几个圈，有几条可达的路径？ 同时参考业务逻辑流程图，AC数量。工作量上，考虑测试用例个数，数据准备需要花的工作，部署工作等等。这样分解下来，就能很好的理解这个故事用例的方方面面，也会减少团队理解的不一致。
更多思考
估算也可能存在变化，比如是随着团队的成熟和对业务技术的熟练，团队原来觉得复杂的，现在变得简单，所以估算时，原来3个故事点，现在估计只有2个故事点。估算本来就是个动态的过程，把握了估算的基本原则，其变化未尝不可。但仍然要记得，100米对大人小孩都是100米。
Story size估计除了影响计划，还影响到velocity。 对于这个数据，比较好的状态是，当参考基准不变的情况下做出的story size的估计，velocity有上升趋势。在参考基准变化（选取参考基准变大）情况下，velocity趋势保持稳定。开篇的时候提到的团队的抱怨，正是那位经理错误使用这个数据的产生的副产品。