本文目的不是为了给读者提供一个万能的、准确的估算方法，而是抛砖引玉，罗列出业内专家对敏捷估算这一话题的不同声音：

　　项目的估算一直是困扰很多同学的难题，很多项目反馈，无论使用何种方法都估算不准确，还有的项目计划未达成也都归罪于估算问题，更有项目由于估算偏差较大而导致项目亏损。种种问题都是关系到软件从业者日常工作的每个环节。近来无论是AgileChina邮件列表还是新浪微博上都有关于这方面的讨论。以下是我节录新浪微博上的一些讨论，有些断章取义，请读者不要纠结于细节。每种观点都非常有价值。

　　以下是微博网友的讨论。注：出场人物(按照出场顺序，以微博上的个人描述为准)：

　　楠妮乐园：都是我们这位可爱的学员的一个小问题引发了后面的讨论。

　　王晓明：知名敏捷咨询专家，敏思特咨询首席合伙人，创新工场特聘导师王晓明

　　徐锋：资深软件需求咨询顾问，专注于需求方法研究，著有《软件需求最佳实践》等畅销书

　　高磊：百度资深高级工程师，测试专家。

　　乔梁：百度人称乔帮主，百度资深咨询师，《持续交付》的译者，国内著名敏捷专家

　　袁店明：上海贝尔资深敏捷专家

　　徐毅：惠普全球软件服务中心资深敏捷顾问 徐毅

　　熊节:《重构》等知名敏捷书籍的译者，国内最早推行敏捷的大师级人物，现就职于ThoughtWorks. (从敏捷中国邮件列表里摘取)

　　问题的起源是我《需求变化不再痛苦》的课程中的一个学员关于敏捷估算的提问：

　　@楠妮乐园：咨询一个问题，工作量的估算，按工作量估算时，一般一个point的工作量是多少?比如是一天?如果是一天，这一天是否包括测试?

　　王晓明：工作量和时间没有关系。一个笨方法(不是好方法)是你可以按照大概100-150行代码量作为一个point, 估算只是开发人员估算，要包括开发人员从设计，到开发，到测试的所有工作量，如果需要重构和编写自动化测试也要包含在内。

　　【编者】王晓明的回答提供了一个Mike Cohn敏捷估算和计划一书中提到的方法在一些公司的应用，尤其是当一些团队不清楚一个故事点的大小订到什么程度合理。

　　这个回答引起了后面一系列关于需求，估算，不同流派，不同理解的讨论。

　　徐锋：工作量估算更准确描述是规模估算，是时间估算的基础，在把工作量估算转成时间估算时，需要考虑很多因素。另外，这里的Point是指故事点还是功能点?如果是功能点，没有100-150行。

　　王晓明：敏捷开发中，针对Story只做工作量估算(故事点)，针对项目发布计划，迭代计划才做时间估算。是以项目的历史效率和当前对工作量为依据来做迭代计划和发布计划。这里说的100-150行可以片面的认为是一个故事点的工作量。

　　徐锋:故事点是规模估算。工作量的单位是人天、人时、人月……，时间估算准确说叫进度估算。准确说，敏捷开发是省略了工作量估算。

　　王晓明:在敏捷开发中，Story的估算是使用工作量作为计算单元，例如故事点，理想天等等。举例说明具体估算方法：团队定义A开发不受打扰的情况下一天可完成的工作量作为一个故事点，估算任何Story的工作量只要估算其相对于1个故事点的相对大小即可。推荐读一下Mike Cohn的敏捷估算和计划。使用人天，人时，人月估算的缺点是每个人的能力不同，因此对同等工作量的估算也不同，这种情况下项目计划制定过程是比较复杂，且不够合理，需要细致到每个人。并且对单点的依赖过强。不建议在敏捷方法中使用。

　　徐锋：故事点在Mike那本书明确地指出它是规模估算的工具，而非工作量。另外，故事点并不一定必须等于一个理想日，你可以这样定义，但不等于故事点就是这个定义。你对于传统估算的理解有偏差，理想日并不是敏捷的创造，在传统的估算模型中就已经提出的。你应该了解了解COCOMO，模型不一定可用，但其抽象是很不错的。

　　王晓明：故事点和理想天是两种不同的估算方法。之间没有任何关系。看到这里我感觉是大家对英文翻译到中文的词汇上的误解。故事点是相对值。每个团队1个故事点的定义都是不同的。没有横向可比性。

　　【编者】这一段的讨论中几位参与者围绕了，工作量估算，工作时间估算，规模估算进行了从不同视角看待项目的讨论。敏捷方法中，项目计划只关注两个因素，一个是估算的工作量，另外一个是实际完成的效率。例如一个迭代计划中10个Stories，估算的工作量是23个Story points，实际完成了20个points。23是计划，20是实际工作效率，根据一段时间的统计，可以将平均绩效作为计划制定的依据。

　　乔梁：估算就是估算，本来就不准，花再长时间也不准确。

　　袁店明：看到大家都在说估算，本来就是对未来的一个估算，软件开发已经从工厂流水线走向创造和探索性的工作，所以是不可能精确，能做到相对准确就算不错了，所以对于端到端的用户故事是不可能精确的。而且对于一个非常小的任务也不可能做到精确，相互信任才是最重要的。

　　徐锋：故事点是规模估算。工作量的单位是人天、人时、人月……，时间估算准确说叫进度估算。准确说，敏捷开发是省略了工作量估算。这种分隔不是我的功劳，在COCOMO模型中就把他们分得很清了。而且估算是一个大领域，并不是《敏捷估计与规划》一本书覆盖得了的。

　　徐毅：我觉得敏捷的做法还是有一定思考的，也即要做到那些所谓准确的估算或度量，要花费很多的功夫，甚至也不是每个人都可以(也不是每个人都有必要)去学会那么高深的估算技能，所以，敏捷实践中降低了前期对估算准确度的要求，以合理的投入获得最大的效果，并以其迭代增量的方式填。

　　徐锋：另外估算不是玄学，也不高深。COCOMO、FP也不太难懂。FP也并可以进行剪裁，很多影响估算的因素在COCOMO背后都有系统研究，抛弃之太可惜!

　　徐毅：COCOMO没有专门研究过，FP了解过一些，感觉极其复杂的计算方式，不知道在什么样的情况下，这个成本代价是值得的。

　　徐锋：其实FP过程是可以简化的，如果只是采用粗估FP法，工作量还算是有限的;但应用它的问题在于模型的抽象稍有过时之感，还有就是无法解决早期估算(这方面我有一些研究成果，有一定作用)。

　　徐毅：问一个问题哈，是我自己有疑问，也一直没有(懒)花时间去搞清楚的，“FP最初被发明出来使用，是为了解决什么问题的?”

　　徐锋：一是度量(现在还会做为法庭判案的基础)，二做为估算(当然有点重)。我一直认为方法本身不重要，重要是他后面的假设、研究结论。我并不鼓励全面应用COCOMO和FP，但学习并变通是很有意义的。

　　徐毅：一和二还是没有很理解，能否详细讲讲?或者有没有相关的文章什么的推荐来看看。

　　徐锋：度量，是指开发之后进行评价。例如，最后到底交付了多少规模的软件呢?估算，是指开发之前。你读读FP和COCOMO的书就可以了。文章很抱歉，我不太喜欢互联网阅读，我只喜欢读书，歉意。

　　徐毅:那有什么相关的书籍呗?我在当当上收藏了一本COCOMO II准备以后买来看，但毕竟没研究过这一块，不晓得什么书会比较经典点或者好入手点。

　　徐锋 《软件估算--黑匣子揭秘》也不错，COCOMOII我有(英文)，还有一些关于估算的英文书籍。

　　【编者】这里徐老师提到的几种估算方法都是有一定应用范围的方法。

　　王晓明回复@楠妮乐园：我建议这样做：找一个相对简单，较小的Story，将这个Story定位一个故事点，然后让开发人员估算其他Story相对于这个Story的大小。从而得出所有用户故事的工作量。这种情况下，这个作为标准的故事最好不要太小。是一个平均水平开发人员半天至一天能完成的工作为佳。

　　袁店明：就是根据团队目前掌握的信息和已有的经验，进行猜，但是这个猜的颗粒度要比较小，根据概率论，取样的样本数多，那么就趋于准确。

　　王晓明：随着完成迭代数越多，未来计划的可达成率就越高，正如Dynesy所说，取的样本多了，趋势趋于准确。

　　【编者】敏捷的精髓是针对不可预知的不确定性进行有效的应对，提高团队的能力，从而可以快速应变。

　　乔梁：指导团队估算时，多次使用了排序法，比扑克法更快捷，效果更好。

　　王晓明：我个人经验就是Mike Cohn的这种敏捷的估算方法比较实用。我们在几十个项目中应用过，是可以满足项目要求的。要注意，团队中的开发人员中必须有经验丰富的，领导能力强的2-3个人。完全是毕业生就不靠谱了。

　　徐锋：完全同意晓明同学，敏捷估算方法是很实用的。

　　熊节： Estimation的结果对整个项目有着极其重大的影响。

　　据我的观察，项目初期的estimation，不管用哪种方法，都有一个共同的特点：不准确。实际上各种看起来很好的估算方法，得到的结果都跟拍脑袋差不多。如果你的项目成败依赖于初期估算的准确，那么你就是在依赖拍脑袋，或者叫撞大运。

　　上述讨论的总结和编者的感悟：

　　估算有以下几种目的：

　　为了报价需要根据已知需求和“预测”需求进行工作量的估算，从而进一步转化成项目费用(为报价提供依据)

　　为了制定项目计划使用，一个项目的组织安排需要多个项目Stakeholders的配合协作，某一个或者多个功能的交付时间(由项目估算间接计算获得)直接影响到项目相关方的安排。

　　为了排列功能的优先级用，当产品经理对需求优先级进行排序的时候，除了需要了解其商业价值，还需要了解其大概的成本，在敏捷项目中这个成本就是由需求工作量的估算，间接换算出来的。

　　为了帮助团队对需求，设计，工作量达成一致，并且了解团队成员的技术能力用，当不同团队成员在估算某个需求的工作量有较大分歧的时候，往往是因为队员对需求，设计有不同理解或者对代码的熟悉程度差别较大。在这种情况下可以通过估算环节帮助团队达成一致。

　　上文中徐老师提到的COCOMO，FP，乔梁老师提到的排序法，Mike Cohn《Agile estimation and planning》中提到的T-shirt size和故事点相对值的估算方法都有项目在使用。

　　COCOMO：Constructive Cost Model：是通过一些算法，根据团队的成熟度不同，能完成千行代码数所需要的时间不同，加上一些参数和各种计算的一种项目估算方法。[http://en.wikipedia.org/wiki/COCOMO]

　　FP：function point：是IFPUG Functional Size Measurement Method方法中的功能点规模(工作量)的估算单元，这也是ISO推荐方法之一。[http://en.wikipedia.org/wiki/Function_point]

　　排序法：主要用于发布级别的估算，估算相对大小。具体做法是：当MSL(Master level Story List)产出后，每个开发人员各拿一部分Stories(卡片)，根据各自的理解对手中Stories按照相对大小进行排序。当这个过程结束后，团队再对这些Stories进行横向比较，将大小差不多的分到一起，然后将排列好的Stories对应到相对的工作量大小，例如1,2,3,5,8。对于过大的Stories要进行分解。

　　T-shirt size估算：将MSL中的Stories根据相对大小估算成S, M, L, XL，然后确定其之间的大小关系，例如一个M相当于两个S，继而根据实现一个S所需要的工作量，最终估算出全部MSL中的工作量。

　　故事点估算：这个方法我在微博中已经都有过详细的讲述了。这里就不一一赘述了。

　　正如熊节所说，任何估算都是按照一定的数学方法进行猜，不可能非常准确。使用方法比完全不使用方法的偏差还是小一些。根据我个人经验，估算的合理性取决于很多复杂因素，例如团队成员技术能力，对系统熟悉程度，代码可读性，对一个Stories设计和实现的充分考虑等等，例如：是否考虑到了性能要求，数据库要求，可用性要求，安全要求，测试代码需要的工作量等等。我做过的很多项目中，估算相对合理的都有一些共同特点：我全程参与了从需求获取，分析，描述到给开发人员讲解的过程，开发团队中有1-2个经验丰富，学习能力极强的人。