谈到敏捷，人们往往都非常高调地打探TDD与持续集成。同时很多实践，非常低调。比如，估算。学习TDD，你有很多具体例子可以学习。但是学习估算，却无从下手。在“搞砸”了几个项目之后，貌似我摸着了一些门道了。
估算的目的
在我看来，估算有两个截然不同的目的。第一个是报价，第二个是规划。为了报价，我们追求的是所有故事卡的总体的绝对大小。为了指导发布规划和在迭代开发中做调整，我们追求的是故事卡之间的相对大小的准确。但是无论，这两个目的都很难达到。
别说不靠谱
首先我想说，估算故事卡的绝对大小，然后拿去报价，TMD这就是扯——淡——。不过，谁让我们是小角色呢，领导让你做估算，你还能不做不成？想不想干了？所以，我们还得干。但是，还千万别不认真做。做得一塌糊涂的估算最后还是要我们一个一个故事卡地去码代码，最后倒霉的还不是我们这些小角色吗？所以，即使你觉得这追求估算绝对大小的事再不靠谱，你还得认认真真，仔仔细细地做好它。
你的痛苦我明了。敏捷从来不打算在项目开始的时候把故事卡写得能让我们读得懂的。如果一开始就把验收条件写得清清楚楚，再按上若干个手印，那就不叫敏捷了。所以，从一开始敏捷就是玩我们开发人员的，你得有这个心理准备。
一般，项目开始阶段的时候都有一个需求收集阶段。幸运的话，你也参与了这个阶段。然后，会有商务分析师写出一个高屋建瓴的故事卡列表来，非常非常的高屋建瓴。拿到这个故事卡列表之后，你干什么？
第一件事
第一件事情就是浏览整个列表，试图归纳一下商务分析师是按照什么思路去划分故事的。如果我们把整个项目看做一团泥：
那商务分析师写的Story，就是对它的第一次切分：
到我们写代码，把一个个故事卡变成一打一打的类的时候，是对它第二次切分：
所以，我们程序员和商务分析师做的事情，本质上是一脉相承的。商务分析师的职责就是把故事卡写到最小的程度，写到”外部可见”地最小程度。而外部不可见的部分，也就是类之间的协作等面向对象建模就由我们程序员来完成。所以，好的商务分析师写出来的故事，你非常舒服，拿来就可以写。但是，我们不在理想的世界种，不是吗？不可能给每个项目都配备最强的商务分析师。很多时候，你面对那故事列表会哭笑不得。体现出来的现象是，很复杂的一件事情，没有足够的故事来覆盖。而很简单，或者本质一样的事情，却写出了一堆故事来。所以这就需要你做两件事情。
第一件事情是查漏补缺，无论故事列表看上去是怎么完善，你自己要心里面对整个流程有一个数。然后去确认没有遗漏的故事。第二件事情是寻找重复，大概明白它们是怎么实现的，分析故事之间是不是从实现地角度看是重复的。
最糟糕的情况是商务分析师的切分角度完全错误，切分的时候没有把握住系统的变化点（真正是代码复杂度所在的地方）。对于整体不了解就开始估算是非常危险的。开发人员在这个时候一定要强硬，对于遗漏的故事一定要提出来，对于重复的故事一定要去掉，对于切分完全错误的故事列表一定要求她们返工。
不明白的时候，我们能做什么？
别指望在项目开始的时候，故事卡上会有很多字。让你估算，你算不出 。难不成你给你的项目经理说，不如你来？NO，NO WAY。这个时候你首先应该与商务分析师交谈，尽可能多的了解细节。但是我们在报价阶段，或者项目前期，商务分析师自己也不是很了解业务，而且我们也没有无限多的时间是去调查了解。所以，真实世界中，你必须在没有充足信息的情况下做出估算。这个时候，你有两个选择：
1、拒绝估算
有的时候，我们可以说不。荒谬的估算，害人害己。不要指望，一个“充分大”的估算可以把你罩住。把小的故事估算大了，只能让其他真正大的故事相对变得小。不要给10，或者8这样没有谱的数字。不要在你所有的估算值中随意地选一个非常大的值。因为你一旦选择了这个值，比如10，项目经理在做发布计划的时候就真的会当10来计划，这意味着5张2的故事卡，3张多3的故事卡。你要扪心自问，这真的有5张2的故事卡那么多吗？或者这够吗？10不是10，10代表你“不知道”。程序员可以说不。
2、做一些假设，把假设写下来，然后在假设的基础上做估算
这是迫不得已的做法，特别是你要报价的话。你必须要把你做的假设写下来。因为你会忘记，你会离开这个项目。你不希望你的同事实现这张故事卡的时候骂你对不对？那请你把你做的每个假设，比如不包括数据库，只有前台界面等等，写在你的估算的旁边。剩下的事情就是祈求你的项目经理和商务分析师会在做迭代开发的时候尊重你的假设。当假设变化的时候，让客户知道，我们做了额外的超出了估算范围的事情，你必须补偿我（。。。Ideally）
做加减法不要做乘除法
在具体做估算的时候，有两种风格。一个种是乘除法，一种是加减法
1、乘除法
选择一张所谓的一个点的故事卡。然后其他的故事卡去和这张一个点的卡做比较，得出它们的估算。如果需要两倍时间，那就是两个点。如果是三倍时间就是三个点。
2、加减法
选择一张中等尺寸的故事卡。然后其他的故事卡去和这张卡做比较，比它大的一点的，我们加一，比它大很多的，我们加二，比它小一点的，我们减一，比它小很多的，我们减二。
我个人觉得， 不要去用乘除法，只用加减法。因为人对于衡量两个物体的倍数，非常不擅长。即便把项目做完了，你也未必能准确估计两张故事卡的倍数。另外，写到好的故事，应该是大小相当的。如果故事的尺寸相差三倍是一个常态，那我觉得这是不正常的。理论上来说，最小的和最大的故事卡，应该在两倍大小左右。如果太大了，说明我们没有理解业务，或者切分方法有问题。特别是你要理解估算是要指导迭代开发的。你估算出一张卡是8个点，那要4张2个点的卡才与之相当。如果用乘除法，导致故事卡的尺寸往往相差很悬殊，在实际开发中真的会有那么悬殊的差距吗？个人推荐的估算值是2，3，4，5。一般取2或者3，大一点的4，大一点的带一些风险的5，如果更大的，那你就要考虑拆分故事了。
总结
估算应该算是敏捷的薄弱环节吧。而且也是成功敏捷项目中的关键环节。传统项目，预先设计，闭口合同等等很多东西，有一整套方法学来指导我们做估算。在这个方面，敏捷毫无疑问把担子都推卸到了具体去做的人身上。关于估算，还有很多东西值得我们去学习探讨。